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 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? never Quick Survey This isn’t a real survey — but out of the four teams that started with charts — only one team uses it correctly anymore (if our sprint reviews are anything to go by). One of the major that I’ve heard is that the burndown charts are useful and haven’t been used at all since they were (that’s right — it was not introduced by the team, but by management). agile burndown complaints not introduced by management Quick question: Who thinks should into teams? No one? Okay. I guess that’s your first sign that burndown charts won’t be useful for the teams. wants to be 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 find it . We don’t use it other than to management. management introduce new processes No one forced didn’t useful reporting Usefulness Why do most teams then — not find use out of a burndown? Well, I believe it’s because there’s much 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. too data 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 at your retrospective if you want. But it’s only useful if your team finds it useful. discuss 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 that in a way that would allow you to look back and say “aha”? If no — I would say you can the burndown. capture skip Summation They’re good at showing how much effort is and what the are — if you’re willing to put in the . After a while, you might find that your team talks enough during the retrospective and week that the data is essentially useful. And that’s totally okay. Teams grow and outgrow metrics and charts. let management bully you into something you need. left problem areas effort not Don’t don’t Originally published at www.alexaitken.nz on July 2, 2018.
