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 some calculation of trend lines. This is one occasion where using a tool makes a lot of sense. All of the major Scrum tools generate this graph to some extent. The simplest possible solution is an excel spreadsheet. More complicated graphs are created by Scrumworks Pro, Version One and Rally.
Welcome back. Today I would like to talk about the alternative product burn
down graph. Also known as the alternative release, burn down graph.
This is a graph that was created by Mike Haun [sounds like], and it is by
far, my favorite graph out of all the agile charts and matrix. In order to
calculate this graph, we would calculate the total amount of work in our
product backlog and at the start of every single script. And we would plot
Every time work is then completed by the team, we will take that work from
the top of the graph. So, in this case, you can see that between sprints
one and sprints two a certain amount of work was completed by the team.
Between sprints two and sprints three, again a certain amount of work was
completed by the team. And between sprints three and four, again, work was
completed by the team.
But what do we do about work coming into the product backlog? What do we do
about new stories that are being added by the product owner? What do we do
In this case, what we would do is we would add it to the bottom of the
graph. So, you can see that between sprints one and two, there was no work
added to our product backlog. Between sprints two and three, again no work
was added to our product backlog.
But, between sprints three and four, there was work added to our product
backlog. And again between sprints four and sprints five, more work was
added to our product backlog. We can then draw some trend lines through the
top of the graph. And what we can show is that the team’s making steady
progress in completing that work.
At the same time, we can draw a trend line through the bottom of the graph.
And what this shows us is how the base line of the product has been
changing over a period of time. We can then, use these two trend lines to
extrapolate for when we think we will likely finish this product. The
earliest point that we will likely finish this product is if we hold the
current baseline static. And where that current baseline meets the blue
trend line is the earliest possible time that we will finish this product.
If, however, the baseline of the product continues to change, as it has
done in the past, then the most likely completion date of this product is
where the red trend line intersects with the blue trend line. So, what we
can then do, is calculate the time frame for when we think this product
will be completed. We can provide a time frame from the earliest likely
completion date, to the most likely completion date of the product.
The alternative product burn down graph is really a useful graph because it
shows not only how the team is progressing, but it also shows how the
product owner’s behavior influences the final completion date of the