Overview
A burndown chart shows the team's progress. It shows a trend view of work items being assigned and completed during a
given time. This chart needs to be continuously tracked. This chart can be used to track iteration progress or
project progress. It provides the answers on the following questions:
-
What is the ideal progress based on its duration and assigned effort?
-
When the iteration or project could be completed based on previous progress?
-
What is the most possible team velocity in future iterations?
Measurement Method
Count:
-
Number of opened Work Items (WI) during time i
-
Number of added WIs during time i
Measurement Analysis
Use a line chart to represent the burndown chart. The number of total WIs and the number of completed WIs on
Y-axis and the time (by day if possible) on the X-axis. Ideally, the trend line should go down as time progresses.
However, the following patterns may occur:
-
Rising Slope: This pattern happens when there are additional WIs (task, defects, etc...)
identified after iteration planning. This is not a bad thing. It is nature of software development but it
is important to only consider adding the WIs that are related to the iteration goals . The
team also needs to focus on prioritizing the WIs and make sure that higher prioritized WIs get
done first. However, you should avoid this pattern from happening especially at the end of
iteration.
-
Flat-line: This type of pattern needs immediate attention. It is a sign of problem or an
indication of poorly adopted iterative development practice. This pattern can occur due to the
following reasons, among others:
-
The rate that the team completed work items is equal to the rate that the new work items are added to the
work items list
-
There are defects or rework WIs which prevent the team to move forward
-
There is a reduction on the number of resources or team members
The following picture is an example of burndown chart for iteration tracking. At the beginning of the iteration,
there is a total of 30 work items assigned to this iteration. The blue line illustrates the number of work
items to be completed. The yellow line shows the number of work items which are added to the current
iteration. Adding work items in the middle of the iteration may happen due to discover of new defects or tasks needed
to complete the other tasks. You should try to keep the number of added work items as low as possible. The team
should not consider adding the work items from change requests. The change requests should be prioritized and
recorded in a product backlog for assigning to the later iteration.
|