I was surprised to see Ken Schwaber talking about burn-down charts, as burn-up charts provide more information and are — for me — the preferred option. So this is a short article about burn-up charts and burn-down charts, both great tools for measuring progress.
First, though, a hat-tip to Ian Carroll, a colleague at MEN Media. His blog shows off the video I saw. In it, Ken explains Scrum and answers a few questions from Google employees. It was worth an hour of my time just for his explanation of the wider consequences of dropping quality. The argument may be familiar to you, but the clarity of the explanation and the use of the visual aid (a burn-down chart) is terrific. If you want to see just that then jump to minute 40.
A burn-down chart tracks how much work remains on your project and whether you’ll hit your deadline. The vertical axis measures work remaining. The horizontal axis marks your iterations, and you should mark which iteration is your target end date for the project. After each iteration you mark your progress on the chart and you can project forward to see whether or not you’ll hit your target end date.
In the diagram above we’ve gone four iterations, and the dotted line (the projection) suggests we’ve fallen quite badly behind schedule. After the first iteration you can see we were making good progress, but things changed in the second iteration and alarm bells should have sounded. The project manager should have started doing something then.
A burn-up chart tracks how much work is done. But it shows more information than a burn-down chart because it also has a line showing how much work is in the project as whole (the scope as workload), and this can change. On the burn-down chart it is harder to show a changing goal.
In the diagram the bottom line is the work done and the top line is the total scope. Dotted lines show projections. We can see that the scope remained steady for the first few iterations, and we would have expected to make the deadline. But scope increased around the fifth iteration. Even this wouldn’t have been too bad if that had been the end of it, but it continued to increase after that. The projections show that we won’t make the target deadline at our current rate of scope creep. In fact we probably won’t even make it if the scope remains steady.
More sophisticated burn-up charts can show several scope lines, one for each release milestone. This way the team and the stakeholders can see the effects of, say, moving scope from one release to another.
Burn-down charts have the advantage that they’re simpler — they only show one line. Perhaps that’s why Ken used them in the video; much more would have distracted from his messages. But if you can stand a little complexity then I’d recommend burn-up charts as the more useful option for real-world situations.
[Update 16 June 2015: If you want to go further, see my later article for an easy way of making these charts with Google Sheets.]
9 thoughts on “Burn-up and burn-down charts”
I find burn down charts excellent as a motivation tool (as a side effect). Burn up charts are if anything frustrating.
As a ScrumMaster I’d say just keep feature creep out.
Burn up charts aren’t just to track feature creep, but also changes in estimates. Though I agree about the motivational benefits of a line cruising to zero.
I hope you don’t mind we’re referencing this article on Banana Scrum site http://www.bananascrum.com/news/2009/07/16/track-the-progress-of-your-team-with-burnup-chart/
I’m surprised at how many people use burn down charts over burn up charts which are way more informative. It’s hard to find burn up chart software. I’m using NXS-7’s Task Analytics http://task-analytics.com burn up charts. It’s been pretty good.
Even though burn-downs are simpler, burn-ups are pretty simple, and the motivational “goal” is to watch the lines meet at the end of the iteration (or release, if a release burn-up). In fact, though there is a motivational factor here, this graph is more significant as a reality-check and planning tool. The lines at the end WILL meet. There is no way around it, unless you know how to stop time (and you don’t). That’s what I like most about the burn-up: It readily reveals scope-creep (which could get hidden by a burn-down) and it shows the opposite, too, when scope is cut in order to meet the deadline. Burn-downs show scope reductions as some strange miraculous period of performance. “Why can’t your team work like that all the time?”
Let it be an information-radiator, not a motivation-radiator, and it will motivate. Let it be a reflection of what’s really happening, rather than fudging the numbers.
Nice graphic, BTW. Can I borrow your burn-down for Agile 2009? It shows up as one of the first in a Google Images search for “chart down” or whatever I asked for… ;-)
I tried NXS-7 Task Analytics http://task-analytics.com and it was pretty basic. It’s ok for Micky Mouse projects but for something more sophisticated try atlassian.com
Concerning my experience, I am coaching projects since 1995 (from small to very large project, from start-up organizations to large multinational companies)
Burndown chart is a very smart add from Scrum Methodology: it allows to track the ETC
ETC is something very heavy to follow-up/ track in the standard Project Management Method, but with the Burndown chart, you get it for free , this is just awesome!
Moreover, the idea itself of burdndown chart means focusing on a sprint target and try to reach it. Do not forget in Scrum, you are agile, but the scope of the sprint is frozen. As I often say it in my trainings, there is a difference between Agile development and chaotic development: the limit of agility in scrum is to have a fix scope for each sprint, else the project could permanently change it scope, to deliver…nothing, circling and not moving forward
So What I mean is that it is very important to focus on the idea to deliver in time the committed content for iteration, and for that burndown chart are king’s
Having good BurnUp does not show you deliver the expected scope in time, just show you produce at a good rhythm, but the focus of scrum is not to make a software factory where only production is encourage, but to produce the right thing!
By the Way, working with ETC provides you a higher Project Management Maturity rather than only counting the time spent or the produced story points or man days (refer to PMI or CMMI)
Patrick: With this information you’re actually able to calculate Earned Value for the ongoing project as well. This is very useful for progress reporting as well.
Comments are closed.