As far as monitoring the progress of an agile project goes, the burndown chart offers a very concise solution. A burndown chart of an iteration is a plot of the remaining effort versus time. Having said that, there’s more to that simple statement than meets the eye. Bear with me, and I’ll reveal all the secrets of the Flying Donut burndown chart to you, showing you some extra stuff we’ve added, along the way: the Burdown Insight™, that lets you peek more deeply into the information behind the Burndown chart in a way that does not get in the way of its simplicity.
I will use the following burndown chart as an example, taken off the Pandamator project on Flying Donut. Click on “Details” to show the burndown chart.
All work done within an iteration should finish by its end. Given a reasonable estimate of the team working at a constant velocity throughout the iteration, the effort left should gradually decrease until it zeroes out at its very end. The role of the blue line in the chart (series “Ideal Effort”) is exactly to provide a steady-velocity measure against which actual work in the iteration can be compared. The slope of the blue line corresponds to the “Claimed velocity” shown on the chart.
Actual work, as measured by the amount of effort left, is depicted by the red line (series “Effort left”). The Burndown Insight™ takes over when you start looking at the red line. The slope from beginning to end corresponds to the “Actual velocity” shown on the chart. The red line goes down (or up!) as values for the effort left are updated by team members. Whenever total effort left does not change from day to day (and the dots on the red line stay on the same level), hovering the mouse pointer over the red line gives you an indication of “Stable”, like in the picture.
There are some hidden goodies in the Flying Donut burndown chart to complement this very basic information. Along the way, it also shows you exactly which cards were modified. Examples of that are shown on the examples above. Note that, while a downwards (or upwards!) turn of the red line by necessity implies that some cards were modified, the converse is not true: no overall change does not imply that no cards were modified. It might as well be that modifications cancelled each other.
If this feels like Flying Donut is actually keeping track of a separate burndown chart per card, this is exactly true. At some point, we might provide a way for you to look at the individual burndown charts.
I showed you some extra stuff, like I promised in the beginning, but you might be wondering where the secrets, I spoke about, are. Well, they aren’t so much secrets, as non-evident facts of how the burndown chart is calculated.
One of those facts is what happens when you start the iteration without having planned everything in detail. For example, some card does not have tasks, its tasks do not all have estimates, and so on. How is the burndown chart calculated in those cases? Rest assured that a burndown chart will be calculated no matter what! There is actually some default logic at play, to make up for the lack of detailed information.
- Ideally, tasks are there and they have estimates (or at least one does). In that case, the sum of the tasks’ estimates is the original estimate for the card.
- If no task has an estimate (or none exists), the original estimate of the card itself is used.
- If not even the card has an original estimate, then this card is not used in the calculation of the burndown chart.
One other non-evident fact about burndown charts is how to deal with new information. What happens when tasks are added or deleted along the way, is that the same calculation, as above, is done, and the burndown chart is modified accordingly. Meaning that the total original estimate is updated. Same thing happens if the end date is modified: the claimed velocity (the slope of the blue line) is modified accordingly.
That’s it! Now you know as much about the burndown charts in Flying Donut as I do.