I suck at estimating! But it seems that our industry considers estimating an important skill. I’ve always been optimist with my estimates. And being aware of this hasn’t made my estimates more accurate. (Apparently there’s event a law for this – Hofstadter’s law). The truth is, I never wanted to get better at it. And I still don’t.

Why?

First of all, estimates are waste (from a lean point of view). If you ask a customer: “Do you want more estimations?”, he’ll say no. This means that estimates are waste.

Of course, there are different types of estimates. There are rough order of magnitude estimations for large chunks of work. Let’s call this Estimating a project. Then there’s estimating smaller pieces of work, for example Estimating stories or features.

Estimating Projects

Think about the estimation that is usually necessary for bidding on a project. The problem with this estimation is that it’s very unreliable. Why?

You can’t estimate what you don’t know. I haven’t ever worked on a project where the team, technology and client were the same. At the start of a project we know the least about it. We don’t know what we don’t know. Even if it’s the same team, technology and client, we might still see Black Swan events – rare things with high impact. Maybe a new competitor enters the market. Maybe two trusted engineers leave the company. Maybe you find a bug in a third party that you can’t work around. So how can our estimate be accurate?

The outcome depends on who does the estimation. Many of these early estimates are expert estimates. This means that someone does the estimation, but another team will do the implementation. So there’s a high chance that if you get two different experts, you’ll get two different estimates. So how can you rely on them?

Then there’s waiting time. Anybody who mapped the flow of work (e.g. using Value Stream Mapping) knows that work spends a lot of time in queues. Waiting for approval, waiting for decisions (UX, architectural), waiting for reviews. So why estimate process time, when this is only a small fraction of the total lead time?

Even if you know they’re unreliable, and you make it clear that this is not a commitment, chances are that people are going to remember the number. Once you’ve said it, it will become an anchor, even though we’re not conscious of this. This is also known as the Priming Effect. So, chances are, people are going to make plans based on that number.

Estimating Stories

Story estimates suffer from many of the same issues as project estimates like unknown unknowns and waiting times. But, since they’re for smaller pieces of work, the uncertainty is usually smaller.

I’ve been using agile estimation techniques (poker planning and magic estimation) for estimating stories and features for the last couple of years. And we split stories so that they fit into a sprint (although sometimes we get it wrong and they don’t) and use spikes to reduce uncertainty. So I’m happier with the way we estimate stories. But we still spend time estimating and re-estimating stories, which, as we established previously, is waste.

So what do I do?

Even though I don’t like estimating, I still need to do it. So, some of the techniques I use when estimating are:

• Prefer faster estimation techniques. For example Magic estimation. I noticed that, even if we spent more time on estimating, the estimations wouldn’t get a lot more accurate. So what’s the point of wasting more time?
• Give a degree of confidence in the estimate. For example: I’m 50% confident that we can finish this work in 3 months and 90% confident we can finish it in 1 year.

Conclusion

Is there value in these estimates? I guess there is. A client probably needs to have a rough order of magnitude of the cost. So I guess it can inform him if this is a 1 year project or a 5 year project. Then there’s forecasting: “When will we finish these first 5 stories?” But maybe there are better ways of getting this information, with less waste. This is why I’ve decided to have a look at the No Estimates book by Vasco Duarte. In the next blog post we’re review this book and see if it answers these questions