The Sprint Burndown – WHY? Part II

This series will talk about the WHYs behind a commonly used, misused, and abused concept in Scrum: the Sprint Burndown. A Release Burndown is an entirely different thing, with different goals and a different audience, which these posts will not cover at all. The confusion between these two burndowns, especially understanding the different audiences, is one thing that leads to misuse of the Sprint Burndown.

Last time, we talked about the basics and the core why behind the Sprint Burndown. Now, let’s talk about the Sprint Backlog in more depth, and at the same time move towards the bigger picture of metrics and audience.

This post answers questions like, “Can I, as a manager, use the Sprint Burndown to gauge the performance and progress of the team?”

• Understand that a burndown is a crude, single metric – so there’s a lot of conversation that needs to come along with it. That is, just having a Sprint Burndown, even if it’s accurate and up-to-date, is rarely enough to-know-where-you-are (see the previous post about why this is an important need). For an example, enter the Daily Scrum – if the SB looks good today, but Jimmy is totally stopped on a huge, key task, for example – the team should hope they’re not just looking at the SB and saying “looks great, moving on…”, and they should hope Jimmy is speaking up (or at the very least, the Scrum Master is helping facilitate that), because things are not “great.” That’s not where they actually are, regardless of what the SB says.
• That said, the SB is useful all by itself as a trigger for explicit adaptations – “we’re not where we thought we would be, even a crude metric like the Sprint Burndown can show us that – what are we going to do?” If you’re not using it as a trigger to adapt, and just looking at a drift from the ideal trend line and saying things like:

  “Well, maybe it will get better.”

  or

  “Let’s just work harder!”

  or

  “It’s really not that bad, I’m about to close 4 tasks and then the line will go down, trust me…”

  – then I actually recommend you stop using it immediately, because you’re not doing anything with it that’s intended – you’re not really believing it (you might say you’re not actually inspecting it), and most importantly you’re not using it to adapt. You’re wasting your time, and you or someone else is likely drawing conclusions from it that are very dangerous because they’re so detached from reality.

• This “problem” (it really isn’t a problem, it’s just the nature of the thing) – that the SB isn’t all that useful by itself, other than as a trigger for more granular discussions around adaptations made in response to its inspection – is much greater, with even more implications for the outside (of the team) observer of the SB. Anyone outside of the team should be very careful about drawing any conclusions without additional information from the entire team. “Don’t draw sweeping conclusions from isolated metrics,” is one cliche that applies here. You can probably start to guess where I’m taking this…
• The SB, when used, or any other how used to meet need-to-know-where-we-are, is explicitly for the team, as one tool that will help guide them to meeting their Sprint Goal. Outside observers don’t have enough context for it to mean anything of value to them by itself, and for the team to add the context would involve so much time on their part (it would go well beyond just observing the Daily Scrum) that you may as well put the outside observer onto the team – which is impractical for all sorts of reasons, and not what the outside observer is after, anyway. Even so, I oftentimes see managers and others outside of the team trying to use one simple thing, like a Sprint Burndown, to draw conclusions that have nothing to do with what’s being tracked, or the actual goal of the artifact in question.
• The questions and conclusions I see these outsiders trying to understand – whether the team is successful and performant, whether they need help and what kind of help, whether medium- or long-term goals are in jeopardy, whether we’re happy with the return on investment of this team in the context of building this product – are all very good things which I encourage you and them to understand. A Sprint Burndown, quite literally, tells you none of these things. Let me repeat:

  A Sprint Burndown, quite literally, tells you none of these things.

  Trying to use it for these means will be very frustrating for people outside of the team, because it just won’t work. Trying to use it for these means will be very frustrating for people on the team, because that inevitably comes across as (and most often actually is) micromanagement.

OK, so I’ve said that the SB is not the tool for understanding these things, but also that these things are still valuable – so, what are some good tools to understand these things?

Next time we’ll talk about the answer to that question, which will also actually help us understand more about the Sprint Burndown.