The Value of Burndown Charts

Burndown gives you a robust way to figure out when your project will actually finish. It’s a core part of scrum, but really a lot of project managers can get value from using this technique.

Burndown is valuable because we know people are generally bad at estimating completion dates, so any estimation technique that contributes an objective estimate should be useful. If you already have a Gantt-based schedule, then burndown is likely a complement rather than a substitute for it because the two methods are fundamentally different, but are both help answer the same question – when will we finish?

Burndown hinges on a very simple equation:

Rate of change in work = New work added – work completed

There are two basic outcomes of this equation. If you’re adding more work than you’re completing, then the completion of the project is still some way off. If you’re completing more work than your adding, then you are on the way to being done, and burndown charting can give you an estimate of how close the endpoint is.

As with anything apparently simple, the challenges are simplified away. Here the main challenges are:

1. Ensuring that all work is defined at a similar level (for example work in a software project might be defined as a bug)

2. Ensuring that you actually have a way to measure when new work is added and existing work is completed.

And of the 2 items above (1) is actually much harder than (2). With any decent tracking system (2) should be straightforward, but on (1) work items will never actually be truly equal, for example I mentioned software bugs as a common unit to measure in, but of course not all bugs are equal, some can be fixed in 10 minutes, others may take weeks or longer.

Then generically any project has 3 phases.

• Phase 1 – planning: work items flat or increasing
• Phase 2 – core execution: work items increasing
• Phase 3 – approaching finish – work items decreasing

The diagram above gives an indication of what this looks like over the life of a project, though of course no project is ever quite this pure.

Burndown is most interesting/useful in the final phase (the downward slope) because that’s when the estimates have most forecasting value.

Example 1

50 work items outstanding

1 work item being added each day (on average)

11 work items being done each day (on average)

So, net 10 items are being done each day and the project should be done in 5 working days (i.e. 50/10).

Example 2

200 work items outstanding

10 work items being added each day (on average)

15 work items being done each day (on average)

So, net 5 items are being done each day and the project should be done in 40 working days (i.e. 200/5).

The examples above also imply that burndown only tells you when the stock of existing work will hit zero. Obviously, if work is continually added to the list each day, the project will never be done, because the stock will be at zero at the end of each day, but then tomorrow more work will come in.

So that, in essence, is burndown charting. If you’re not currently using it and have a large number of similar work items on your project (or sub-project) then it’s a useful technique to experiment with.