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

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

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...

Written by Jack Milunksy - COO at Brightspark, certified ScrumMaster and Co-founder of Agilebuddy (Agile project management software that lets you easily Create, Estimate, Plan and Track your software development projects). For great Agile tips follow Jack at: www.twitter.com/agilebuddy. To get more info on Agilebuddy please visit: www.agilebuddy.com

Comments

[mel]

i'm interested in hearing what you think about a burndown that tracks # of tasks left to do rather than # of hours of work left to do.
for my teams we've stopped estimating tasks in hours and have just been keeping track of what the tasks are. this has made the team's interaction with their wall a lot more fluid. most tasks are taking 1/2 day to 1 day to complete.
i'm getting pushback from some people in mgmt who say they don't have a clear picture of how the team is doing. my argument is that essentially the hours burndown and task burndowns are the same, it's just the scale that's different.

[Jack Milunsky]

That's a really good question Mel. In fact there are a lot of folks that prefer to work this way. I think if you can ensure that all your tasks are a day or less then I think that works fine. But I tell you it's really hard to get a sense of where things are at at the macro level. i.e. how far are you progressing towards the uber goal of the release. I am not sure that the hours' burndown helps you much with that either. So tracking velocity is better for that. So in my opinion then is what you're doing is fine but be sure to track how many story points you're completing in a given period (your velocity) which will allow tracking at the macro level.

[Chris Sage]

I am one of those that prefer to work with tasks less than a day long; I feel it's easier to get a sense of how things are going and how long we have left (not to mention, it's a lot easier to estimate, develop and test really small things).

Definitely keep track of your velocity so you and the business can see the long-term picture.

One of the challenges I've had with using different measurements than hours is that a lot of folks that don't have the experience in doing so are resistant about measuring in any way except hours. They're not used to it, and it's hard for them to make that kind of transition, even after explaining the concept. (I use difficulty as estimate)

[Dave]

Mel, a question, how often do your teams deliver vs fail to deliver at the end of a sprint? If your team is delivering 90% or better then tell management (as politely and diplomatically as you feel appropriate) to get their nose out because its working. If the team is delivering 40% or less then they are worried for good reason, you need to look at what the problems are - and there could be many, anything between the two and you should be working to improve the team (retrospectives) and will need to somehow compromise with management - perhaps the over used colour coding put different colour markers on the board or next to particularly problematic tasks so people know where and how bad the risks and issues are.

[Dave]

Even when reduced to running a 'waterfall' project I always have my team fill in their weekly timesheet with the following info:
Task, time spent, time to go

The last column is missing from the majority of timesheets you see in use in companies. Without it the fact a task estimated at 20 hours has had 15 hours spent doesn't mean only 5 to go, it really doesn't, and it is at exactly that point of missed opportunity that most project managers go so badly wrong.

In a scrum situation I don't bother with a formal reestimate, but I do ask questions on tasks that seem to be giving more trouble than expected, or appear to be taking more than the original points estimate would suggest. Perhaps a formal reassesments not a bad idea.

[George Dinwiddie]

Jack, you make some good points above. I also like Mel's suggestion of tracking number of tasks rather than hours left on tasks. Of course, this only works if you use smallish tasks. My preference is to use smallish stories, instead. Rather than splitting the user story into tasks, split it into thin slices of functionality. Then you can track these by story-point estimate or, like Mel does with tasks, by counting them. It's easier to tell when a functional story is complete than a task, so there's less likelihood of fooling yourself.

The one thing in this article with which I disagree is the notion that "it would be nice" to stay below the rhumb line of the burndown chart. Sure, that does give the team a comfortable feeling. But it also indicates that the team is going easy on themselves, especially if this is a common occurrence. If the team never struggles to meet the sprint commitment, if it doesn't occasionally fail to do so, then it's an indication that they're playing it safe.

I talk about this and other things you can see in the shape of the burndown in my Better Software article, http://www.nxtbook.com/nxtbooks/sqe/bettersoftware_0709/index.php?startid=26

cheers,
George

[Eric Gavaldo]

Hi George,
I loved your article :)
Well, I think there is no 1 way to handle burn down charts and to fix the problems you describe (which is more a management issue to me) but very likely one solution per problem/company/team. However, I'm using a (free) tool I wrote myself to capture stand-up meeting's output. It generates a "velocity chart" for me (that I prefer to burn down chart). This chart includes also week-end which allows to visualize potential emergency "rescue plans". It is more based on remaining % of each task. And I apply a global "efficiency ratio" for each team. This allows me to "adjust" the prediction depending on the guys in the team.
You can have a look at it here: http://www.xqual.com/products/screenshots_serie3.html
I've been using this for one year now and I'm quite satisfied with the results (much better than the excel sheet I used before).
I'd be happy you suggest some possible improvements if you have some ideas...
Cheers,

[Payal Sood]

Hi,

I have used Burndown based upon estimated hours vs Actual hours spent so far. I stopped doing them as mentioned in one of the comments this doesn't reflect how much work is left.

What we now do is use our board where stories are broken into tasks which have estimation in hours. The tasks are mostly less than 1/2 day so at any time, if you like to sum up on the board you know how much is left. We have also reduced the sprint cycle from 3 weeks to 1 week which help in more realistic planning. Also as we have a QA lead we have categorized board with To-DO, In progress, Ready for QA, Ready to go-live. The board looks bit messy but serves the purpose.
So we could roughly calculate the velocity however where one can't have committed teams (due to their specialty) board having estimation in the post-it notes for left out work is a much better representation of the status.

[Bradford Hull]

I have tried to chart burndown hours for my management in a number of ways, because they think it's intuitively obvious that charting them will give them a valuable insight into how the project is going. I wish I had $5 for every intuitively obvious thing that isn't true...

The best I've come up with is, when a task is finished, prorate the estimated hours over the time since the task started and take them off the estimated hours left. This doesn't end up showing at all times the nice straight line management expects, because you can only count the time down after a task is complete, but if you have a lot of moderate sized tasks like you describe it will be fairly satisfactory.
Using actual hours is actually using different units, since the estimates are guesses. Management will also want to know the comparison of actual to real, but for burndown purposes it doesn't help to subtract oranges from your original stack of apples.
It works better to show actuals vs estimates in a different report. Just my opinion, but it works for my managers.