Iteration Burndown
This metric tracks remaining estimated effort hours in an iteration. It is calculated and graphed daily in an Iteration Burndown chart to help a team monitor their progress for a given iteration.

Main Description

Overview

Iteration Burndown helps a team understand the status of an iteration by showing how much work is left to do. It enables the team to adjust scope or resources to finish the iteration successfully.

An Iteration Burndown chart is updated each day with the estimated work remaining in the current iteration. Ideally, the amount of remaining work decreases as development progresses until it reaches zero at the end of the iteration.

Unlike release burndown and product burndown which both track functionality, iteration burndown tracks remaining effort hours in order to maximize the productivity of the team and predictability of how much work they can perform.

Measurement Method

Remaining Estimated Effort Hours is calculated by:

  • Allocating work items in the work items list to the current iteration
  • Creating an effort hours estimate for each allocated work item
  • Totaling the remaining effort hours estimated for work items that are still open

Note that you may be working with a product backlog of functional requirements, work items of both functionality and project tasks, or even with multiple work item lists, each dealing with different complexity factors (such as distributed development or compliance issues).  Regardless of the types of work items in the backlog, the recommendation is to graph effort hours remaining over time.

Iteration Burndown is captured in IBM® Rational® Team Concert® and IBM® Rational® Insight®.

Measurement Analysis

Use a line chart to represent the Iteration Burndown.  The Y axis shows the remaining estimated effort hours for the iteration. The X axis shows all of the days (past and future) in the iteration. The trend line should slope downward as time progresses. However, the following patterns might occur:

  • Rising Slope: This pattern happens when there are additional work items (such as tasks and defects) identified after iteration planning.  This is not always a bad thing. It is the nature of software development; but, it is important to only consider adding work items that are related to the iteration goals. The team also needs to focus on prioritizing the work items and making sure that higher priority work items are completed first. Teams might also see a rising slope when their estimates increase as the iteration progresses.  This is another common pattern in software development, as teams are rarely perfect in their estimating.  However, this pattern should generally be avoided, especially at the end of iteration. The team may need to perform some re-scoping to get back on track if their Iteration Burndown chart displays a rising trend line.
  • Flat-line: This pattern can occur when there are defects or rework work items that prevent the team from moving forward. This could indicate the team needs to place more focus on quality.  This pattern is also seen when the rate that the team completed work items is equal to the rate that  new work items were added to the work items list.  If this trend continues, the team will not reach its iteration commitments without rescoping.  In extreme cases, the team might not be performing any work at all, resulting in a flat trend line. Immediate action must be taken to determine the reason that productivity has stalled.  Another cause of a flat trend line is a reduction in resources or team members.  This scenario requires rescoping or backfilling the missing resources. Yet another cause of this trend line is work items that are too large in scope. The team may need to create smaller work items so that the burndown chart reflects that work is being completed.  
  • Perfect Downward Slope: This trend represents the perfect project with a trend line sloping in an even descent toward completion. Most projects experience some changes in their rate of progress along the way due to normally occuring factors. A perfect trend could indicate that the team is working in a very controlled, non-trusting environment where they feel uncomfortable communicating their true status.
  • Dramatic Upward Slope at the End of the Iteration (Hockey Stick): This trend typically indicates a surprise at the end of the iteration.  The team might have pushed high risk items to the end of the iteration, waiting too long to seek clarification. Or, the scope of the iteration changed late in the iteration. A sudden increase in the amount of outstanding work very late will make it difficult for the team to meet its commitments for the iteration.  This trend should be raised and resolved as part of the retrospective.

The following Iteration Burndown chart example displays scope changes and burndown. The graph plots two lines in this example of an in- progress iteration.

                            Iteration Burndown With Scope

The bold blue line shows the amount of work left by plotting remaining estimated effort hours from open work items only.  Notice that this line can go up as more work items are created for the current iteration or if estimates are increased.  When this line drops it can be either because work items were closed or removed from the iteration.

The gray line shows the total work for the iteration by plotting effort for open plus closed work items.  This line does not slope downward as work is completed unless the remaining Estimated Effort Hours goes down.  This happens only if estimates are reduced or work items are removed from scope.  In a perfect plan, the gray line would be perfectly horizontal , but that is extremely rare, especially in early iterations. Notice that this happens near the end of the graph.

The variance in the plan can be also measured in this graph. According to the gray line, this team originally planned for roughly 2000 hours of work, but are currently planning for about 3200 hours, or 60% more than originally planned at this point in the iteration. If this were the end of the iteration, the team would actually have completed 2400 hours of work (3200 gray line minus 800 dark blue line = 2400 hours closed) That would be 20% more than they had originally planned.


Measurement Pitfalls

Following are some things to look out for when tracking Iteration Burndown:

  • In non-trusting, highly controlled environments, teams might fear they will be judged and punished for less that stellar results. This can lead to inaccurate burndown tracking to avoid negative repercussions.
  • In theory, a team could simply adjust the end date of the iteration if their burndown trend indicates they will not meet their iteration commitments.  Instead, scope should be allocated to subsequent iterations, and the overall project plan adjusted for scope, resources, end date, or quality based on those reallocations.
  • 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 their productivity.

Countermeasures For This Metric

  • When a team has a perfect or near perfect downward sloping trend line, they may have refused to add any new requirements to an iteration in order to preserve their positive burndown results.  If this is happening, a subjective measurement for Customer Satisfaction can be added to the iteration.  When stakeholders do not see their requests addressed, their satisfaction with what was delivered for the iteration will be low. A Change Request Aging metric can also be used in these situations. This metric will be higher if teams are routinely refusing to add any new requirements to the iteration.
  • If the team discovers a trend of addressing low risk items first, leaving higher risk items to the end of the iteration, a Backlog Complexity metric could be tracked as a countermeasure.  Backlog Complexity should be dropping in each iteration, but will remain high if the team has a habit of addressing high risk items late in each iteration.
More Information
Concepts