Release Burndown
This metric tracks the estimated functionality yet to be implemented for the current release.
Main Description

Purpose

Release burndown shows the estimated functionality remaining to complete the current release. It provides answers to the following questions:

  • When can a release be completed based on the team's previous progress?
  • What progress was made in previous iterations?
  • Is the team's velocity sufficient to complete the release on time?

The Release Burndown chart provides a broad view of a release's progress. It is updated once each iteration, and indicates if the team is creating functionality at a reasonable pace. It can also expose projects whose scope is out of control, negatively impacting burndown. Based on the trend view they see in this chart, the team can take action to better control scope, or can adjust resources, budget, timelines, quality levels or commitments.

Unlike Iteration Burndown, which tracks remaining effort hours, Release Burndown tracks functionality in order to determine whether the team is delivering working software in each iteration. The resulting Release Burndown chart helps determine how much functionality the team is creating compared to how much they promised to create.

By tracking this metric, the team can also prove they are adopting iterative development best practices.

Definition

Remaining functionality is calculated by:

  1. Identifying a work item type as representing top-level functionality
  2. Creating a complexity estimate for each top-level functionality work item
  3. Totaling the remaining complexity for work items that are still open


Top level work items are work items that represent significant units of scope. The most typical top level work items are use cases, features, user stories, stakeholder requests or defects. They have a complexity attribute, but not an effort hours estimate. Thus, these top level work items represent functionality.

Complexity is an attribute of each functionality work item and is described in terms such as use case points, feature points, user story points, stakeholder request points, or High-Med-Low complexity. The higher the "points" the more functionality each work item is worth.

In a release burndown chart, the Y axis shows the remaining functionality for the release, and the X axis shows all the iterations planned for the project.

Analysis

Using Release Burndown to monitor project execution

Release Burndown is used as a project execution metric to help a team monitor and steer their project performance. It is an indicator of overall progress to middle management (project manager and product owner) and development executive audiences. Middle management can use this metric to monitor how the project is progressing against plan, and predict whether the team will meet release commitments. Release Burndown can be used to re-plan the release when the project is behind schedule, or to help plan resources needed for the release.

Expected trend - The trend line should slope downward as iterations are completed indicating that remaining functionality is decreasing. However, the following patterns might occur:

Rising slope - This trend can indicate that the project is out of control, with poor product management. If a team sees an ongoing rising slope, then they need to focus on the best practices of Inception and Elaboration in order to regain control. Consensus may not have been reached regarding the objectives for the project, and requirements may not have been sufficiently detailed to understand architectural risk or to properly plan.

Flat line - This trend could indicate that the team has not embraced iterative development best practices. It could be that the team is not delivering working software. Or, the team is delivering working software but new functionality is added to the release equal to the rate that work is completed. In some cases, the team has to focus too much of their time on defects. Measures should be taken to increase quality when this occurs.

Perfect downward slope - Unlike a perfect slope in Iteration Burndown, which could indicate a team that is inaccurately charting their results, a perfect downward slope in Release Burndown is likely to be accurate. Validate that Customer Satisfaction and Quality levels are high, and that Change Request Aging is low to confirm the trend.

Fast decline at the end of the release - This is a pattern that should be monitored closely. When the trend line is clearly not heading to zero for the release, but the slope quickly drops to zero at the very end, a number of factors could be involved. Perhaps through heroic efforts the team increased their productivity to meet their commitments. But, it could be the case that important features were left out of the release, or requirements for shipment changed. This is acceptable when stakeholders decide that scope is less important than the timeline.

Fast incline at the end of the release - This trend is unlikely to occur unless (either intentionally or by accident) the metric was not tracked correctly in each iteration. Or, it could be that product management is out of control, and last minute requirements were added to the release. If this is the case, ask the customer if scope or timeline is the priority for the release.

The release burndown chart that follows is a simple example of tracking the release burndown rate. Based on the trend indicated in this chart, the project looks like it will finish before I8. Assuming that I8 is the last iteration for this release, the project is well positioned to meet its release commitments.

Notice that this graph shows "instantaneous velocity," the velocity just by looking at the last two iterations. Also of value is "average velocity" which would be the average velocity considering all past iterations.

Release Burndown

In the following release burndown example, scope changes are plotted as well as burndown. Note that the blue line represents remaining work whereas the gray line represents planned work.

Release Burndown With Scope

The gray line indicates that this team did not estimate the complexity of all of their top-level items up front; or, they allocated more and more to the release as time went on. Their scope has increased from about 4 units to nearly 80, or 2000%. The gray line shows that now their scope is stabilizing. The blue burndown line shows that real burndown is starting to occur.

Using Release Burndown to monitor capability improvement

Release Burndown is also used as a capability improvement metric. It helps a team and middle management (project manager, product owner) monitor improvements made during the project lifecycle in adopting the Release Planning practice. If teams are adopting these practices by performing two-level project planning and updating plans to reflect changing business priorities and needs it will be reflected in their Release Burndown trends. Operational Executives can also use this metric to monitor systematic improvement in reducing time to value across the organization by adopting Release Planning.

Expected trend - If teams are successfully adopting Release Planning, Release Burndown trends will show that functionality slopes downward as iterations are completed in a steady decline to zero at the end of the release.

Rising slope - When teams routinely display a trend line with a rising slope, it indicates that there is a problem with Release Planning adoption. Teams may not be collaborating effectively with stakeholders to update plans based on actual progress in each iteration. Or the team and stakeholders may not share a common understanding of project objectives.

Frequency and reporting

Data is collected at the end of each iteration. The resulting Release Burndown chart is shown by a team lead or project manager for review by the team and stakeholders at the end of each iteration to help identify trends. Release Burndown for multiple projects can be rolled up in order to monitor improvement across the organization.

Collection and reporting tools

Release Burndown is captured in IBM® Rational® Team Concert®. IBM® Rational® Insight® reports on this metric.

Assumptions and prerequisites

  • The product owner sorts the product backlog into priority order and shuffles the product backlog items as priorities change from iteration to iteration.
  • Release planning is performed and the release has been defined.
  • Iterations have been scheduled and features to deliver during each iteration have been documented as work items.
  • User stories or use cases have been elaborated with relative points assigned to each
  • The team is delivering working software in each iteration.

Pitfalls, advice, and countermeasures

  • Although planning and executing at the iteration level is very important, teams should not lose track of where they are in context of the overall release plan. In their desire to make sure iterations are successfully delivered, some teams may lose sight of their progress against the release goals. Additional scope may continue to creep into the plans as the team progresses forward. As a result, each individual iteration appears relatively successful to the team, but the higher level goal of delivering the overall release is sometimes forgotten and changes in the release plan are not communicated to the organization.
  • In some cases, a team might get very good at capturing and reporting burndown accurately, but may not know how to take action to improve based on what they see in their trend line. When this happens, deeper analysis is needed to find the underlying cause of the trend, so that corrective actions can be taken. It might be necessary to abandon the metric if the team is unable to use the measurements to incrementally improve.
  • If the team discovers a trend of addressing low risk items first, leaving higher risk items to the end, a Backlog Complexity metric could be tracked as a countermeasure. Backlog Complexity should be dropping, but will remain high if the team has a habit of addressing high risk items late in each release.
  • For additional analysis, combine Release Burndown with Iteration Velocity in order to estimate potential finished date.


More Information
Concepts