Similar to the Sprint burn-down graph, the Product burn-down graph is a way to track progress. In this case we’re tracking progress against the entire product that we’re building. The example that I use in this video was very popular several years ago. Since then, Mike Cohn’s Alternative Product Burndown graph has become more popular, and that’s the topic of the next video.
Until then, here’s the traditional way of building and using a Product burn-down graph.
Transcript
To plot this graph, the team would calculate the total amount of work remaining in the product backlog and plot this as a bar graph at the start of each sprint, for example here our team has completed four sprints, during each sprint an amount of work was completed reducing the height of the bar graph.
Our example teams for the Product Burndown Graph may look like this. By referring to the difference in bar heights between sprints one and sprints two, we can see an amount of work was completed from the Product Backlog. Similarly between sprints two and sprints three, further work was completed and between sprints three and four yet more work was completed.
We can now project a trend line through the top of graph as extrapolate a date when we think we might finish the product. But what happens if new work is introduced into the Product backlog by the product owner? What happens if work is re-estimated by the team? How do we account for this changes? although this graph works well, it is limited in presenting the full scope of changing conditions faced by most Scrum teams.
A better solution to this problem Scrum is Mike Cohn’s Alternative Product Burndown graph. This is the subject of our next video. Here are some common examples of Product Burndown Graphs.
