Besides velocity, there is another key indicator you can use to measure how well your agile team is performing: the burndown chart. It’s a simple concept—as time passes, the amount of work to do decreases. At least, that’s what would happen in an ideal world.
There will, of course, be days when progress is not as expected or tasks are reevaluated to be larger than originally estimated. However, that’s normal. You shouldn’t expect to see perfection—we want burndown charts to reflect reality, even if there are a few zigs and zags. The iteration may well finish cleanly in spite of these speed bumps, but they may also be an indicator that the iteration is not in a good state of health and action is necessary.
With a burndown, typically you measure against hours and/or story points. Some teams decide to estimate just using story points, and provided they have a demonstrated historical velocity they can attain sustainably, there is no problem in that. However, this also implies that the acceptance of stories will need to be fairly ad hoc, with the product owner accepting stories as the team completes them.
In cases when you are forced to perform the acceptance ceremony at the end of the sprint, it makes sense to measure burndown progress using hours, as there is no value in showing a burndown against story points where all of the burndown occurs at the end. Less experienced and less consistent teams are also better off measuring against hours, because this will provide potentially more frequent updates on the remaining work to do.
Burndown charts produced using software usually will have an “ideal burndown” line. This is useful because this line indicates the gradient to be expected for an ideal burndown, but in reality, the gradient is likely to fluctuate higher or lower so that the net result is a clean burndown. It’s extremely unlikely that a team will deliver with a gradient that is the same as this line for the entire iteration. In fact, performance this perfect should be discussed and examined, as it’s likely that the team is tweaking figures.
Figure 1: Burndown axes and ideal burndown line
Figure 2: A burndown for a clean iteration
Figure 3: A challenged iteration
Figure 4: Iteration with carry-over
Figure 1 shows the burndown axes and an ideal burndown line. Typically, you can expect a team’s workload to start below this line. This allows for some “wiggle room” as changes or unknowns impact the iteration.
Figure 2 shows a typical burndown for a clean iteration. Shown as daily updates, the team had good days and not-so-good days, but it still managed to complete the iteration cleanly.
Figure 3 shows a challenged iteration that was brought back and finished cleanly. The team started off all right but ran into problems around the third day. The team crossed the ideal burndown line and realized they had to reassess the iteration—in this case, by removing a story from the iteration—and by day 5, things were back under control.
Figure 4 shows a challenged iteration that resulted in stories being carried over. This is similar to Figure 3, but in this instance, the team failed to make an adjustment and ended up with stories left incomplete.
The main difference between teams that manage to bring an iteration back under control and those that don’t will be the amount of carry-over. Carry-over is bad because it affects the team’s velocity in a way that will make it more difficult to predict when work will be done. Teams that react quicker should also reduce waste. A key tenet of agile is that accepted stories should be potentially shippable. Stories that have been carried over are not shippable, so the time and effort spent on them is applied to stories that could be completed and accepted cleanly.
Once, I was working with a team that had some critical “must-have” features for a release and some bug fixes loaded into its iteration. After a day or so I saw the estimated hours remaining had increased and crossed the ideal burndown line. After a brief discussion I learned that some of the bug fixes had been underestimated initially, and after the team got more detail about them, the estimates soared. The product owner was adamant that the team complete the must-have features, but after considering the new estimates, he decided it was possible to delay some of the bug fixes until a later iteration. The iteration completed cleanly, and the critical features were included in the next product release.
Having the discussion early in the iteration minimized the disruption to that iteration, and having a product owner who made a clear call in terms of prioritization made the decision obvious. A couple of iterations later, the bug fixes were done, and because expectations had been reset, this was completely fine with all stakeholders.
I hope I’ve provided some food for thought that you can apply to help your team better understand its burndown. To review:
- Expect your team to track its burndown using hours (or, ideally, both hours and story points). If the team is just using story points, ask how often acceptance ceremonies will be performed, and check that the product owner agrees. Also make it clear that for a story-point burndown, the frequency of updates will be the same as how often stories are accepted.
- Your team should start with a figure that is below the ideal burndown line, allowing for change and reevaluation of estimates.
- When it’s clear that the burndown progress will cross the ideal burndown line, have a conversation with the team and product owner: Can we bring our work back on track? What needs to change?
- Discuss the burndown occasionally during the sprint retrospective. Use it as a visual aid to discuss where problems occurred. It may also be necessary to discuss “perfect” burndowns—do these figures reflect reality?
Any views expressed within this article are Dave Browett's and do not necessarily reflect those of his employer.
