Burndown charts are a fairly common tool used in Agile projects to measure the velocity of a team. It usually contains two sets of data, the actual missing effort and the expected missing effort.
The thing is, looking at a burndown chart is useless, unless you have a very good understanding of what’s going on with the project.
Here’s a sample of a burndown chart:
At first glance, it seems things aren’t bad. Although there is a “saw” look to it, every couple of weeks things go back to normal. The drops seem to occur at the end of each iteration (assuming 2 week iterations). But the thing is, the chart doesn’t show us why the drops occur!
One reason might be poor self management by the team. They only close the stories at the end of the iteration. This is a good scenario, because it means you can quickly coach the team to have more fine grained stories, so you can have better visibility on the project.
Another reason for these drops might be that, at the end of each iteration, the team reviews the backlog and realizes it will miss the date. With that in mind, they remove the last items from the backlog, and the project gets back on track. This is way more problematic!
The team is assuming the project is about 1/2 weeks late (marked by the dotted red line), so they cut 1/2 weeks worth of work from the backlog. But the reality is that the project is 5 weeks late! (marked by the dotted blue line).
The consequence of this is that the team will have to cut about half of the backlog to finish the project on time! This can obviously have catastrophic implications for the project....
There are several ways to deal this problem, but the important thing is that action is taken as soon as possible. And to be able to quickly understand what is going on, you cannot trust on the burndown chart alone. You need a very good understanding of what is going on with the project.
2 comments:
I think your burndown chart cannot be interpreted as the second scenario. If the backlog is cut than I expect the red line to drop (ideally on the day when it's cut). When features are added during the project I expect the red line to rise. If you see drops on only the work done line but not on expected one then the work should actually be done.
But anyway I agree with the idea of your post that we need to be careful in deriving project status only from looking at burndown. This should be always some trigger for further investigation. Anyway you get a feedback during standups and everyday communication. Burndowns may be used to notice some general trends.
Actually the red line is a forecast line, so it does not change when the backlog changes. Still, you are right, it would be pretty easy to add a line that reflects the changes in backlog size... that would fix this particular problem, but not others.
The main point here is that you can't just look at numbers to draw conclusions about a project. (kind of reminds me of the late Robert McNamara).
About standups, iteration review meetings, etc, they are great communication improvers, but they tend to focus on the short term. It's very important to stand back and look at the broader picture frequently.
Post a Comment