Hello again. Let’s now talk about the product burndown graph. The previous
graph that we saw, the sprint burndown graph, was the total amount of work
outstanding throughout the duration of one single sprint. The product
burndown graph is the total amount of work remaining, on a sprint by spring
basis, over the duration of several sprints. Then, we describe briefly how
we would calculate this graph. At the start of our single spring, we would
go to our product backlog and calculate the total amount of work
outstanding. Then we would plot this amount. Let’s say, for example, that
the team has completed four sprints. Then, we may have a graph that looks
We can now say that between sprints 1 and sprints 2, the amount of work
completed by the team is simply the heights between the tops of the graph.
Similarly, we can say between sprints 2 and sprints 3, a certain amount of
work was completed by the team. Also between sprints3 and sprints 4, even
more work was completed. We can now generate a trend line through the top
of the graph, or we can extrapolate a date when we think we might finish
This graph only shows part of the story. What about new work coming in?
What about work that has been re-estimated by the team? What do we do with
that work? In this particular graph, it’s difficult to actually see that
work. What we actually see between the differences in the heights of the
bar graph is the net amount of work that is completed by the team.
We can’t see explicitly how much work there was done by the team versus how
much work was added by the product owner to our product backlog. This graph
does work very, very well. It used to be my favorite style of graph.
However, about five or six years ago, I was introduced to Mike Cohn’s
alternative product burndown graph. I’ll show you that graph next time. In
the meantime, let me show you some different styles of product burndown
Agile, Scrum, Agile, Software, Project, Management, Agile, PM, Agile, Project, Management