Purpose
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.
Definition
Remaining Estimated Effort Hours is calculated by the following:
-
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®.
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 occurring 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.
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.
Frequency and reporting
The team monitors this metric daily to understand how much more work is left to complete in the iteration. At the
end of the iteration, this report is used to identify trends.
Collection and reporting tools
IBM® Rational® Team Concert® collects data for this metric.
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.
|