Scrum Certification: What’s it worth?06-08-2008
Has Scrum Supplanted XP…?12-08-2008
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:
- 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!