Burndown is a technique used in Scrum projects for tracking the progress within or across sprints. It is an exciting way to track how a team is progressing against a deadline – and we can apply it to any form of project-status. In this article, we will apply it to documenting business processes.
Thanks in Advance
Thanks in advance to Mishkin for pointing us to a great pdf about Scrum from Yahoo. Also thanks to Michael Cohn of Mountain Goat Software, for his innovative extension of burndown for tracking progress across iterations. The clear explanations and differing applications of this simple visualization technique are inspiring. We plan to use burndown for tracking progress on our current project.
Tracking Business Analaysis
Consider a project involving a team of business analysts, defining as-is processes and requirements for a portion of a large enterprise software deployment project. This project is helping a company migrate from a legacy system to a new solution.
For this hypothetical process, assume that we are documenting 50 as-is processes, with an average estimate of 10 hours of business analyst effort per process – or a 500 hour chunk of work. With 5 analysts working 5 “on-task” hours per day, that translates to 125 hours of capacity per week – or a 4 week cycle for the team.
Linear Forecast
The burndown principal is that we’re tracking a fixed amount of work, over a fixed amount of time. What is interesting is that we don’t monitor how much work we’ve done – just how much work we have remaining. This is important, because effort already spent is a sunk cost, and should not drive our decisions. We should focus on the time remaining to complete the committed deliverables.
Erratic Progress
Even if we spend five hours per day on a task, we will not be eliminating five hours of remaining work each day. Estimates are never perfect. We discover unanticipated problems along the way that increase our estimates of remaining work. We have brilliant ideas that can save time – reducing our estimates of remaining work.
The Ah-Ha! Visual
Combine the ideas of a linear forecast with the notion of tracking time remaining instead of time spent. Then track daily updates of estimated time remaining.
Velocity is what scrum practicioners call the reduction in remaining work per unit time. Visually, this is the slope of the curve. The steeper the slope, the greater the velocity (imagine a downhill skier), and the greater the progress. We’ve zoomed in on the first half of the burndown graph in the chart above. The remaining line is our current estimate of remaining effort (the solid red line). The forecasted line is the original “project management” forecast of equal progress every day. We can take away a few observations from the visual:
- When the remaining line (solid red) is above the forecast line (dashed blue), we are behind schedule.
- When the slope of the remaining line is steeper than the forecast line, we are gaining ground. When shallower, we are losing ground.
- The gap between the two lines shows exactly how far ahead or behind schedule we are.
The Excitement
This clear communication of status allows our project manager to know exactly how we’re doing. It also allows our team to see exactly how we’re doing, and makes it easy to visualize goals like “make up lost ground” as well as providing nearly instant feedback. When the remaining line deviates significantly from the forecast line, we can revisit schedules and scope.
So, it sounds to me like you are making corrections to your estimates, which is constantly recalculating your time remaining. Correct?
Hey Bob, thanks for reading and commenting. The answer is yes and no.
Assuming that the estimates don’t change at all, each day I would update time remaining. There may be times when I get pulled into meetings or other “on-project/off-task” activities, and I can’t allocate the predicted amount of time on that day. Or I may work from home one day, and in the absence of interruptions, dedicate more time to the task than was planned. Either situation would modify the relative time remaining, without necessarily changing the estimates of how much work is required.
However, and I think even more valuably, the estimates do change by tiny amounts every day. When the work for a given day allows me to accomplish more than I expected (it was easier than I thought, or I hit a groove, for example), then the amount of remaining work would be reduced by more than the amount of time spent. The converse is true for tasks that take longer than expected.
What makes burndown so powerful is the fact that we are always looking at what remains to be done. Imagine a runningback trying to score a touchdown. While he’s running, it doesn’t matter that he may have had to switchback behind the line to avoid tacklers – all that matters is how far he is from the end zone at that moment.
We can also use the data to review, reconcile, and improve our estimation process once everything is done. When our estimates prove to be off (in either direction), we have great data to help us understand why. And that understanding can be incorporated into estimates on future tasks / projects.
Thanks again, and welcome to Tyner Blain!
Scott