Estimate Effort Based on Past Performance
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.
- The task was not a priority. The boss asked how long the task would take; he didn’t say get started on it.
- We had other things to work on. We could only give the task fifteen minutes a day.
- We had interruptions. The folks from tech support had a question, or a developer wanted to discuss a bug, or . . .
- We had other planned, ongoing work. Standup meetings, team meetings, and checking email continue even when you have a special project.
- Waiting. The server we needed didn’t have the version of the software we needed on it, or we needed to wait for a build, or we didn’t have install permissions.
- Failure demand. The task itself would take a day if everything worked, but because it didn’t, this led to reproducing issues, documenting them, arguing about the bug, waiting for a fix, and retesting. None of that was included in our estimate.
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.
