Do burndown charts provide any value?

I was minded to write this post after seeing this graph in a recent post discussing Scrum anti-patterns showing up from burndown charts. This anti-pattern is — “The team accomplishes the sprint goal way earlier than expected”. So, presumably, the team delivered value to the customer earlier than they expected. And this is an anti-pattern — apparently, a bad thing.

Really? Let’s just re-visit that:

“The team delivered value to the customer earlier than they expected. And this is, apparently, a bad thing.

This is the main reason I believe burndown charts are, fundamentally, a very bad thing.

However, there’s more. Let’s consider what a sprint burndown chart actually is, and the science behind it. A burndown chart shows the progress towards achieving the sprint goal. There is a widely accepted “ideal” shape for such a chart which is a straight line from top left to bottom right. All kinds of deviations from this shape are considered an anti-pattern; “the cliff”, for instance, where the line goes horizontally for most of the sprint, then steeply drops off, is seen as really bad.

So let’s take a typical scrum team of about 8 people, and work out how we can achieve a perfect chart. We’ll assume a 10 (working) day sprint and a velocity of 20 story points (to make the maths easier). After day 1 of the sprint. we need to have completed 2 story points. So, we need to have a story of that size (or two “1”s) in our sprint, every sprint, regardless of what we are building. Indeed, we need to have 10 stories of that size, and we need to do them one after the other in order to get that perfect line.

Now, given we have 8 people, I assume they wouldn’t all work on a single story — surely there is some parallelism. So how can we get that perfect line? We’ll we can’t, with these numbers, it’s mathematically impossible unless we consider fractional story points. More realistically, it’s highly unlikely that we can get anywhere near the line unless we game the planning to make sure we have stories of certain sizes that will allow the maths to add up during planning.

Now, there are 2 issues here:

1. We should not be selecting stories and estimating based on how we can achieve a perfect burndown; that is the tail wagging the dog, and patently absurd.
2. Who cares about how we achieve the goal as long as we achieve it? Certainly not the customer, and, in an autonomous, trusted team no-one else should either.

The usual justification for burndown charts is that it identifies issues, and “allows a conversation” about them. However, in my opinion, the issues they are highlighting ether do not exist, or can be unearthed in much better ways; there is no 1-to-1 correspondence between “shape of the chart” and “underlying problem” — the chart may identify an issue, or not, and the issue may, or may not show up as a particular chart shape.

As an example, the classic “cliff” is seen as showing that all the dev gets done up front, then everything is handed to QA and there is a bottleneck. So what if the team has no QA? How have we managed to come to this conclusion? It could be that the team is working in parallel, so a lot of stories finishes at roughly the same time, and the devs are all then code reviewing and doing PRs later in the sprint. Indeed, if all the stories are correctly broken down as small as they can be, this is almost inevitable with any kind of parallelism. Not necessarily a bad thing. Conversely, if there are QAs, and there is a QA bottleneck, that would show up in the project board as a column stuffed full of stories with the devs twiddling their thumbs — no need to surmise it from the shape of a graph if it’s there on the board in black and white. If we need to generate the burndown chart to see the problem, it sounds to me like we’re not on top of things, and there are deeper issues than the shape of a graph…

Another classic “anti-pattern” is where the scope of the sprint changes, so the graph goes up instead of down. Again, why do we need a graph to show us this? Isn’t it obvious when we take in new work that there are more cards on the board than before? Why wait until we calculate the burndown chart to guess at this? Again, is this even an issue? It might be, but it could be that we’ve done a spike and now know more about what needs doing, so we add in some new stories. If we hit the goal anyway — who cares? Plus, if this happens in a single sprint, it could be we are adding new work to unblock another team so that both teams can deliver quicker. Is that a bad thing? Only according to the burndown police.

Let me use a hypothetical example to demonstrate the “better ways of identifying the problem than a burndown chart” concept.

It’s day 3 of the sprint, and we find it necessary to add a new story to the sprint. How do we do this? We have a good old discussion between the whole team — devs, SM and PO — and decide it’s the correct thing to do. On day 5, the same thing happens, same discussion, same outcome. All fine so far.

So, we get near the end of the sprint and look at the burndown chart in a standup.

SM: OMG — the graph went up on 2 separate occasions! Anti-pattern alert! What’s happening?

Devs: Well, on the first occasion, we discussed it in detail and decided it was the right thing to do. On day 3, I believe.

SM: Ah, OK. What about the second one?

Devs: Well, same thing — we discussed it in detail and decided it was the right thing to do. On day 5, I believe.

SM: So why are we discussing it all again now just because the chart has identified an “anti-pattern”?

Devs: Well, indeed. Why are we? Are these discussions why our standups take so long? #facepalm

If the spikes in the chart are the first time anyone was aware of the issue, there are deeper problems:

• The SM and/or PO are not available enough
• Devs, PO and SM aren’t communicating
• SM doesn’t have a handle on what is going on
• We are waiting to generate charts/metrics rather than sorting issues as they occur

…etc. A burndown chart is not identifying these issues; indeed an “ideal” chart could easily hide them! And, identified anti-patterns often aren’t problems at all!

I think what I’m basically saying is this:

Probably the biggest flaw in these charts is the behaviour they drive. Using such charts — and caring about deviation from the “ideal” — means we are caring more about how accurately a team can estimate their work rather than the value they are delivering. Also, the goal is seen as simply a number of story points and that is all that matters. How often have we heard “we can bring in 5 points into the sprint if we take out 5”? That is just maths — are two stories of the same number of points “equivalent” in terms of the goal? If we take out a story, are we guaranteed that there is one of exactly same size that also contributes to the goal? We should be asking how we can we maximize value delivery and hang the arbitrary points goal.

As with many things now seen as “standard Scrum” (i.e. add-ons that were never in the guide, and were certainly never in the original intent of Scrum), burndown charts are an attempt to objectify something that doesn’t matter to allow an unnecessary element of control over a team.

In fact, and again like many of these “add-ons” — these charts are just an easy proxy to something more difficult. Burndown is trivial to measure and gives a nice easy set of trite “anti-patterns” you can easily identify, well, choose, actually, from their shape. An easy way to spot “problems” (i.e. probably no problems) without having to think about it too much. It’s much more difficult to look deep into the team’s psyche and interactions and work out what’s really going on, to find out if they are, in fact highly performing and delivering the most value they can rather than checking they are burning story points to tick boxes and satisfy the Scrum police.

Did I mention I’m not a fan of burndown charts? :-)

The real issue this article is identifying, of course, is tracking the wrong metrics to give a false sense of progress. I explore this in more detail in this blog post if anyone’s wants to explore further https://www.linkedin.com/pulse/why-we-measure-punish-speeding-steve-wells/