Scrum Certification: What’s it worth?
06-08-2008Has Scrum Supplanted XP…?
12-08-2008One 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:
- Recalculate the initial total and redraw the chart. Not good. Hides the changes which have been made to the scope.
- 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.
- 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!
19 Comments
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
🙂 – Thank you, Srikanth!
Peter
thanks, it is really a best way of managing the scope changes! I like it a lot.
And again 🙂 – I just wish I knew whom to say ‘thank you’ to!
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.
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
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
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?
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
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.
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.
Thanks for posting the answer!
I'm a lecturer and the students find this much easier to understand – and so do I!
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?
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
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
… who got the idea from Timothy Murry (here: http://alistair.cockburn.us/Burndown+chart+showing+scope+changes). 🙂
Kirk
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.