Overview
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.
Measurement Method
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 Hi-Med-Low complexity. The higher the “points” the
more functionality each work item is worth.
Release Burndown is captured in IBM® Rational® Team Concert® and IBM® Rational® Insight®.
Measurement Analysis
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. The trend line should slope downward as iterations are completed. 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 example, scope changes are plotted as well as burndown.
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.
Metric Pitfalls
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.
Countermeasures For This Metric
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.
|