Mike Cohn’s Alternative Release Burndown graph is my preferred burndown graph. It’s simple, clear and offers a wealth of information. This lesson is all about the Alternative Release Burndown. After watching the lesson you may also want to read Mike’s summary, which you can find here: http://www.mountaingoatsoftware.com/scrum/alt-releaseburndown
Creating this graph is a little bit more complicated than a Sprint burn-down graph. There needs to be a record of work created, work completed and calculation of the trend lines. The simplest solution is a spreadsheet, and I’ve created a Google spreadsheet for you to explore. I also wrote a full article explaining this graph in detail.
But before you dive into the details, let me explain how the graph is structured and how it can be used:
Transcript
Thereafter any work completed by the team is taken from the top of the graph. You can see the amount of work completed by the team by the differences in heights in the bars. In our example, between sprints one and sprints two, work was completed by the team between sprints two and sprints three again work was completed by the team.
And between sprints three and four, more work was completed by the team but what happens if work is introduced into the product backlog? What do we do about new stories added by the product owner? How is this handled? Work added into the product backlog is added to the bottom of the bar graph. For example no new work was added to the product back log between sprints one and sprints three, however between sprints three and four there was work added to our product backlog and similarly between sprints four and sprints five.
If a trend line is drawn to the tops of the graph it shows the team is making steady progress in completing the work in the product backlog, it shows the rate in which work is being completed by the team, if the trend line is projected through the bottom of the graph, it shows the rate at which the work is being added to the product backlog by the product owner.
These two trend lines can then be used to extrapolate for completion date of the product. If the product backlog remains static, the earliest completion date is where the current baseline meats the blue trend line. If however the baseline of product backlog continues to change, then the most likely completion date will be at the intersection between the blue trend line and the red trend line.
The alternative burndown graph can be used to provide a time frame for when the product is likely to be completed, between the earliest completion date and the most likely completion date. It is a useful tool because it shows how the team has been progressing but also illustrates how the product owner’s behavior can influence the final completion date of the product.
In our next episode we will look at Extreme Programming and Scrum, until then thank you for your time.
