Forget Burndown Use Burnup Charts
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.
Burnup Charts
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.
Summary
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?
7 Comments
Leave a comment
0 TrackBacks
Listed below are links to blogs that reference this entry: Forget Burndown Use Burnup Charts.
TrackBack URL for this entry: http://www.nearinfinity.com/mt/mt-tb.cgi/433
In the summary the first 'burnup' should probably mean 'burndown'.
Great idea!
The burndown charts shown here are release charts, where each data point captures the points remaining at the end of each iteration for an entire release. I agree that burnup charts are useful for tracking progress across the release, but I don't think they are appropriate for tracking progress within an iteration (or Sprint, in Scrum terms).
Iteration burndowns are ideal for providing daily feedback to the team for the purpose of deciding whether to reduce scope, add scope, or abandon the iteration entirely. In Scrum, success of the iteration is of utmost importance; the entire Scrum process relies on regular, predicable, and demo-able results at the end of each fixed-length iteration.
So don't throw away those iteration burndowns!
More info:
http://www.mountaingoatsoftware.com/sprint-backlog
Steve,
On our project we have week long iterations. So iteration burndowns would only be so useful us. But even so we still (even though we know we shouldn't) occasionally add stories mid iteration. Doing this would still scew the results of a burndown, and I believe showing an iteration *burnup* would still provide more useful information than a burndown. I stand by my conclusion: throw those burndownws away :).
I've just got into project management recently. We've been using burn up charts for the reasons mentioned in the article. I've been using NXS-7's Task Analytics http://task-analytics.com for our projects. Are there any products that you would recommend?
We have had a debate regarding the need for accurate calculations for velocity during project life cycles.
Looking back on what has been completed a typical simple average of story points completed per iteration seems adequate for Agile purposes. The question of complex story points where more time is required to complete them is drags velocity down for specific iterations.
One opinion is to assign higher numerical values as a multiplier to weight these points more heavily. This seems to provide a more discrete option for velocity calculation.
What is you opinion on the value of more complicated velocity calculations?
In my team, we use burn-down charts with discontinuities: requirements that are added or skipped in the sprint show up as a vertical plot in the burn-down chart.
In that way, we can show the changes in workload during our sprint.