For Product Owners, a release burndown chart shows a single value — the net change in the amount of work remaining. In some cases, the simplicity of this is wonderful. However, it can also mask what may be going on in development of a product.
For example, a team had expected to make progress of 40 Story Points last Sprint, but the burndown chart only shows net progress of 10 Story Points. Was the team slower than expected, or was more work added?
It’s important to know the answer to this question, because we cannot really predict when value can be released without it. With this in mind, Mike Cohn uses the following type of burndown chart:
On this burndown chart, the height of each bar represents the amount of work remaining in the release. This figure shows a release with 175 Story Points planned in it as of Sprint 1.
The team finished 25 Story Points in Sprint 1, leaving 150 to go as of the start of Sprint 2. There were 120 Story Points as of the start of Sprint 3. So, the top of the bar is reduced by the amount of work the team finishes in a given Sprint.
Before the start of Sprint 4, the Product Owner added new Stories to the product. This additional work is shown at the bottom of the bar for the fourth Sprint. You can see that the vertical height of Sprint 4 goes from about -40 to about 95, or 135 Story Points of work remaining. Forty of those 135 Story Points are from new work.
Prior to the start of Sprint 6, Stories were removed by the Product Owner. As with an increase in scope, a decrease in scope comes off the bottom.
One way to forecast how many Sprints a team will take to get to a release will take is to draw a trend line through the bars and extend the baseline.
A problem with this is that predicting the end date as above does not include the rate of change to the Product Backlog.
The Product Owner can anticipate the number of Sprints needed by also drawing a trend line through the changes occurring at the bottom of the bars as shown below:
The Product Owner is likely the person who will be using burndown to both manage and order their Product Backlog as well as use it to report on progress of a release. Typically, Developers will update their charts as work is completed, some software packages will do this automatically, however in some Scrum Teams, updating these charts falls to the Scrum Master.
Download Mike Cohn’s Excel spreadsheet for capturing and displaying release burndown from his website.
Adapted from: Cohn, M. (2022) Alternative release burndown chart. Online at: https://www.mountaingoatsoftware.com/agile/scrum/scrum-tools/release-burndown/alternative
All fields are required.