TASK ESTIMATES AND THE BURN DOWN CHART, WHY AND HOW

In the olden days, you had to wait until the end of a project to know if you were finished in time or not (and you never were). And a project that lasted more than a year is not uncommon. That is a long time of uncertainty. Thankfully, we now work agile. Nowadays we have sprints, and they are typically two to three weeks long. Which then means you only have to wait that long to know. So much better!

But I dare say that we can do even better than that. Just as test driven development has pushed error feedback to the limit, I mean, if you write the test first, you will get feedback as soon as you have written the code that the test verifies; Scrum also pushes the feedback loop to be as short as possible. And how do we do that?

The burn down chart!

So, what exactly is a burn down chart then?

It is a graph that shows a simple approximation of how much work you probably have left to do, at any given moment, if you work in a steady and even pace. I say probably because it is just an estimation.

Here is an example.

And this is how you create it.

Start with summing up the number of hours you have estimated in the tasks. This is the starting point for the burndown chart.

Then draw a diagram, with the days of the sprint on the X axis and total estimated hours on the Y axis.

Draw a straight line form day 1, on the total estimated hours, down to zero hours at the last day of the sprint.

Now, the stage is set.

Next step is to start working. That means that you update the time left on the tasks you are working on. Let’s say that you have a task that is estimated to take 5 hours to complete. When the day ends, you look at what you have left to do and re-estimate it and find that you now only have 3 hours left.

Yes, we don’t care about how much time you worked on the task already. That is the past and that is not of any interest to us right now. We only want to know how much work you have left to do. The future.

Now, it is time to start drawing the second curve. The actual time left on the project. You do this in the beginning of the next day. Sum up the time left in all tasks again. Plot it in the graph.

Now you have two lines. One with the perfect but hypothetical work progress, and one with the actual. They will deviate, because nobody is perfect, but in the end, they will average out and follow each other quite nice.

And this is the crux of it!

Because, if you for some reason deviate from the expected curve, you will see it immediately. When you look at it, you will se that something is wrong. It is like the canary in the mines. It will alert you of problems just about as soon as they start building up.

This can be the result of many different things. You might have underestimated the work, or you learned something about the task that you didn’t know in when you estimated. You maybe have technical issues which stall the production.

It doesn’t matter what the reason is. You know that something is happening, and you can start addressing the problem right away.

It can of course go the other way too, maybe you just did a brilliant job and completed a task much sooner than you expected. In that case, the only problem is that you have too little work in the sprint. But that is also good to know.

So, now we know we have a problem, but what should we do to fix it?

We do what we always do in Scrum. Collaborate. Discuss within the team what the best solution is. Help each other out! Or maybe even tell the product owner that you might not make the agreed delivery this sprint. They too have responsibilities and maybe have to change their plans because of this.

The thing is, you will get a really early warning that someone is struggling. And the team will give support at the same time you need it. Not one or two weeks later. By solving the problem before it even becomes a problem will make you act instead of just reacting. You are on top of things instead of defending yourself why you didn’t do what you agreed on.

This is how you organize for success…

— Cheers!