The iteration burndown is a primary tool for understanding the status of an iteration. It shows the trend for how much
work is left to do within that iteration. This is done by adding up the estimated effort left for each of the work
items to be addressed within the iteration, and showing how the estimated effort is changing over the duration of the
iteration. The iteration backlog should be updated frequently, ideally daily.
Factors that impact the team’s assessment of work left include:
-
Work has been completed, which means that less work is left to do.
-
The developer responsible for a work item changes their assessment of effort required to complete the work item.
This should be expected, since we typically understand what it really takes to complete a task first when we have
done a subset of the task. Especially, it is common that estimates of work left increases in the beginning of the
iteration, especially for inexperienced teams, since they often underestimate efforts. As teams become more
experienced, you would expect that they may still have to modify estimates, but the modifications are as frequently
upward as downward.
-
Estimated effort left can increase during the iteration, as a result of the team learning more about what needs to
be done.
Daily or frequent updates to the iteration burndown allows the team to react to changes, by for example cutting scope
by removing work items from the iteration, by reducing the ambition level associated with a work item, or by finding
more clever ways of approaching work items, such as having an expert team member help out with troubled work items.
See ex_iteration_burndown.xls for an example
iteration burndown report.
|
