Let's Take a Look at an Example
To enable the project team to monitor their progress against the release plan they must maintain a release burndown chart after each sprint.
The X-axis of the release burndown chart shows the sprints; the Y-axis shows the amount of work remaining at the start of each sprint. Work remaining can be shown in whatever unit the team prefers--story points, ideal days, etc. I prefer to use story points as they tend to focus the team as to complexity as opposed to task related time units.
In the simple example shown in the diagram on the left, there are 8 two-week sprints. The total number of story points for the release is 240 and the team’s velocity has been estimated at 40 story points.
The first sprint went to plan and the team reduced the number of story points by 40 leaving 200 story points remaining at the start of sprint 2. In the second sprint, the product owner added more work (30 story points) and added a further 20 story points worth of work in sprint 3. In sprint 5, the team had under-estimated some work and only managed 10 story points. And in sprint 6, the product owner removed 40 story points worth of work from the release. The remainder of the release progressed well, completing the release at the end of sprint 8.
For the average project, this type of burndown chart gives the right amount of information to the team, product owner and scrum master. There are however situations, especially when dealing with projects that will involve significant change, where there needs to be an alternative view because without the extra information that I told you in the previous paragraph there would be no way that you could extrapolate that type of detail out of the graph.
Mike Cohn defines an alternative burndown chart that presents the information in a clearer format. I use this format a lot as it can quickly be interpreted and highlight any issues during the release and identify any significant deviations within the release plan.