BROADCASTS.com

Published: July 7, 2020, 4:01 a.m.

In this episode, Professional Scrum Trainer Sam Falco addresses the question: \u201cHow do you escape the tyranny of the burndown chart?\u201d

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\u2019ve seen it many time since. Teams try to predict every task they\u2019ll have to do during a Sprint, estimate the hours for each, and make sure that the team\u2019s capacity is fully allocated. As the Sprint progresses, they discover new work. Work that was predicted 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 \u201clook right.\u201d 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\u2019s what it says about tracking Sprint progress:

\u201cAt 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.\u201d\xa0\xa0\xa0\xa0\xa0\xa0\xa0\xa0

Tracking total work remaining provides transparency about the team\u2019s progress toward the Sprint Goal. That transparency allow the team to make informed decisions about how to adjust the scope of its work throughout the Sprint. If the team doesn\u2019t 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\u2019s 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\u2019s capacity.

How do we 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. New work emerges as a result. Teams that have strived for efficiency in allotting their time find that there\u2019s 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 up front 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\u2019t 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.

Want to Learn More or Get in Touch?

Register for our upcoming web meetings by visiting agilethought.com/events

See available training courses at agilethought.com/training.

Visit the website and catch up with all the episodes at AgileThought.com!

Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!