Why I Don't Like Burn-down Charts

Burn-down charts, sometimes known as 'glide path' charts, are a tool used to track progress and momentum in agile projects. Typically this chart is posted somewhere highly visible to remind people that there's still a lot of work to do, and it's no time to relax. In theory they're a great productivity tool, but I don't like them at all.

My sole claim to lasting fame so far is an acknowledgment in David's book regarding my turning him on to Cumulative Flow Diagrams (CFD). Although I didn't know the formal name for them at the time, I had very strong opinions as to why they were superior. You see these charts sometimes in industry growth reports or other areas where you're tracking multiple trend lines simultaneously. The best current example I have for this is a graph of Hybrid Electric Vehicle sales. If a pie graph tracks the distribution of a pool of data for a fixed moment of time, a CFD tracks it over a period of time.

A Burn-down chart, if properly drawn, can reveal a dangerous situation: divergent lines. That is, more tasks are being started than completed, more tasks are being completed than tested. If you find yourself in this situation, it is time to drop everything else that you are doing and have a frank discussion with upper management about project strategy, and the potential for success of the project in meeting its delivery milestones.

What it will never show, however, is if new feature requests are coming in faster than tasks are being completed. Burn-down charts obfuscate one of the biggest risks to a project delivery date, even for Lean or Agile projects: scope-creep. A Burn-down chart sets the 'destination' as the origin of the graph. What happens when the destination keeps changing? If the Y axis is counted in number of tasks to complete, you have to redraw the graph, pushing the lines upward and recalculating them (a potential source of reporting errors, but not so bad if you set up your spreadsheet correctly). Worse, if your Y axis represents percentage complete, then you have a more serious problem, because your % jumps around from week to week. At a minimum, if you must use Burn-down charts, make the axes absolute. The level of unproductive meta-discussion that can be caused by a relative Y axis on a project that suffers from repeated re-scoping can be astoundingly high. Planning meetings where you are expected to figure out what to do about the information can quickly degenerate into hour-long discussions about what exactly the information is.

What we want to see on the progress graph is the current notion of how much work is left to be done, along with the current state of completion. The human eye is remarkably, if not perfectly, good at processing visual information. With a CFD, enough information is presented in the graph that everyone can make determinations about project trends without the necessity of extensive footnotes or side-commentary. The graph literally speaks for itself.

In some situations, the CFD will reveal a bad situation for what it is long before there's articulate consensus among the team that something is not going well (it's very easy, and indeed common, for developers to complain that a situation is bad, it's much harder for them to demonstrate how bad it really is). If the whole point of the graph is to measure and to report, and hence to know what the hell is going on, why chose a graph that is less capable of achieving this goal?