“Why would you want a rough estimate, when I can do a more precise one?”
And really, if we can do something better, why do it half way?
There’s a simple answer, but I’ll give it after the long detailed one.
Let’s start by asking again:
Why estimate at all?
There’s a whole #NoEstimates discussion, whether we need estimations or not. Unless your organization is mature enough to handle the truth, someone will want an estimation, believing he can do something with it: approve the task, delay it, budget for it, plan subsequent operations. That someone needs information to make decisions, and is basing them on the numbers we give.
In reality, unless there are orders of magnitude between expected results in estimation it wouldn’t matter. If we had a deadline for 6 months, and the estimation is 8 months, the project will probably be approved, knowing that we can remove scope from it. If we estimated a project will take a year, there’s going to be a 3 month buffer between it and the next one, because “we know how it works”. Things usually go forward regardless of our estimation.
If however, we estimate we need 5 times the budget than what we thought we needed, this may cause the project to cancel.
In summary, the upfront estimation serves making decision. In fact, if you just go with the discussion, and leave the number out, you can reach the same decisions.
So why do we need the numbers?
Numbers are good proxies. They are simple, manageable, and we can draw wonderful graphs with them. The fact they are wrong, or can be right in very small number of cases is really irrelevant because we like numbers.
Still, someone high up asked for them, shouldn’t we give them the best answer we can?
Indeed we should. But we need to define what is the “best answer”, and how we get it.
How do we estimate?
How do we get to “it will take 3 months” answer?
We rely on past experience. We apply our experience, hopefully, or someone else’s experience to compare similar projects from our past to the ones we’re estimating. We may have even collected data so our estimates are not based on our bad memory.
Software changes all the time, so even past numbers should be modified. We don’t know how to factor in the things we don’t know how to do, or the “unknown unknowns” that will bite us, so we multiply it by a factor until a consensus is reached. We forget stuff, we assume stuff, but in the end we get to the “3 months” answer we can live with. Sometimes.
How about the part we do know about – we can estimate that one more precisely. We can break it down to design, technology, risk and estimate it “better”.
We can. But there’s a catch.
Suppose after we finished the project, we find that 30% of it, included the “unknown unknowns” stuff. We could have estimated the other 70% very precisely, but the whole estimation would still be volatile.
(I’m being very conservative here, the “unknown unknowns” at the time of estimation is what makes most of a project).
The simple answer
So here is what we know:
- Estimation is mostly wrong
- People still want them
- It takes time to estimate
- Precise estimation costs more
- Precise and rough estimation have the same statistical meaning because of unknowns.
That means that we need “good enough” estimates. These are the ones that cost less, and give a good enough, trusted basis for decision for the people who ask for it.
Fredkin’s Paradox talks about how the closer the options we need to decide between, it takes longer for us to decide, while the difference in impact of choosing between the two becomes negligible. Effective estimation recognizes the paradox, and tries the fight it: because the impact of variations in the estimates, there’s no need to further deliberate them.
If you get to the same quality of answer, you should go for the cheaper option. Precise estimates are costly, and you won’t get a benefit from making them more precise. In fact, as a product manager, I wouldn’t ask for precise estimates, because they cost me money and time not being spent on actual delivery.
Working software over comprehensive documentation, remember?
| Reference: | The Hidden Cost Of Estimation from our JCG partner Gil Zilberfeld at the Geek Out of Water blog. |
