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…
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.
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).
Which brings us back to the question, how do we show changes of scope on the burn down chart? Jürgen summarized the alternatives:
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.
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!