In this episode of Trainer Talk – the supplemental series to the Agile Coaches’ Corner podcast – Professional Scrum Trainer Sam Falco addresses the question: “How do you escape the tyranny of the burndown chart?”
The Problem with Burndown Charts
This was the question a student asked last week. I knew exactly what he meant. I experienced it myself with my first Scrum team, and I’ve seen it many times since. Teams try to predict every task they’ll have to do during a Sprint, estimate the hours for each, and make sure that the team’s capacity is fully allocated. As the Sprint progresses, they discover new work: Work that was predicted and takes longer than usual. The burndown rises instead of falling, or it plateaus; the burndown chart becomes a burden that destroys morale and effectiveness.
After a few Sprints of this experience, teams either abandon the burndown chart or they start playing games to make the burndown “look right.” In both cases, the team loses out on a valuable tool for helping them achieve the Sprint goal.
Does the Scrum Guide Require Burndown Charts?
To be clear, the Scrum Guide does not mandate the use of a burndown chart. Here’s what it says about tracking Sprint progress:
“At any point in time in a Sprint, the total work remaining in the Sprint backlog can be summed. The development team tracks this total work remaining at least for every daily Scrum to project the likelihood of achieving the Sprint goal. By tracking the remaining work throughout the Sprint, the development team can manage its progress”.
Tracking total remaining work provides transparency about the team’s progress toward the Sprint goal. That transparency allows the team to make informed decisions about how to adjust the scope of its work throughout the Sprint. If the team doesn’t know how much forecasted work remains, the Sprint goal may be placed in jeopardy.
A Sprint burndown chart is one way to fulfill the need to sum up the remaining work and make that data visible. So, why does the burndown chart so easily become a burden to the team rather than a tool?
Often, it’s because of a holdover from the mistaken belief that software development can be managed through predictive processes. Even in organizations that recognize the folly of predictive planning on a macro level, teams fall into the trap of thinking they can and should plan every minute of a team’s capacity.
How Do You Use a Burndown Chart Effectively?
Software development falls into the realm of complexity. Even within a Sprint, we have to allow for emergent understanding of the work. Requirements — understood well enough for the work to begin — become clearer and new work emerges as a result. Teams that have strived for efficiency in allotting their time find that there’s no room to adjust as new information and understanding becomes available.
The secret to avoiding the tyranny of the burndown chart has nothing to do with the burndown chart itself. The secret is to let go of the belief that we can know everything upfront and that efficient time usage is a worthwhile goal. Instead, strive for value delivery, select work that the team understands well enough to start on, and don’t strive for 100% utilization. The only thing certain about software development is that it is filled with uncertainty. In Sprint planning, you need only look a few days into the future, and allow remaining details to arise as work gets underway.