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.
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.
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.
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.