• Skip to main content
  • Skip to primary sidebar
  • Skip to footer

Alex Aitken

Technical and Engineering Leadership, Coaching, and Mentorship

Are Burndown Charts Useful?

July 2, 2018 By Alex 1 Comment

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.

Reposted on Medium.

Share this:

  • Click to share on X (Opens in new window) X
  • Click to share on Facebook (Opens in new window) Facebook

Like this:

Like Loading...

Related

Filed Under: Leadership

Alex

Reader Interactions

Trackbacks

  1. Are Burndown Charts Useful? | | IotaHosting.Org says:
    July 5, 2018 at 12:46 am

    […] published at http://www.alexaitken.nz on July […]

    Loading...
    Reply

Leave a ReplyCancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

About the author

Alex is an AVP of Engineering currently working at Bukalapak. He is a leader in full-stack technologies. Read More…

Pages

  • Speaking Experience
  • About

Social Profiles

  • LinkedIn
  • Medium
  • ADPList

Recent Posts

  • Interviewing as an Engineering Leader
  • Managing Low Performers
  • Getting Docker, React, .NET Core, Postgres, and Nginx Playing Nice
  • What Makes a Good Software Engineering Manager?
  • “Am I There Yet?” Said an Engineer

Archives

  • January 2025
  • August 2024
  • July 2024
  • October 2023
  • August 2023
  • October 2020
  • May 2020
  • February 2020
  • June 2019
  • March 2019
  • October 2018
  • September 2018
  • August 2018
  • July 2018
  • June 2018
  • May 2018
  • April 2018
  • March 2018
  • February 2018
  • January 2018

Categories

  • Coding
  • Essay
  • Leadership
  • Management
  • Roundtable
  • Strategy

Footer

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright © 2025

 

Loading Comments...
 

    %d