![](https://hackernoon.com/hn-images/1*_uhQvGpszOmhUnhPHNfjhQ.jpeg)

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?

![](https://media.giphy.com/media/dVsoSPwNWAEqQ/giphy.gif)

### Quick Survey

This isn’t a real survey — but out of the four [agile](https://hackernoon.com/tagged/agile) teams that started with [burndown](https://hackernoon.com/tagged/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.

![](https://hackernoon.com/images/0*k2IbQNVM2D8BZQrv.jpg)

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?

![](https://media.giphy.com/media/26BGDEJS1QPcyfako/giphy-downsized-large.gif)

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_](https://www.alexaitken.nz/blog/are-burndown-charts-useful/) _on July 2, 2018._

Too Long; Didn't Read

Cassandra Forward a free Cassandra-focused community event

Are Burndown Charts Useful?

Too Long; Didn't Read

@alexaitken

RELATED STORIES