Burn-down charts: The Good, Bad, advice and alternatives

I’ve never completely accepted burn-down charts. I know they are a staple of Agile development and I’ve even used them myself but I’ve never been completely happy with them.

The reason I’ve never been happy with them is that they require and initial figure to burn-down. You need an initial number - in hours, days, points or what ever - to seed the chart and then you burn off some amount and you see the line falling.

The problem is that initial figure, it has to come from somewhere. In generating that figure you need some description of the work to be done, i.e. requirements, and you need some estimation of how long it will take. Both known requirements and estimates have their problems.

Burn-down charts were popularised by Scrum where there are, strictly speaking, two types of burn-down chart: the product burn-down chart and the sprint burn-down chart. Since in Scrum the work to be done is fixed for the iteration (barring a major issue) the requirements are pretty well fixed so that isn’t s a big issue, and the estimates are the best known at the time which isn’t too much of an issue.

In a 4 week iteration, with a Sprint Goal I can see were the Sprint burn down has a place. But if the iteration is 2 weeks or 1 week I’m not sure it is worth the trouble. And if there is no Sprint Goal then what does it show? Progress against a collection of tasks?

My bigger issue lies with the Product Backlog burn-down chart. Because the items haven’t been committed to a Sprint then there is every possibility they will change. Indeed, the more Agile you are the more likely they are to change.

However, once the estimate gets out there, once it becomes known the team estimates the project at 100 points of work people start ask questions when the number changes.

There is also an inbuilt assumption that there will an end to the development work. When the thing under development is a Product or a Programme development work may continue for a long time, perhaps ever. So its wrong to talk about end dates - and also wrong to talk about projects because projects, by definition, have an end date.

Then there is the estimate: it is made when there is little information known about the requirements, the system or how much work is needed on the code. So the estimate is going to be pretty inaccurate. The best that can be said is that its a finger in the air.

But, the estimating process normally takes a lot longer than sticking a finger in the air. If you involve the whole team it takes even longer. If you don’t involve the team then its the estimate of some “leadership” which runs counter to the principle of self-organizing teams.

More detailed estimates also leads you into design decisions - because how can you estimate if you don’t know what you are going to do? However, its best to delay design (and other) decisions until the last possible moment because the information on which they are based can change.

The first Agile teams I coached skipped burn-down charts altogether. Then one day a colleague on another project (yes, you Ed), told me his Project Manager felt a lot happier now there was a burn-down chart in place for his work.

And thats where much of the value of burn-down charts. They give Project Manager types something to stare at. Burn-down charts look enough like a Gantt chart to reassure people.

All that said I use burn-down charts. Yes they are useful. They are genuinely useful when you have a piece of work with a defined end condition, i.e. a genuine project.

Of course you have to overcome the estimation problem. The trick is to accept estimates are just that, estimates, do them fast, don’t worry about them. Then do plenty of statistical tracking. How much new work is found each iteration? How much is removed? Then project forward best and worst case.

I did this with a team last year. At first we had a burn-down chart with but I refused to give a end date. After a few weeks we had data on how fast the team was working, what new work was being found and how much work was being removed. From this I could forecast a best case and an worst case end date.

That’s important: there is no definitive end date, just a range of possibilities. The more data you have the more accurate the estimate should be but its no guarantee. Giving a range of dates might not make you popular but it ensure people remember there is no certainty.

Burn-down charts are not the only tool for tracking team progress. Some people prefer burn-up charts. At first I thought this was for psychological reasons - up is more positive than down - but its also easier to add more work to the top.

So, if a team is doing 10 points a week on a 100 point project its easy add another 20 points to the chart and show the team now have to get to 120.

Taken to the extreme you get cumulative flow charts - often used by Kanban teams - shown in this diagram:



These show both the total work done and the total work to-do as constantly rising lines. If total done ever matches total to-do then its game over. This technique is open ended, the work is ongoing. And it is only necessary to estimate a little bit ahead.

So, if you do use burn-down charts:
• Consider using burn-up charts or cumulative flow diagrams
• Don’t make estimates too detailed; don’t worry about over estimating, it will all come out in the wash anyway
• Certainly don’t spend too long making detailed estimates
• Track work done, work discovered as you go along and work removed; you don’t need to put these on the charts but keep the numbers so that you can...
• Use statistics to project a range of end dates
• Don’t let anyone thing a burn-down chart is a substitute for a Gantt or Pert chart

And when people demand a done date remind them that the old method didn’t give them a done date either. Yes it gave them a date but it was never the actual date.