Iteration / Sprint Burn-down or Burn-up Chart?

Burn charts are an excellent light-weight tools for tracking software projects. The value of this tool is that it is an early, reliable, and visual indicator for team progress.

Burn charts are drawn on two levels: release and iteration. On release level, burn charts are used to track completed points every iteration, and is excellent to track releases on prolonged amount of time (3-6 months). On iteration level, burn charts are used on daily basis to track team progress in the iteration and how far the team is from achieving the iteration goals.

It is very important to note that Release burn chart come in two forms: burn-up and burn-down. However, on iteration level, it only comes on the form of burn-down chart, and there is almost no literature on iteration burn-up chart. You may find examples of iteration burn-up of effort plotted on the iteration burn chart, like that of Mitch Lacey's Scrum template.

What's the problem with iteration burn-down?

In the following example, consider the flat line at day 4 and 5

Iteration burn-down chart: does not indicate the reason of no progress on days 4 & 5

On day 4 and 5, the remaining effort did not change. There are many reasons which may explain this case, like:

• The team were on vacation
• The team were assigned temporary tasks in another project
• The team worked on the project; some of them increased the remaining hour of their tasks due to very optimistic initial estimate
• The team discovered more technical tasks that need to be done, but were overlooked in the iteration planning meeting. The estimates of these new tasks are added to the remaining hours of this iteration and the overall remaining hours are the same

Any of these explanations may be valid and usually such explanations are mentioned in the retrospective and this experience is added to the 'group memory' of the team. But, such contextual data is very important information for whoever is observing the team from outside. Also, it may be very important for the team while analysis on their performance over a long period of time, larger than the past iteration only. In such cases, such contextual data may not be visible or may be lost from the team memory.

Another pitfall of this graph is that in this specific case, it doesn't indicate the progress of the team. It just indicated that there may be an issue which needs more investigation.

Iteration burn-up captures more contextual data

Now, consider the following graph, which depicts the same data of the last example:

Iteration burn-up chart: actual work compared to total work indicates clearly the team progress

There are two graphs:

• Actual burn-up (blue): this is a plot of the cumulative actual work hours by the team
• Total work (red): this is the summation of the 'actual + remaining' work reported by the team

The rational of this graph is that the iteration is over when the actual burn-up graph intersects with the total work graph. This is exactly what we need from any progress indicator, to indicate when we will finish the iteration, given the variable and dynamic development environment.

In the above example, it is clearer now the reason behind the flat remaining line on days 4 and 5. On day 4, the team did not work on this iteration, so the total work graph is flat, whereas on day 5, the team did work on the iteration, but the total work is still flat, which means that the remaining is kept constant by the team.

The powerful point behind this iteration burn-up chart is that it indicates the actual effort of the team as well as the total work side by side, and indicates changes and patterns in both of them also side by side.