When developing a product from the ground up, you might think you need a burndown. Do you want to have an overview of how much work is left before your release? That’s the general gist of a burndown. You want to be able to say — in five weeks I’ll be done. But it never works like that. What ends up happening is that your burn down stays flat — or goes the opposite way because you’ve discovered new requirements. So, are burndown charts useful?
Quick Survey
This isn’t a real survey — but out of the four agile teams that started with burndown charts — only one team uses it correctly anymore (if our sprint reviews are anything to go by). One of the major complaints that I’ve heard is that the burndown charts are not useful and haven’t been used at all since they were introduced by management (that’s right — it was not introduced by the team, but by management).
Quick question: Who thinks management should introduce new processes into teams? No one? Okay. I guess that’s your first sign that burndown charts won’t be useful for the teams. No one wants to be forced to fill out some time-based chart that you’ll review at the end of the sprint. To be honest, my team moved away from a pen-and-paper burndown to a JIRA-based burndown because we didn’t find it useful. We don’t use it other than reporting to management.
Usefulness
Why do most teams then — not find use out of a burndown? Well, I believe it’s because there’s too much data to collect. You may think it’s only one small line you have to draw — but you need to estimate how much work everyone has really done towards their tasks. In the end — when you use pen and paper — you may only draw a line down when a task is completed. Which is also totally okay. How JIRA works is that when you have hours remaining and you log work — it’ll move the chart down. Kind of works. But you’ll see in my example below why it also doesn’t really work.
Another reason why I think we don’t find burndowns useful is that we don’t review it at the end of a sprint. We should be — but someone always forgets to bring it (or print it out). We should be discussing the flat points and figure out what the problems are and how we could improve it. Let’s take the example below.
If we were to have a retro and include our burndown, firstly you can see the amount of hours recorded is far larger than the hours going down. Why? That’s a good question for your retrospective. For us, we already knew about this issue without the burndown. We had a lot of bugs with our story that we were working on, and so there was a lot of work going into the same tasks. These are things that you can discuss at your retrospective if you want. But it’s only useful if your team finds it useful.
Effort v. Reward
I talked about the amount of effort that goes in. I talked about the potential reward. What I didn’t talk about was what that really looks like. Let’s say you draw that line every burndown. Someone on your team is responsible. They need to follow what people did the day before and sort of draw that estimate. Maybe you only go down when a task is done? That’s how some of the teams did it. Reduce the mental complexity.
But is it worth the effort? From my experience, unless someone wants to do it — no one will do it. No one will take responsibility for the burndown because who wants to be an engineer drawings lines?
As for the reward? Are you missing something at your retrospectives? Yes? No? If yes — would a burndown capture that in a way that would allow you to look back and say “aha”? If no — I would say you can skip the burndown.
Summation
They’re good at showing how much effort is left and what the problem areas are — if you’re willing to put in the effort. After a while, you might find that your team talks enough during the retrospective and week that the data is essentially not useful. And that’s totally okay. Teams grow and outgrow metrics and charts. Don’t let management bully you into something you don’t need.
Originally published at www.alexaitken.nz on July 2, 2018.