Burndown charts - It's not about staying below the line

June 13, 2009 by Jack Milunsky

Introduction
I recently participated in a Scrum development discussion thread on Yahoo Groups where one member new to Scrum asked the following: "Our burndown chart's remaining work line always goes up. As a Scrum Master, what do I have to do to make it go down?" This question, surprisingly, generated a lot of response from the community. I found it puzzling to see how adamant some were to introduce solutions to get the remaining work line to go below the estimated work line.

Goal

I believe that the underlying goal should not necessarily be about staying below the estimated time line in a burndown chart (although this would be nice). Rather, the goal should be about achieving SUSTAINABLE THROUGHPUT (figuring out what your team's development capacity is and how much you can shove through the pipeline). A burndown chart is just an information radiator that is there to help you to determine whether that goal of reaching optimal capacity is achieved. That's it. So as a Scrum Master, you should not get too overly hung up on the burndown chart.

Understanding the problem

If you know you are completing tasks but your burndown is still going up, this probably means that you're adding more tasks during the Sprint than your development team is able to finish. But there's value in knowing this information. When you see that your remaining work line is above the estimated work line by the end of your Sprint, this is a good indicator of the following:

• Your development team is applying new design choices to the existing code during the sprint.
• The tasks you have scheduled are so large and undefined that the hours keep going up as you figure out the complexity is increasing.
• Or your team is having difficulties estimating - which is common among new Scrum teams (see my previous blog on the significant of story points here).

What you can do about it

These are just a few examples of what a burndown chart can tell you. There could be a whole host of other reasons why you're above the estimated line. However, there's a number of things you can do; you can remove tasks off the sprint or you can try and break the tasks down further till you have something more manageable. The challenge is pinpointing the reason and trying in a very practical way, to get the team working at a sustainable capacity in order to manage all tasks for each iteration while minimizing work-in-progress.

Practical use of the tools

Another point that was brought up in the discussion thread was, why have a burndown chart at all if you're using a task board? Although I do believe the task board provides value, I don't believe that it should be a substitute for the burndown chart. The Burndown, Kanban boards and burnup charts are all just tools in your project management toolbox to assist you with continuous delivery of value to the customer. And each of those tools serves a different purpose. With a task board, you know which tasks are in queue, you know which are in progress, you may even know how big the tasks are. But without the burndown, you don't know how far along the complete trajectory you are. Just because half the cards on a Kanban board is in the "done" column midway through a Sprint, doesn't necessarily mean that you have completed half the story points for that iteration. The reason is that you may have smaller or larger tasks remaining. And the larger the project, the more complicated it is to get a sense of the size of each task just from glancing at a whole bunch of cards on a board. Everyday my teams provide a brand new estimate (in hours) for all tasks in progress (this takes them just a few minutes to update each day). So I take a look at my burndown, and in one second, I know if we are ahead or behind the plan...

Permalink