Using Your Burndown Charts for Better Sprint Retrospectives
An accessible version of this post is available at https://blog.edx.org/using-burndown-charts-better-retros
I’ve been sitting in on a lot of standups, groomings, planning, and retros these days. One thing I’ve noticed across teams is that we’re always not quite sure what to do with burndown charts. What stories do they tell? How seriously should we take them? How should we feel when they don’t burn all the way down (as most teams won’t), or, worse, like airborne embers, float stubbornly up?
In my view, burndown charts are valuable catalysts for conversation about the way your team is getting work done. By extension, a retrospective that makes good use of a burndown chart is more likely to produce actionable insights that will result in meaningful outcomes.
This post is about what I think burndown charts tell us and how you can use them in your retrospectives.
What does a burndown chart tell us?
A burndown chart, as I see it, gives a qualitative sense of what’s going on in a team’s sprint.
As many burndowns show, scrum teams can be riddled with interruptions or regularly fail to deliver on their sprint commitments. Deciding to use scrum doesn’t automatically mean that you’ll fend off interruptions or complete sprints. Scrum just makes it visible when you don’t. The way you work will always require some sort of irreducible creativity, teamwork, problem solving — that hard, human idea-making that no universal process will ever be able to do for you. But the framework you use to think about your work will help you know where to focus your efforts. That’s where the burndown chart comes in: it registers when sprints are affected by interruptions, gross mis-estimations, or by pulling in too many points. An unhealthy burndown is a good entry point into a conversation into what needs improving.
How you can use burndowns in your retros
Here’s the idea. You start your retro by looking at your team’s burndown, and ask the following two questions:
- Why did — or didn’t we — complete our sprint commitments?
- Why were there — or weren’t there — interruptions in the sprint?
In scrum, teams should be using the retro to continually hone their processes toward the goal of consistently hitting their sprint goals and reducing interruptions. For those of you who are skeptical of scrum (and we should all maintain healthy degrees of skepticism about our processes!), talking about the burndown will raise legitimate questions about the relative importance of delivery on commitments or reducing interruptions. I suspect that many of the points that might come up in a traditional retro (one that asks what went well and what didn’t) will also surface.
A side benefit of a burndown-driven retro is that you can evaluate the efficacy of your action items when you revisit your burndown in your next retro. In theory, burndown-driven retros will, over time, lead the team to healthier burndowns. By cementing the burndown as a proxy for the team’s performance, it becomes a scorecard that you can measure your team’s progress against.
Postscript
After I started writing this post, I had some interesting conversations with some coworkers, including Bill, on this topic, where they expressed similar views to the ones in this post. My own thinking on this topic is greatly indebted to theirs.
Another coworker of mine pointed out that changing your retro style can help surface different kinds of issues. If you try this kind out, keep in mind that there is no single best way to run retros. On the contrary, there may be great benefit in switching it up.
I think about burndown charts as if they are a strand in a spider’s web: a thing the spider can use to remotely detect disturbances at a distance, otherwise invisible to its senses. Teams, composed of people who are prone to biases and blindspots, should think about other ways to build and maintain “webs” to register other invisible aspects of their performance. What strands compose your team’s web?
Originally published at blog.edx.org on November 8, 2017.
