
Some Like It Hot
In my early ScrumMaster days, I experimented with Sprint Burndown Charts which could be both simple and packed with information. Whenever my teams were collocated, I used hand-drawn versions on the Scrum Room wall. Each daily Scrum would end with the ceremonial plotting of the next point on the Burndown.
However, I had a problem with the “classic” format which showed a single line crawling its way down to zero. The hours remaining showed the hours completed and the hours added (or “discovered”) as a single data point. I wanted more.
The “Classic” Problem
For those who use hand-drawn Sprint Burndown Charts, the one on the right might look familiar. In the first few days of the Sprint, the number of hours remaining may bob up and down.
Sure, work is being completed, but other factors are impacting the number of hours remaining. New tasks may be discovered. Effort may have been underestimated. Acceptance criteria may evolve to clarify a requirement or add a bit of “gold plating.”
At a glance, what’s really going on?
The Secret Lies Below the Surface
I decided to plot points below the x-axis whenever hours were added. It didn’t tell you why they were added, but at least it made visible when they were added.
How exactly does this help? Let’s walk through a Sprint. The first chart shows what we’ve plotted at the end of the Sprint Planning Meeting.
The second shows day 4. Hmmm… things were going as expected days 1 – 3, but something happened on the fourth day. Hours were added. Anyone looking at the chart knows the obvious question to ask. What happened?

On day 7, we can see a trend. Hours are being added almost as quickly as they’re being completed. If we were using the classic Sprint Burndown Chart, we’d see a relatively flat line.
With this Burndown Chart, we know that the Sprint isn’t finished when the line above the x-axis hits zero. It’s finished when the lines converge. Do we still have time to respond and complete the Sprint?

In the fourth chart, you’ll see how at any point we can extend the lines and ask ourselves, “What happens if the trend continues?” As early as possible, we can use our Agile management skills to respond. Can we scale back on our acceptance criteria and consider a User Story “good enough?” Can the whole team “swarm” our bottlenecks? Should we (gasp) pull a Story entirely?
Regardless, we have better feedback day-by-day and can brainstorm the latest options.
Beyond the Bounding Box
I saw a similar approach applied to the Release Burndown Chart on Mike Cohn’s site, mountaingoatsoftware.com. The technique is simple and solid. It helps me think about ways to move beyond the bounding box of the upper right quadrant.