Tuesday, June 18, 2013

Sprint Burndown Chart: Yes or no?

I don't believe in sprint burndown charts. So far, in every team I've been Scrum Master for, not one developer really wanted to update the burndown by himself, meaning I was either the burndown-monkey or I found myself asking the team to update the burndown regularly. And since I don't get the real advantages of burndown charts, I struggle to explain the team why it's important to maintain the burndown chart. I guess that's what you call a chicken/egg-problem.

The burndown chart is supposed to show the current status of the team and indicates whether the team is likely to successfully get everything done in the sprint. But: In my opinion you don't need a burndown for that because all the information can be read from the sprintboard. Nowadays sprints are mostly 2 weeks long (I haven't heard from anyone using longer sprints than that in a long time), so it's relatively easy to overlook this time. While I think that a burndown is useful with 4 week long sprints, in sprints up to 2 weeks length it's basically just maintaining an information that is already on the sprintboard.

I've been trying to solve this dilemma for quite some time now but haven't found a real solution yet. First I tried to find the reasons for a burndown chart. Having found none that did satisfy me, I thought: Well, maybe there's another good, intuitive way to visualize the current status. One that would maybe integrate directly into the sprintboard. So far, I haven't found one.

Being on agile coach camp 2013 past weekend, I took the chance and conducted a session called "Burndown Chart 2.0" hoping to find this intuitive, sprintboard-integrated way.

Although we haven't found one, the session has helped me a lot to remind myself what the burndown chart is about, whom it is for and whether it is useful or not. First of all the burndown chart is a tool by the team for the team and no one else, no manager, no stakeholder, no one else. Second its main purpose is transparency: Transparency where we are, transparency what has happened.

Deriving from the fact that it's a tool by the team for the team, the burndown chart should be used when the team wants to use it. If you feel that a burndown chart could help you in your current situation, then use it, otherwise there's probably no real reason to use it. Using a burndown chart is not essential.
Apart from that it doesn't always have to be a chart. Depending on what you want to visualize it can also be a traffic light (visualizing if the team thinks the sprint will be successfull) or any other visualization you can think of.


  1. This comment has been removed by a blog administrator.

  2. This comment has been removed by a blog administrator.