On Monday, the boss asks you how long a task will take, and you say, “About a day.” Wednesday afternoon, the boss asks again, and the task is not done. By Friday, the task is still only half done.
If you’ve never experienced this, your position is more fortunate than most. For the rest of us, though, I expect the scenario is oddly familiar. Some of us have lived through attempts to get “better” at estimating or to find “root causes” for bad guesses about work effort.
I’m not sure they were bad guesses, and I’m certainly not sure that spending more time estimating will make things better. Let’s look at a few other possible explanations.
Of course, it is possible that our estimate was off by a bit, but compared to the above possibilities, it is unlikely we were off by much. No, the main reason specially assigned tasks are late is because we estimate in “touch” time, then assume we will begin the task immediately and have a forty-hour workweek of touch time.
The assumption of a forty-hour week is so superficial that it is foolish. It leads to padding our estimates, then playing with numbers to make sure they add up to forty. It is a joke. We should stop doing it.
The only problem is that people don’t know of an alternative. Allow me to introduce one: prediction based on past performance.
That is, if we have some way of making the size of the work about the same—what I call the batch size—if we count the number of tasks we get done in a week, then we are likely to get done that many next week. (This scales up. If you do it with a team for long enough, it will actually average out to include holidays and vacation.)
I am still skeptical of using past metrics to predict effort, but this is really more a metric of flow. It doesn’t require you to change the way you work. Just find the batch size, get those batches to similar touch time effort, and count.