This article is part of my online newsletter called the Scrum Addendum. If you enjoyed this article you should signup for the complete series.
This week, we’re going to look at the Enhanced (or Alternative) release burn down graph ,, which is one of my favourite tools. If you’d like a refresher on burndown graphs, my online intro to Scrum describes them in two parts:
* Scrum 101 – Part 6
* Scrum 101 – Part 7
Release burn down graphs demonstrate three things very clearly:
- The rate at which work is being completed by the team
- The rate at which new work is being added to the product backlog
- A way to determine a date range for completion.
At first, a release burn down graph can appear quite chaotic, but once the trendlines are drawn, the intent of the release burn down graph becomes clearer. You can clearly see how work is completed (top trend line), and how work is being added to the backlog (bottom trend line). Here’s a typical example of a release burn down:
When observing the trendlines there are three interesting patterns, each of which is discussed below.
Converging trend lines
This is the ideal scenario. It shows that work is being completed (top line) faster than work is being added (bottom line). As a result we can project to where the two lines cross, and thus when the project will be completed.
Converging trend lines for burndown graphs is a good thing, and it’s what you want to see. Be aware that many teams take two or three sprints before than have sufficient data to be able to predict an end date.
Diverging trend lines
Diverging trend lines are actually quite common, especially during the first few sprints when the scope of the project is still not fully understood and the product backlog is undergoing major revisions. It shows that work continues to be added to the backlog faster than it can be completed. If the divergent trendlines continue, this may be a cause for concern. Effectively controlling any increase in scope is key to turning this scenario around.
Parallel trend lines
This is interesting because it tells us that work is being added to the project at the same rate as it’s being completed by the team. In this scenario, the team clearly has no end in sight. Teams that are the first responders to critical application failures often have this type of product burn down graph.
And, this style of graph is not a problem provided that you’re fully aware that there’s no end point for the team’s work.
I hope the last few emails have given you some ideas on fine tuning your Agile projects. Coming up next, I’m going to look at other topics that many Agile organizations have faced or thought about, giving you my take on what works and what doesn’t. In the next email I’ll look specifically at dog-fooding, which is a common practice in which users use the products they develop. While there are benefits to this approach, it needs to be approached with an emphasis on delivering high quality software to be effective.