Are Burndowns Evil?

Agile teams often use a burndown chart to track the progress of a software project. The burndown chart provides an indication of work done over time. I have used burndowns on many projects and I have come to believe their use can negatively impact the quality of the software we deliver, without providing much benefit to the outcome of the project.

Firstly, a burndown can create schedule pressure early in the iteration. This is especially apparent on a new project with a new team. It takes time for a new project to get under way and for team members to get up to speed. This time can be very difficult to factor into an iteration.  Even though progress will improve, seeing the burndown flat-lining immediately can cause a lot of negative pressure on a team.

A burndown chart is linear and has no room for variations in team size, unscheduled meetings, unforeseen technical problems and other issues outside the control of the team. The burndown doesn’t take into account the unplanned, but necessary work that needs to be done to ensure the success of the project.

A burndown can be very unforgiving. One bad day and the progress line goes off course. This can cause pressure within the team to cut corners to get back on track. This is detrimental to the quality of the software and encourages developers to get a story done quick-and-dirty just to satisfy the burndown progress.

The progress of a burndown can be taken the wrong way by project managers and customers. No stories complete == no work done, which is usually not the case. If we need to track progress, we can simply look at the task board! How many stories are done? How many are still to do? How much time is left in the iteration? What needs reprioritising? Talk about it. Discuss the issues. The task board is a great place for the team to get together and talk about the progress of the project. If required, create a throw-away progress chart. But we shouldn’t drive the development process from it.

Use the number of points/ideal-days completed to estimate the team’s velocity. The velocity should be calculated on work already completed. For a new team and a new project, it is almost impossible to predict a velocity for the sake of creating a burndown, so why bother? It can cause more harm than good.

Another problem with the linear nature of a burndown is that it doesn’t factor in breakthroughs. A breakthrough is a fundamental shift in the understanding of a software design. This is a very important step in improving the design, quality and maintainability of the software. If a breakthrough is discovered by the team, then taking the time to refactor should be encouraged. Breakthrough refactorings can be hugely beneficial for the future development of the software.  A burndown can discourage refactoring and improvement by promoting a linear track.

The focus on a burndown is on reaching a predetermined end-point in time. Instead we should be focusing on delivering value to the business without compromising quality.

Experienced teams working on new or familiar software might not have any of these problems. I have been on projects where the burndown was very accurate and the project went very smoothly. But this was not because of a burndown. The burndown didn’t really provide any benefit to the outcome of the project. The project work was easy to estimate and so the burndown was always on track.

I’m not saying never use a burndown. They are often required by project managers to report on progress. Just don’t let it become the focus of the project, as it can potentially do more harm than good.

About these ads

16 Responses to “Are Burndowns Evil?”


  1. 1 Mike Wagg January 19, 2009 at 10:58 pm

    I couldn’t agree more. Burndowns have their place, but the task board should be the main focus both for developers and project managers to see how well the iteration is going as well as the business who should use it to ensure their stories are being correctly prioritised.

  2. 2 Eldon Ferran de Pol January 20, 2009 at 12:36 pm

    I completely agree in the vast majority of cases but would like to outline the one occasion where a burndown was a genuinely positive influence on a project, although slightly irrelevant to the dev team.

    A few years back (you know when Tim) I was on a project where a burndown was used basically to help towards answering the “what is my budget for an agile project where I may stop at any point, constantly reprioritise or may go on beyond beyond what is currently envisaged” question.

    The PM and the customer used a burndown pretty much entirely between themselves as a way of saying if we forecast our stories over x iterations what is my indicative budget for the project. The customer was then able to report up the chain. Everyone knew that this was subject to change both in terms of the order stories may be done in and what would eventually be delivered but it did give an indicative figure for him to work with.

    As iterations proceeded and things changed they would update the burndown inline with each iteration so the customer was always able to say “based on current planning my budget is x”. This worked very well for him but, crucially, only because the entire organistion bought into agile so that was an acceptable thing for him to report upstairs.

    All of this was done outside the iteration meetings and was never used as a tool for nudging devs along. The only impact on the developer was a minor change to stand up routine which was that after the stand up you updated the burndown with how many hours you thought you had left on any given task within that iteration. This took about 2 mins.

    Having said that every other project that I have worked on with a burndown is perfectly described by you above. However, to answer your actual question I will paraphase the NRA’s favourite saying about Guns, Killing and People.

    “Burndown charts aren’t evil, Project Managers are”

  3. 3 timross January 20, 2009 at 1:36 pm

    Thanks for your comment, Eldon. I agree that a burndown chart can be beneficial to a project manager as a way of tracking development progress, as you mentioned above. It just shouldn’t be used drive the development process and should probably be kept invisible to the development team. If things start to go off track the PM can raise the issue, but the development team shouldn’t be driven to cut corners just to get back on the proverbial track.

  4. 4 Eldon Ferran de Pol January 20, 2009 at 2:51 pm

    Whilst being slightly facetious my last comment was really to suggest that burndowns used the way you highlight aren’t really about the burndown at all. It is about some PM’s difficulty in relinquising what they percieve as control in the new agile world.

    Take away the burndown and that kind of PM will probably simply replace it with some other form of mapping the agile world to their long ingrained waterfall tendencies. It takes a very big mind shift to truly adapt which is why you see so many “agile” teams where all that really means is we unit test, have CI, have stand ups and break our eight month project into 2 week chunks.

    What do you think?

  5. 5 Kevin E. Schlabach January 20, 2009 at 3:32 pm

    Tim-

    Your blog makes a lot of good points, but none of them are that burn-downs are bad. Instead I believe you are making points about how burn-downs are mis-used.

    Any metric when mis-used is a problem. PMI and waterfall tend to be horrible experiences because of this same issue (though I prefer agile).

    All I’m getting at is that each of your examples points to a cultural problem that doesn’t go away by removing the burn-down.

    Bad trends in burndowns should be a flag for resetting expectations. When expectations are adjusted (developers, customer, managers), then everyone should know about it (thats why we do sprint planning and review together, right?). This is why I would disagree with you that they should be hidden from the development team. Self-empowered and self-managed teams can only exist if they take on some of the management and projection of their work as a partnership with the upper management team. Most of your debate feels like an us/them argument.

    you said – “a burndown can be very unforgiving”

    “My definition of agile is that you accept input from reality, and you respond to it” – Kent Beck

    To me a burndown is one of many measurements of reality!

  6. 6 zubairk January 20, 2009 at 5:05 pm

    are you sure that shoulnd’t be: “Burndowns don’t kill people, people kill people.”?

  7. 7 timross January 20, 2009 at 9:30 pm

    @Kevin, thanks for your comment. In retrospect, a burndown will always reflect reality. My issue is that a burndown doesn’t always promote reality. It promotes a linear track through an iteration. My main point is that the burndown shouldn’t be the main focus point for the team.

  8. 8 timross January 20, 2009 at 9:52 pm

    @Eldon, I was more getting to the point that over-focusing on a burndown can negatively impact the quality of the software. This applies to the entire team, not just the PM. On past projects I have seen developers that deliberately cut corners just to get the burndown looking better. Staying on the line almost becomes the goal of the iteration.

    I believe Agile is about communication, not about processes. Although any process that helps to facilitate communication is a good thing. As you know, a good PM on an Agile team acts as a facilitator, not a controller.

  9. 9 Eldon Ferran de Pol January 21, 2009 at 12:14 pm

    The reason I focus on the PM in the case of the burndown is because in my experience “over-focusing on a burndown” tends to be driven by a PM. Developers follow that lead. The PM may just be responding to pressures from above but within the development team context I have never seen a dev suggesting hitting burndown is essential while management argues the opposite. The contrary position is common.

    A good burndown is a forecast and a metric of progress that can be extrapolated. Like any forecast it should be modified as reality becomes apparent. It tends to depend on management attitude, not dev attitude, whether this morphs into a target that must be hit or whether it’s accepted that when the burndown goes astray it’s because of predictable errors in estimation and that the burndown (forecast) needs changing to reflect that.

    It is a slightly different subject but I am increasingly realising that management attitude within Agile teams is the most challenging to get right. Developers are natural allies of the agile movement. Management, whilst it may want to be “agile”, has to question very long held, fundamental assumptions about what it means to manage a software project that makes it far more difficult for them to truly embrace. To me, burndown mis-use is just a manifestation of this difficulty.

  10. 10 Clive Skipper April 2, 2009 at 9:38 am

    I have found this discussion very interesting.

    From my point of view, as a PM, I only ever viewed the Burndown as a barometer for the state of the sprint/iteration. It is not a mechanism to track that the team is working. I certainly don’t view the burndown as a means to push the team to deliver the sprint/iteration goal.

    It appears to me that what has been expressed is actually a reflection on the team involved. Does the team feel empowered to use the information presented by the burndown to manage the scope of the sprint/iteration? If the burndown is trending away from the estimated burndown and the team aren’t confident that the stories will be delivered. This situation should be a trigger for the team to discuss with the Product Owner the removal of scope. What you are expressing is that the team do not feel empowered to make that decision and instead “work harder” – read reduce quality – to deliver the sprint/iteration objective.

    The simple fact there seems to be a PM vs Developers suggestion should raise alarm bells.

  11. 11 New Project December 21, 2012 at 2:53 am

    Hi there! I just wanted to ask if you ever have any issues with hackers?

    My last blog (wordpress) was hacked and I ended up losing a few months of hard work due to no backup.
    Do you have any solutions to stop hackers?

  12. 12 apple application support quicktime December 26, 2012 at 9:14 pm

    I want to to thank you for this great read!! I certainly enjoyed every little bit
    of it. I have you bookmarked to check out new
    things you post…

  13. 13 binary options review February 15, 2013 at 1:59 am

    Hi, i think that i noticed you visited my site thus i came to return the choose?
    .I’m attempting to to find things to enhance my website!I assume its adequate to make use of a few of your ideas!!


  1. 1 Evil Burndown Charts « Zubair’s Weblog Trackback on January 26, 2009 at 7:46 pm
  2. 2 Agile: Chasing a points total at Mark Needham Trackback on May 11, 2010 at 10:30 pm
  3. 3 Zubair Khan: Evil Burndown Charts | Software Secret Weapons Trackback on September 23, 2010 at 5:10 pm

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s





Follow

Get every new post delivered to your Inbox.

%d bloggers like this: