Accurate estimates are possible

Humans are terrible at predicting things. Especially about the future.

I have had two insights that really help. The second one turns everything I have ever been told about estimations on its head.

Assembly-lines under controlled conditions are easy to predict. But few of us run these any more, and still people who depend on us really want to know when we will deliver. So we guess, because not guessing is bad for business.

The first insight was taught to me. It turns out we are slightly less bad at comparing than predicting, and so came the storypoints: This new task feels twice as painful as that other task we just completed, so we assign it twice as many storypoints. Over time we calibrate our reference list and are told our estimates will get better, eventually.

It also turns out that the simpler the task, the easier it is to estimate. So if we break everything down into small enough pieces, estimation becomes more accurate.

What if we combine the two? We pick a small standard size for tasks and then we whittle them down until they are all of the same small size. Now we get relative estimates of small tasks, the sweet spot for estimation. For us, that optimal small task size takes just over half a day to complete.

Now, we don’t follow this rule to the letter. Here is how we size tasks in practice, balancing simplicity with flexibility:

• “I can do this straight away”: 0 points
• “Straightforward change I know how to do”: 1 point
• “I have an idea, but it’s a bit sprawling or includes an infrastructure change”: 2 points
• “I have no idea how to do this, and I need to fully immerse myself in it”: 3 points and time-boxed to 2 calendar days.

The second insight is my own. Here is my story:

A few years ago, management accused my team of running over time on every project, and I admit they were not wrong. I took the opportunity to go back and review every project from the last six months, and I was somewhat surprised by what I found. Yes, every project ran late, but they were all delayed by roughly the same ammount: about 25%.

And that is when the second insight hit me: There is no estimate.

I have not done a single estimate in over 10 years.

I think that the ShapeUp method from Basecamp gave me the missing clue. ShapeUp talks about bets rather than estimates. Not “How long will this take”, but “How much are we willing to invest in this idea”.

I do not design a task that will take half a day to complete. I design tasks worth half a day. Because any task worth doing includes parts that matter more and parts that matter less. Parts with risk and parts without. Simply put: there is a lot of gray area.

What I realized was this: We always handled the important and high-risk aspects up-front. By the time we had run over by 25% and management was getting anxious to move on, whatever remained typically wasn’t that valuable. So we shipped and took on the next project.

This was my real insight. Divide your problems into a standard size that is small enough to be low risk. Then do the important parts first and ship when you are out of time.

That is how I hit 25% prediction accuracy, by focusing on value and risk.