Agile projects traditionally use burndown charts to visually show work remaining over time. This could be for the current iteration or it could be for the duration of the project. Either way they can help managers (or the Project Owner in Scrum) track velocity, estimate either the project or iteration completion date, or find trends in past performance. But burndown charts have a major shortcoming: they fail to show what makes agile projects agile – new requirements. And that’s where burnup charts come in. But first let’s examine burndown charts.
The Problem with Burndown
A typical burndown for the life of a project might look like this:
It shows the project started with 100 points of work in the backlog; it’s completed eight iterations; the team accomplishes about ten points an iteration; and if everything continues at the current velocity the project will complete all work within another two iterations. Great.
But what happened in iteration six? Very little appears to have been accomplished. Maybe the team all took a vacation. Maybe there was a major problem or the team incorrectly estimated complexity. Or perhaps a large set of new requirements were added to the backlog because the customer decided what they thought they wanted wasn’t what they really needed: namely the exact scenario agile was designed for.
The problem is that burndown charts lack two essential pieces of information. First, how much work was actually accomplished during a given iteration (as opposed to how much work remains to be completed) and second how much total work the project contains (or if you prefer how much scope has increased each iteration). A burnup chart for the exact project above might look like this:
We can now clearly see that the team did not take a breather in iteration six. They continued to complete about ten points per iteration, but during the sixth iteration the scope increased by about twenty points.
One could imagine the opposite happening as well. Later in the project the team might delete old user stories that were envisioned during project inception and thus decrease the total scope. The burndown chart would incorrectly show such a scenario as a sudden increase in velocity.
Either way the burndown chart hides essential information. I propose we throw it away and show the slightly more complicated, but infinitely more useful burnup chart. After all you wouldn’t want upper management thinking you were lazy in iteration six would you?
For more information on how to produce burn-up charts see my video: How to Create Burnup and Burndown Charts in SharePoint.
I'm just coming back to software development after spending a few years focusing on infrastructure. When I first saw a burndown chart I thought exactly the same - it doesn't show enough information about added or deleted requirements.
I assumed this was just down to my old-fashioned view of things - which it still could be of course :-)
Your burnup chart with a moving target works better for me - have you had any other feedback yet?
It's one of the better ones out there.
However, I do agree with you and prefer burnups myself. I just find them more clear to read. Also, it is much much easier to add other items we might want to present, such as risk reduction, value delivery and others. Plus we're just much more accustomed to reading burnups.