THE THING THAT EVERY COMPANY DOES WRONG WHEN THEY START WITH SCRUM

Scrum has many useful tools. One of them is the burndown chart. It works like the canary bird they had down in the mines in the past that warned when the air became unbreathable. The burndown chart shows hour for hour, the progress the team makes. It normally show a steady and fairly even descent towards zero. But if it doesn’t, just like when the air pump broke down, the canary stopped singing. Or in our case, the chart starts pointing up. And this is the signal that tells you that you have a problem.

For this to work, we need a starting value. So we start with estimating how long time each task has left until it is finished. Each task should be so small that it should be fairly easy to estimate it rather correct (another feature of Scrum).

Also note that I don’t say “how long it will take to finish the entire task”, we are not at all interested in the actual time it will take to complete it. This has no use to us. And it is anyway almost always incorrect.

One thing to note is that the time left value has no meaning by itself. It is only together with all the other time estimates that it gets useful. Like the cogs in a mechanical clock. Each cog by itself is at most pretty to look at, and it is not until we assemble them all into a clock and get them moving, that it can start tell time.

It is exactly the same with these time left estimates. What does it matter if you have one or five hours left until you are done with this task? It will be done when it is done. BUT when you assemble all estimates into one big machinery, and get them moving by reducing the time left every time you complete one step, you get the burndown chart.

The time left estimate is a moving target. It changes all the time. And it is not only moving downwards. We can very well be adding time to it too.

For instance. We start out with one estimate. After working on the task a while, we might discover that we forgot one vital thing, and this thing will delay the time that we are finished with the task. So we increase the time left. This will be visible on the burndown immediately.

And this is why we bother with estimates and changing the time up and down. We can immediately see if things are on track or if we have a problem. It is only when you are aware of the problem that it can be solved.

Where things go wrong

Now, not everybody in the company knows how scrum works. Especially people outside the narrow sphere of scrum teams. And this is a problem. Because all they see is the starting point and think: “Oh, this is the time it will take to finish the task. This is the time that they will spend working on it. So if I add them all together, I will know how long time they have been working on the project.” Or something along that line.

But then they forget that when we progress with each task, we change the time. For instance, as I said above, what happens if we add a couple of hours to a task because we have to do more work than originally estimated?

The problem is that time left is not the same as time spent. We measure the future, how much time is left, while the managers measure the time we did spend, and that is the past. It is two completely different measurements, it’s just that they happen to share the same unit.

It is like wanting to know the distance between two cities and answering in meters above the sea level. Sure they measure distance both, but while driving you go up and you go down. And in the end it doesn’t matter one single bit how high up you were, to the distance you drove.

And to add to the madness, we are not even delivering time. We are delivering stories. So the conversation is actually: