For years, I have been involved with estimating a wide variety of things. I have read about and then experimented with different estimation strategies. I have taught and coached others in estimation. I have worked with, and learned from, hundreds of people who also have a wide range of estimation experience. Throughout all this, I have identified several things that I believe to be true about the act of estimation.
In my experience, the quality of an estimate increases when:
– The work is small. For example, it’s easier to estimate the amount of liquid in your water glass than it is to estimate the amount of water in the ocean.
– The work is near term. We have greater motivation to think through an estimate when we’re just about to do something than if that work will be done at some point in the future.
– The work is understood. Imagine someone coming up to you and saying “I’d like you to update the web site, how long do you think that will take?” The request is far too vague to respond with a reasonable estimate. Until you identify what that update is, there’s a big difference between fixing a grammar mistake on a page and adding an e-commerce marketplace to sell products on your site; you really can’t estimate the work. Furthermore, you also need to understand the architecture of your site and the work processes involved with updating it. Fixing and deploying a grammar mistake may be five minutes of effort or five hours of effort depending on your environment.
– The work is stable. When the requirements for the work change, so must the estimate. What seem to be simple requests, such as asking for multi-currency support in your e-commerce marketplace when you originally said you only needed to support a single currency, can be an expensive and time-consuming change.
– You know who is going to do the work. People are unique, they aren’t fungible resources that you can easily swap. For example, when building a fence, a team of three people who build fences for a living will very likely get it done faster, better, and for less cost than a team of three people who are building a fence for the first time. A master craftsperson with years of experience may be 10 times or even more productive than a novice. In software development, studies have shown that the most productive programmers are 25x more effective than the least productive programmers. And we all know that some people just aren’t going to work well with others, so team configurations are also important considerations.
– The process and tools are understood. When estimating how long it will take to dig a hole for the foundation of a house, it would be good to know if it’s being dug by three people with shovels or one person with a backhoe.
– The estimator is also the doer. Someone who is going to do the work is much more motivated to get an estimate right than someone who isn’t going to do the work.
– The estimate is being committed to. When you know that you’re going to be held to the estimate that you produce you are much more motivated to get it right.
– The estimator has done this sort of work before. People who have done the work before have a better understanding of the issues involved than people who haven’t.
– There are several estimates being combined. In high-risk situations I strive to estimate something using several different strategies, ideally involving different people, and then combine the results to get a better-quality estimate.
– It is treated as a probability distribution. By treating estimates as probability distributions (which they are), and not as point-specific scalars, we can apply our estimates in a realistic manner.
The further away you are from these truisms the less dependable an estimate will be. As the old saying goes, “Garbage in, garbage out.”
This article was previously published as a Disciplined Agile blog on Scott’s website.
