Agile teams often rely on burn-down charts to show how much work remains in each two-week sprint. The starting point represents the total work to be done and ends at zero when it's finished. There's no detailed plan of how much work is done each day -- teams just draw a line from start to finish.
But two problems can arise:
1. Teams get used to collecting data, but forget to interpret and take action on it.
2. Executives may look at the graph and become concerned if the actual numbers don't track precisely to the projected line.
So how do you know when to be concerned versus when the numbers are varying normally? An average of 20 percent variance is a good rule of thumb. Anything less is a false alarm. Anything more demands attention.
Here are some models I've created of possible scenarios, but in reality, progress is more of a wandering curve. The vertical axis shows how many hours are left and the horizontal axis shows how many days are left. The straight blue line represents the planned amount of work left each day in hours, while the red line shows the actual hours left.
Case 1: Under the line
The team consistently finished more work than expected. Does this represent an error in estimation or natural variance in the system?
The team is running behind, but is close enough that it will still complete the work for the iteration.
Case 3: Above the line -- in trouble
The team is so far behind, it must stop and take action to address the problems or re-plan the work. This progress line is a powerful warning signal.
How do you use burn-down charts?