Skip to main content

Towards a better burn down chart

One of the most important advancements of Scrum and XP compared to other frameworks is the use of a burn down chart rather than milestones to measure progress. It is simple and clear, measures real progress, but has one problem, how do you show scope changes?

Jürgen at ASD recently summarized a couple of alternatives for maintaining the release burn down chart. I suppose every Scrum Master has their way of doing things, so here's mine...

What is a a burn down chart?

As a pilot, I like to think of a burn down chart as being like the glide path of an airplane on final approach. An instrument in the cockpit tells you if are above or below the ideal glide path. If you are stabilized on the glide path (usually 3 degrees at a big airport) you will hit the runway at the designated touch down point. If you are too high, you will not make it to the runway unless you increase the rate of descent (which is not always easy to do). If you are too low, watch out for the trees!

A burn down chart tracks how much value has yet to be delivered. So at the start of the project, you make an initial estimate of each feature in Story Points and add up all the features to get the total, say 120 Story Points. Then after each Sprint and for each story that is done, you deduct the story points for those features from the total.

What if your won't make your deadline?

So if you have a total of 120 Story Points and you finish 10 Points in the Sprint, you would expect to need 12 Sprints to complete the project. If your planning calls for 6 Sprints, you have a problem. So you work on improving your velocity (e.g. by removing impediments) and reduce the scope.

Improving your velocity is like increasing your rate of decent. Removing Scope is like magically moving the airplane closer to the ground by adjusting the altimeter (works great in the flight simulator, but not in a real airplane).

Tracking Scope in the Burn Down Chart

Which brings us back to the question, how do we show changes of scope on the burn down chart? Jürgen summarized the alternatives:
  1. Recalculate the initial total and redraw the chart. Not good. Hides the changes which have been made to the scope.

  2. Create a "burn-up" chart as proposed by Alistair Cockburn. He proposes adding a 100% line which moves up and down as the scope changes. His concept is "earned value". The analogy becomes climbing a mountain rather than landing an airplane.

    Perhaps if I were a mountain climber I would have a different attitude (and I do admit, "upper right" is generally good in business graphics), but the idea that the height of the mountain is going to change is somehow counter intuitive.

  3. Move the target line above or below the origin as the scope changes. Our airplane is still landing, but we change the altitude of the airport (You can't even do that in a flight simulator!). Again, it works, but for me it is counter intuitive. Explaining a target that is less than zero can also be a challenge.

A Better Burn Down Chart

I have used the following "flight simulator" approach in the last few projects and find it satisfying.
Progress is graphed on a burn down chart. The target is 0 Story Points. The results of a Sprint are plotted at the end of the sprint. This line usually has a downward slope, worst case is horizontal if no progress is made Then any changes to the scope are applied. This is a vertical line, up for added scope, down for removed scope. It's as if the airplane were repositioned up or down while on approach.

    In the example, you can see that the Team was initially slower than planned -- a common problem. After two Sprints, the response was to reduce scope and increase velocity (e.g. by removing impediments or adding capacity). After four sprints it was clear that they were in good shape and could take on some additional functionality without risking the release date.

    The advantages of this approach? It doesn't require any redrawing. There is no need to explain negative number targets — the target is always zero. It is clear whether the product owner (vertical change) or the team (sloping change) has changed the amount of work remaining.

    It is easy to graph on paper or with Excel (use an X-Y line plot) so give it a try and let me know what you think!


    Srikanth said…
    Thanks Peter. Burn down chart proposed seems more intuitive than other options I read about. I am, at present, doing some reading in order to introduce agile steps in my project. You article helped me a great deal!.

    Peter said…
    :-) - Thank you, Srikanth!

    Anonymous said…
    thanks, it is really a best way of managing the scope changes! I like it a lot.
    Peter said…
    And again :-) - I just wish I knew whom to say 'thank you' to!
    Anonymous said…
    There's a problem with that kind of chart though: when you do a post mortem, you can't easily say whether the cause of the slow/fast rate was increased speed of the team or changes in scope. In some situations, changes in scope do happen and that needs to be accounted for. That's why the changing baseline and changing 100% lines were proposed.

    But if you can guarantee 100% that the scope of the project will not change over time, then I guess the one you proposed above will do.
    Peter said…
    Hi Mark,

    Changes in scope are shown by vertical lines on the chart. Velocity is represented as the slope of the (non-vertical) lines connecting the sprints.

    So you can clearly see changes in scope and changes in velocity.

    The total impact of the changes in scope is simply the (vector) sum of the height of the vertical lines.

    You are correct that the chart does not show the cause of anything, only the impact of scope and velocity changes. So you see what questions to ask.

    Hi Peter,

    Can you please provide a sample Excel file that builds a chart like the one you're talking about?

    Thanks for posting on this topic. My team is asking for this information to be displayed in the burndown chart, and I think you've got a great solution here.


    Peter said…
    Hi James,


    The original Better Burn Down Chart in OpenOffice .ODT format as well as an exported .XLS file are now online for download.

    BTW - Your blog looks delicious! Do you use Scrum for cooking, or what's the connection?
    Thanks for the files, and for checking out my blog.

    My food blog is somewhat unrelated to my job as a software engineering manager, although I tend to use an inordinate number of "pizza" references when doing product demonstrations :-)


    Unknown said…
    how did you get excel to draw the "ideal line" by only providing the start/end point? when i opened the XLS file you provided the ideal line wasn't showing so I had to go fill in the numbers.
    Unknown said…
    nevermind, in Excel (2007 at least) you can right-click on the chart, choose "Select Data Source" and then click on "Hidden and Empty Cells" to tell it to fill the line in when data is missing.
    Peter said…
    Thanks for posting the answer!
    pd said…
    I'm a lecturer and the students find this much easier to understand - and so do I!
    Unknown said…
    I think it's better to use online tools for that so it's easier to share with teammates and managers.

    For the rest we like to use real boards and post-its.

    Try this one

    This is what a chart looks like:

    Isn't it simpler?
    Peter said…
    Hi "Unknown"

    I came real close to calling the last comment spam. But I have a weakness for two guys posting something on the web for free :-).

    The demo doesn't show how to handle scope changes. I think it important to distinguish between progress made by the team (burn-down) and changes made by the product owner.

    For some thoughts on whether to use electronic or tangible tools, check out my "Rock, Paper, Scissors"articles on the relative merits of various approaches. For a list of tools, see Directory of Scrum Management Tools
    KirkBryde said…
    Peter said: ... I just wish I knew whom to say 'thank you' to!
    13 October, 2008 13:45

    It's 5 years later, but you might want to thank Alistair Cockburn, who published a burndown chart like yours in 2006 here:

    KirkBryde said…
    ... who got the idea from Timothy Murry (here: :)

    Peter said…
    Hi Kirk,

    Thanks for pointing out the previous references!

    My own thinking is evolving on this. In my own work, I am getting away from using estimates and burn down charts, but focusing on keeping features small and getting them really done.


    I hear you on managing by feature. Most Agile teams have a good handle on keeping stories small and getting them done by end-of-Sprint. But if a feature is defined as a deliverable (realistically, more deliverable than a single story) chunk of software that consists of multiple stories, then stepping it up a notch by focussing on smaller features and getting them delivered is good - very good.

    This is actually central to Dean Leffingwell's SAFe - the Scaled Agile Framework. SAFe is much more than just managing by feature, but managing by feature is one of its cornerstones.

    Burnups (or burndowns) by feature will help you visualize the progress of the team's feature-by-feature progress over a release. Tracking a release with a big visible burnup (or burndown) chart by feature (vertical axis being story counts; horizontal axis being Sprints) is a way for the team to recognize the importance of finishing each feature asap, and incrementally delivering feature-by-feature rather than story-by-story.

    Popular posts from this blog

    Sample Definition of Done

    Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
    Project Manager: Is this function done?
    Developer: Yes
    Project Manager: So we can ship it?
    Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

    At its most basic level, a definition of Done creates a sh…

    Explaining Story Points to Management

    During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

    Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

    The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

    Money for Nothing, Changes for Free

    “Money for Nothing, Changes for Free” encourages both customers and suppliers to focus on value.

    A key advantage of Scrum projects is that at least once per sprint you have something that could be shipped and no work in progress. You can change direction every sprint, and you can reevaluate whether the project is a good investment or if your money could be better spent elsewhere. Abrupt cancellation is risky for the supplier.

    While the concept of an early-exit penalty is not new, Jeff Sutherland gave it a unique allure with his allusion to the Dire Straits hit.
    Desired Benefit Incentivize both customers and suppliers to focus on functionality that provides genuine value.
    Structure This works with Agile software projects because there is little or no work in progress. After each Sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budge…