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!

    Comments

    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!.

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

    Peter
    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!
    Mark 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.

    Cheers,
    Peter
    The Fresh Chef said…
    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.

    Best,

    James
    Peter said…
    Hi James,

    Sure!

    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?
    The Fresh Chef said…
    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 :-)

    Cheers,

    James
    codecraig 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.
    codecraig 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
    http://www.burndown-charts.com

    This is what a chart looks like:
    http://www.burndown-charts.com/teams/dreamteam/sprints/demo

    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: http://alistair.cockburn.us/Earned-value+and+burn+charts

    Kirk
    KirkBryde said…
    ... who got the idea from Timothy Murry (here: http://alistair.cockburn.us/Burndown+chart+showing+scope+changes). :)

    Kirk
    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.

    Best,
    Peter

    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…

    Scaling Scrum: SAFe, DAD, or LeSS?

    Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

    Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

    How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

    Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…

    Five Simple Questions To Determine If You Have the Agile Mindset

    My company has started a top-down transition to Scrum and Kanban. Will that make us an Agile company? About 2 years ago, I attended a conference hosted by the Swiss Association for Quality on the topic of Agility. As a warm-up exercise, the participants were given the 4 values of the Agile Manifesto, then asked to arrange themselves in space. How Agile is your company? How Agile do you think it should be? Very Agile on left, very traditional on the right. There was a cluster of people standing well to the right of center. “Why are you standing on the right?” It turns out that they were all from the railway. “Our job is to run the trains on time.” They were uncertain whether this agility thing was really aligned with their purpose.
    Is Agility limited to software? Steve Denning has collected the evidence and laid out the case that Agile is not limited to software, nor is it merely a process, nor is it something you can do with part of your time, nor is it something you can have your …