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:
-
Identifying a work item type as representing top-level functionality
-
Creating a complexity estimate for each top-level functionality work item
-
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.
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.
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.
|