There’s a Problem with Burndown Charts

Okay. I admit it. I’m not a big fan of burndown charts for tracking software release progress. You can flip them over and call them burnup charts but I’m still not a believer. Here’s why.

The burndown chart has an end goal. That goal is total user story points expected to be delivered for the software release or sprint. At the sprint level, the chart makes sense. Total story points for the sprint should rarely, if ever, change. Once the team has committed to a set of stories for the next sprint, the total number of story points being delivered is fixed — barring unusual circumstances.

Day-by-day the Scrum team can track story points delivered versus story points remaining. At a glance, anyone can get an idea of how much work has been done and how much work remains to be done.

At the software release level, it’s more complex. The total number of story points for a release is rarely a fixed goal — it varies over time. It’s perfectly acceptable for a Scrum team to add or subtract story points during the release cycle as new information becomes available.

Stories may be added or removed. Story points for any given story may increase or decrease prior to the target sprint.

The result is a moving target.

If 100 story points are defined for a release and 50 story points have been delivered, is the team 50% done? At a moment is time, the answer is yes. What if 10 story points are added tomorrow? Suddenly the team is 45% done not 50%.

For that reason, burndown charts serve as an informative look back at the status of a software project. They also help track velocity, which is the best predictor of the Scrum team’s future performance. However, they are a misleading indicator of when the release will be done unless the business agrees to lock down the release backlog — something I would not expect or endorse as it would be anti-agile.

If you’re a fan of burndown charts, there’s no reason to stop using them. You simply need to understand the information being conveyed and how to use it. They represent a statistical tracking tool for agile software development teams, not a project management tool.

photo credit: alexcoitus via photo pin cc

Updated: August 12, 2012 — 10:17 pm


  1. I just ran across this post. I’m surprised no “Agile fan boys” jumped on you. I can see what you are talking about; however, I think there are two counter arguments for burndown charts that I would ask you to consider.


    1. The story points for a release should be fixed based on the teams capacity in story points if there is a fixed release date.

    2. As scope changes, given a fixed time and fixed cost, items as the bottom of the release backlog should fall off the release backlog. Ken and Jeff are advocating just one backlog, the product backlog. That’s fair and I see their point, but by keeping separate backlogs for each of the levels of planning, I can keep items that slip out of scope somewhere and still only focus on what is in scope.

    So, maybe it’s not so much that the release burndown chart isn’t conveying everything you need it to. Most of the electronic tools I’ve seen stink at this. Things I’d want to see are planned, and forcasted (based on a three-iteration running average velocity) zero-crossing points on the burndown. I’d also like the chart to burndown from the planned capacity and then it recaculate over time with a scope line.

    Without these crucial elements, you are correct, it isn’t that useful of a project management device.

    1. Excellent points, Devin. It seems that burndown charts have different meanings among software development teams. Any tool is only as good as the person using it. Any tool should also have a clear purpose. Simply drawing a burndown chart because it is a recommended practice isn’t good enough. I think the potential for misuse is great. I just don’t like them.

Comments are closed.