Estimation Types

When I get asked for an estimate, my first response is not a cost, a date, or a functionality number. It is not even #NoEstimates. My first response is a question: “What type of ‘estimate’ do you want?”

What I need to know is what will the questioner do with my estimate. I usually see six action types:

1. They need to make a high probability (practically guaranteed) commitment to somebody else
2. They need to make a go/no-go decision
3. They need to make some tradeoff decision given a set of constraints
4. They want to get a sense of what they are dealing with
5. They are merely curious
6. They want to hold you accountable (and it probably won’t end happily for you)

The problem is, many of those who ask me for an estimate think they want a type 1 (or a type 6) when that is NOT what they need. It is also a problem for many of my agile friends who no longer believe in estimation because all they have known are type 1 & 6—estimation extremes!—and miss out on the aid of types 2-4. (For somebody wanting a type 5, you can just slap them and walk on.)

People think they want a type 1 estimate because, frankly, it would be nice to have. I wish I could predict with high probability just about everything in my life! On software projects, we can always make a high probability project estimate at any point in the project but the Cone of Uncertainty reminds me that the highly probably number I could give would be outrageous early in the project. “Ah, Earl, how long to put up ‘Hello World’ on our existing website?” “Um, type 1 estimate is 4 years.” If you make me give you a early type 1 whole-project estimate, I am highly confident I can meet it, maybe I can even come in before that outrageous number! Type 1 estimates are best suited when the natural variation (Cone of Uncertainty) and the special cause variation (risk) are small. On well run projects, this is usually at least 30% of the total calendar time into the project and we can use data generated from the project. On tasks, these are small, well understood tasks.

While they want type 1, what early project estimates need is a type 2 estimate. Type 2 estimates are the order-of-magnitude kinds of estimates. We create type 2 estimates to let us know if it is worth putting additional work into lowering the natural and special cause variation that can support the creation of a type 1 estimate. If we do a type 2 estimate and decide that if what we are looking at is not even close, we can make important decisions to change the definition of the work or abandon it altogether. We can use type 2 estimates not only early in projects but also at the feature and task levels. One common practice is to decide if a user story is a “story” or an “epic”. Being an epic means it does not fit in our sprint’s aircraft luggage sizer at the gate. If the user story fits, we will consider it for a sprint commitment (type 1 estimate); if not, it needs to be broken down further.

Type 3 estimates tend to happen when we have lower variation than a type 2 estimate but not low enough to really commit. What type 3 estimates do is give us enough insight into the work to help us make decisions that further lower the uncertainty. Type 3 estimates are not about making commitments but answering questions like, “About how much more work would it be if we made ‘Hello World’ blink a lot?” or “Can we fit in ‘Are You There?’ as well, given the schedule?” Unlike type 2 order-of-magnitude estimates, type 3 estimates tend to be much more refined, i.e. their ranges tend to be smaller. Unlike type 1 commitments, type 3 estimates still have a high end that is probably undesirable. We use type 3 estimates as we figure out fit and finish decisions. We also use them during the first half of sprint planning meetings as we nail down acceptance criteria and accept stories into the sprint commitment.

The interesting thing about type 4 estimates is that they are often not about a number but the relationship between numbers. This one is best expressed in the Scrum practice of estimating tasks during the second half of the sprint planning meeting. Here, when a number is given (often hours of effort to complete), we are NOT doing a type 1 estimate but expressing to the rest of team a whole litany of assumptions wrapped up in a number. When I hear my co-worker express that getting the letter “H” in the “Hello World” will take three effort hours to complete, I don’t care about the three per se; I care that it jibes with what I was thinking. This tells me that we are likely on the same page design wise. If what she said was radically different than what was in my head, then it would be time for a conversation. Type 4 estimates are also good at identifying ambiguity in sets of requirements.

The type of estimates we use to get work done on projects is probably around 90+% types 2-4. Don’t get stuck in the extremes. Don’t stop estimating. It is your tool to create information to help make decisions.