Burndown charts are a way of tracking how much work was estimated to be remaining at a given point in time, and we track this over time to give us some idea of the rate of change. We start with some estimates, then we track how much time is left at regular intervals, I do this daily, because its a sensible unit but there are no rules. Its much easier to show this rather than tell it so here is an example – we’re making a dolls house.

(yes, this is a photo of me. This was my fourth birthday and the dolls house was a home-made gift from my parents – I still have it)

Task List and Estimates

We need some numbers to start with, and I don’t mean looking at a task and going “a week and a half … ish?”! Tasks need to be in small enough increments that we can safely estimate them. By “safely” I mean realistically and hopefully accurately enough that you won’t find your project manager following you to your car at night with a pitchfork in his hand. For our dolls house, the table looks something like this:

As you can see, we’ve got a large element listed in the middle of the table – 27 hours is too big to be a single estimate, so we’ll break it down further.

Charting Estimate Remaining Over Time

The aim of this is to chart how the estimated outstanding work changes over time. So we start with the total estimates in place – I’ve added a week’s worth of days, just because its easy to fit onto the page, but your chart might have dates rather than days and go on for longer. Each day copies the number of hours of the previous day as its initial value – we’ll edit them when they change.

On Monday, all the work is still to be done, so we start with a chart that looks like this:

To make the chart is as simple as adding a “total” field to each of the day columns and turning that into a bar chart:

Let’s say on Monday we get the first two tasks done – we set the “Monday” column for these tasks to zero because there is nothing outstanding. Now our table and chart look like this:

So each time some work is done which causes the estimated remaining work to be reduced, we update the figures in the table.

During the Main Phase

Imagine we’re partway through and its Thursday, let’s check in on our dolls house project:

At this point, its pretty obvious that the project isn’t going well. The curve on the chart isn’t steep enough to be able to reach zero by Friday and without having to interrogate developers (who of course are always 90% finished), we can see that overall, things aren’t great. Project managers may know that there is one blocker which is causing the problem but if you didn’t know … then you do now :)

A closer look at the numbers against the tasks show that we started the reception rooms and the bathroom but neither are finished, the bedroom we’ve worked on for the last couple of days and its almost there … you get the picture.

The Aim of the Game

The ideal burndown chart tends towards zero at the point at which the project needs to be finished … but working this way gives a nice graphical overview of whether thing are heading in that direction or not. Flat lines are generally the sign of something bad, and progress is really visible even when its spread across many tasks or many developers. The chart could have a column for who owns each task, and for extra points add an “actual” column so you can compare how the team performs against its estimates (this is “project velocity”).

This post was really only intended to show things as I see and use them – if this helps you then great. If you want the “official” version then I can only suggest you get a book on scrum and find out how to do it from someone much more qualified than me :) If you’re using this or something similar, then I’d love to hear how it works out for you and what you do differently – leave comments and tell me!