BT

Deciphering Burndown Charts

by Vikas Hazrati on Feb 16, 2010 |

Burndown charts are considered to be one of the most useful information radiators on an Agile team. It is a graphical representation of amount of work left to do (y-axis) versus time (x-axis). The interesting part is that the analysis of the burndown chart can reveal multiple pointers on how the team is doing and what can they do to improve further. It helps in getting a good heart-beat on how the team is making progress.

Hiren Doshi suggested that it can help in answering the following questions

  • How good is this team with the planning?
  • How well is this team executing against the planned stories in a Sprint?
  • Is this team self-organized and are they working in unison as a "team"?
  • What improvements can this team make?

Hiren took an example of the following chart

Commenting on the blue line, Hiren suggested that, as per the chart, the team planning is not good since their line never touches Zero. There could be multiple reasons for this. There might also be an issue with the unison of the team and they might need coaching. Hence, the improvements would more likely be in terms of planning and self organization.

The purple line suggested that the team did reach its goal but probably they were not proactively updating the numbers. Either they were lazy in updating the amount of work left or towards the end of the sprint a lot of user stories were jettisoned.

The green line suggests a burndown for a mature team who has been planning well, is self organized and they have had enough stories to keep them busy through the sprint. This line as close to an ideal line that one can possibly get given the complexities of software development.

Likewise Kane Mar suggested the following seven categories for burndown charts

  1. Fakey-Fakey – Characterized by a perfect decent towards completion. Software projects are complex enough to have a straight like to the goal. Mostly these graphs come from environments rampant with command and control and open communication is a rare commodity.
  2. Late-Learner – These are characterised by a hump late in the graph. Common with teams trying to communicate effectively and learn scrum.
  3. Middle-Learner – These graphs have a hump in between showing more maturity than late-learner. These teams discover most tasks and complexities during the middle of the sprint.
  4. Early-Learner – Early hump and then a gradual burndown. These teams have realized the importance of early discovery and then they work effectively to achieve their goals.
  5. Plateau- These teams make good progress in the beginning and then lose their way in the later half of the sprint.
  6. Never-Never – This is when the burndown suddenly starts moving up towards the end of the sprint and would not come down. These late changes need to be raised immediately and also as a part of the retrospective.
  7. Scope-Increase – This is characterised by a sudden increase in the amount of the work during the sprint. It’s usually a sign that the team did not fully appreciate the scope of work committed to during the sprint planning meeting.

George Dinwiddie too described the common burndown issues and attributes.

Thus, there is a lot which can be deciphered from the burndown charts. The key is to keep analysing them iteration on iteration and keep improving on the basis of that analysis.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

I am not sure the burndown answers anything :-) by Kjetil "Fred" JD

But it raises questions! The "answers" suggested here are some possible answers that *might* be right - but they might also be totally off. Use your burndown as a vehicle to produce questions - and explore the answers with your team.

Re: I am not sure the burndown answers anything :-) by Vikas Hazrati

Hi, I would agree with you that the answers would vary as per the teams and the circumstances. The idea is that once you start interpreting it in the right way, it could potentially lead to the root cause of a lot of things.

Meh by Aslak Hellesøy

Burndown charts are lame. Please stop using them. They don't show lead time or bottlenecks, robbing teams for opportunities to improve important things (deliver faster). People should move to CFD (Cumulative Flow Diagram). They convey so much more information.

Re: I am not sure the burndown answers anything :-) by Bas Biesheuvel

I agree on this. These answers might be right in some situations, but not in all.

As for an example, most of our burn down's look like the purple line (line 2) in the first picture. Not because of the reasons mentioned in this article, but because in most cases we end with high complexity stories that are developed in parallel and are finished just in time.

CFD are better than Burn down charts by puneet jain

I agree with Aslak, CFD are much better in terms of giving details of development. but how to have a unified CFD where nature of tasks are different, i.e if tasks can not be broken down into same kind of subtasks.

Re: CFD are better than Burn down charts by Geir Amsjo

Well, these are two completely different things and not comparable. Burndown Charts was never intended to do anything else than give the team status at a certain point in time. Or raise questions rather than give answers as Kjetil points out. Do not expect the BC to tell the outside world anything. Process Improvement is great and you need to use different measures for that. CFD is an example.

Re: CFD are better than Burn down charts by Mark Levison

Geir - I think the point from the lean community make is that CFD's can give you all the information from a burndown and more. My concern when I'm introducing Scrum is a CFD a bit too much? At this stage I'm still on the fence.

Cheers
Mark Levison
Agile Pain Relief Consulting

Re: I am not sure the burndown answers anything :-) by Mark Levison

Kjetil - I think the key point is that teams should use their burndown (or CFD) in retrospective meetings to check their progress.

Cheers
Mark Levison
Agile Pain Relief Consulting

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

8 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT