Burndown Chart Patterns

Ideally, a team's or project's trend line simply burns down to zero at a constant (or near constant) slope.  Since we don't have the luxury of living in an ideal world, especially on software projects, other patterns typically emerge, especially in earlier iterations until teams get into a more consistent rhythm.  A few of the more common include:

1. Rising Slope - it is very common for some additional work (tasks, unexpected functional scenarios, a quick spike to validate feasibility) to be identified shortly after the initial planning session.  This is not necessarily a bad thing, more the reality of software, just hopefully limited in scope.  As a result of this early initial climb in the burndown chart, the team quickly needs to determine whether this is natural and can be addressed in the current time-frame, or whether this is pointing to a bigger problem in terms of overall scope.  The fact that this is visible early is absolutely key, especially given that is helps everyone on the team focus specifically on what needs to be done to ensure that the iteration or project does not spiral out of control.

2. Flat-line (i.e., zero net progress) - a flat-lined burndown chart may have a number of explanations: 

• The team may have been pulled to work on other projects or priorities (i.e., another project, support and maintenance) and has left the current project helpless to succeed.
• The team may be completing work at an expected rate, but new features and/or tasks are being added to the iteration or project as fast as work is being done.
• Defects and rework may be preventing real progress from being made.

We have all likely experienced these types of situations from time to time, and know that, regardless of the reason, they all require immediate attention if the project is to have a chance of success.

3. Late-breaking Decline - A really interesting, and unfortunate, pattern and one that is most difficult to explain is a chart that is clearly not headed to zero but then magically, at the end of an iteration or project, the slope makes a bee-line for zero and somehow finishes on time.  Did the team suddenly get incredibly productive, did all the features get thrown out, did the definition of potentially shippable change...? Clearly, none of these explanations support a reliable, predictable process of any sort.  But heck, glad they hit the date - just don't want to be the one on the receiving end of this software<g>.

Comments

[Mishkin Berteig]

I am glad you pointed out the "Late-Breaking Decline" pattern. That's one that I missed in my "Five Signs of Trouble in an Iteration" article on Agile Advice (http://www.agileadvice.com/archives/2006/03/five_signs_of_t.html).

[Ajay Danait]

One reason for Flat-line (i.e., zero net progress) could be that the team did not report progress regularly or there was a vacation plan (or the team members did not turn up to work).

[Paul Arrowood]

Do you advocate tying story points ONLY to true story development work? Or would you give points to defects, spikes, and other work not done at initial release planning? We seem to always have a constant creation of "things to do next week" and as coach & PM, I just don't know whether that's because we're new at this, or whether this 'smells' of something needing investigation/improvement?