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.
