Release Burndown

On a Scrum project, the team tracks its progress against a release plan by updating a release burndown chart at the end of each sprint. The horizontal axis of the sprint burndown chart shows the sprints; the vertical 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, team days, and so on. My preference is for story points, for all of the reasons described in the Agile Estimating and Planning book.

On this agile burn chart, the team started a project that was planned to be eleven two-week sprints. They began with 200 story points of work. The first sprint went well and from the chart you can infer that they had around 180 story points of work remaining after the first sprint. During the second sprint, however, the estimated work remaining actually burned up. This could have been because work was added to the project or because the team changed some estimates of the remaining work. From there the project continued well. Progress slowed during sprint 7 but then quickly resumed. All this information is clearly visible on the release burndown and the team can easily keep track of everything that is going on in a sprint burndown chart.

This type of release burndown chart works very well in many situations and in many teams. However, on projects with lots of changing requirements you may want to look at an alternative release burndown chart as a way of keeping your agile project on track. The agile burn chart is an essential part of any agile project and is a way for the team to clearly see what is happening and how progress is being made during each sprint.