Release Planning Advice
By: Roman Pichler
Tags: Product Manager, Product Management, Release Management, Product Owner, Agile

Use a Release Burndown Chart to Track Progress

The release burndown chart is a simple yet powerful tool to track and forecast the progress for a release. Despite its usefulness, experience tells me that many Scrum product owners don’t use the burndown. But creating the chart is simple. Start by asking the development team to estimate the total amount of the product backlog items that should be part of the release. Rough, high-level estimates are sufficient. Then draw a coordinate system that takes into account time, captured as sprints, and effort in the product backlog, which might be expressed as story points.

The first data point is the estimated effort before any development has taken place. To arrive at the next data point, determine the remaining effort in the product backlog at the end of the first sprint. Then draw a line through the two points. This line is called the burndown. It shows the rate at which the effort in the product backlog is consumed. It is influenced by two factors: changes in the product backlog and velocity, which is the development team’s ability to make progress. Extending the burndown line to the horizontal axis allows you to forecast when the development effort is likely to finish, or if you are likely to reach the release goal and deliver all relevant product backlog items at a specific date.

The release burndown chart above shows two lines. The solid line is the actual burndown. It documents the progress to date and the effort remaining. The dotted one is the forecasted progress based on the burndown experienced so far. Notice that the burndown in the second sprint is flat. This might be caused by new items being added to the product backlog or the dev team revising estimates.

To achieve a forecast that is as accurate as possible, try the following three tips:

Base your forecast on a trend rather than a single sprint. This usually requires you to run two to three sprints before you can create the first forecast for a release. Consider how representative the burndown of the past sprints is for the remaining sprints. In the example shown above, the second sprint has a flat burndown. This might be due to more items being added to the product backlog based on the first sprint review meeting or the dev team re-estimating items. To get the forecast right, it would be worth considering how likely it is that another flat burndown will occur again and to which extent you should account for it. If you decided that it was highly unlikely to reoccur, your forecast in the sample chart above would probably be steeper. Make sure that you prioritise the product backlog by risk, particularly in the early sprints. This makes it more likely that the backlog changes in the first few sprints and then starts to stabilise. This makes forecasting the remainder of the development effort easier and results in a more accurate forecast.

If the forecast shows that you are off-track, that the burndown is slower than anticipated, then determine the causes. For example, the development team might lack some crucial skills, the team might be too small, a technology might not work as expected, you might have been too optimistic, or the initial estimates might have been wrong. Once you’ve identified the main cause, decide how to respond. The prioritisation of goal, time, and cost recommended above will help you with this.

Note that if you have to push out the release date or make a bigger change to the goal of the release, this may have an impact on your product roadmap and require you to adjust it.