Deciphering Burndown Charts

Posted by Vikas Hazrati on Feb 16, 2010

Sections

Process & Practices

Topics

Agile Techniques ,

Agile ,

Information Radiators

Share |

RELATED Research

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.

RelatedVendorContent

Five Key Practices to Agile ALM

Agile Practices to Improve Project Management Organization (PMO) Effectiveness

Agile Maturity Model Applied to Building and Releasing Software

Agile assessments for your team

Agile workshops and training

Related Sponsor

Maximize your business-responsiveness with Mingle. Provide your global development team a shared space that adapts to the way they work.

1. Back to top

   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.

   Reply

2. Back to top

   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.

   Reply

3. Back to top

   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.

   Reply

4. Back to top

   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.

   Reply

5. Back to top

   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.

   Reply

6. Back to top

   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.

   Reply

7. Back to top

   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

   Reply

8. Back to top

   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

   Reply