Estimating increases your knowledge in uncertainty, creating value through changing commitments to options.
Now I’ll say at the outset, I agree that estimating is a hazardous exercise, filled with sources of error, some of which are themselves poorly understood. And that this is particularly true if you are estimating something that truly has little or nothing in common with anything you’ve previously delivered (otherwise you’re simply estimating by analogy, which is perfectly fine).
And yes, sometimes organisations estimate because estimating is what they do. It can simply be a ritual.
And yes, the outputs of estimating are frequently misused far beyond their prescribed capabilities.
When you see a "good" estimate, ask yourself: "how much did that estimate cost?" and "what could we have built with that money? #NoEstimates
— Vasco Duarte (@duarte_vasco) August 8, 2014
Estimates should not be confused with quotations or deadlines (although they may be a factor in defining both of those). They are not promises, nor should they be only concerned with cost and schedule. They are an expert assessment of all kinds of factors, including quality (another misused and misunderstood word!), people capacity and technical capability.
However, let’s think about a couple of the needs that are often behind a request for an estimate, rather than simply going on and doing the work. Often the thinking is as a method of risk reduction – reduce the uncertainty around the risk that the work will cost more than it’s worth, or (worse) that it will cost so much that we can’t afford to finish it, so don’t get any value. And you could apply the same questions to schedule, technical risk or any other constraint.
Now you might think that this is a foolish quest for certainty. But usually the people looking for estimates aren’t that stupid. They’re generally not expecting a perfect estimate, that is correct to the penny.
But what they are looking for is a material reduction in uncertainty. That gives them a better idea of what to expect before deciding to do it, and gives them a more solid option to not do it. Effectively, what you’re doing is converting a commitment into an option, which is (nearly) always a worthwhile exercise.
Options are valuable. Options expire. Don’t ever commit early without knowing why.Chris Matts
If you’re creating value, it follows that the work that you undertake to create it cannot be waste.
The bigger question therefore is not whether estimating is valuable activity, but is it valuable enough? Is the value of the option worth more than you pay for it? Can you create the same (or near enough) option in an easier way? This is why lightweight rapid relative estimating (Blink Estimating, Storypoints or even Sweet Wild Ass Guesses) can be powerful. All these methods have their own weaknesses, but they’re all more useful than not doing them. Even if all the estimating work does is give you added discipline to understand the work better before committing to it.
So yes, we need to be very careful not to boil the ocean in creating estimates that outweigh the value they create.
If you’re thinking about producing ‘good’ estimates, stop, and think instead about producing ‘good enough’ ones.
My programmer friends I’m sure will be thinking at this point: what about a technical spike? Absolutely, that would be another method of assessing technical opportunities and risks which might inform other estimated factors.
However, there’s often a bias inherent there: assuming that work you understand better will give the better outcome. It’s the kind of thinking that often leads to Dilbert-thinking: that management must be incompetent idiots because they can’t do what we do, and we don’t understand (or even see) what they do. And leads people to create axiomatic, circular definitions for Estimating as A Bad Thing.
Which is often the kind of thinking that got us here.
It’s a variant on the power play of
We should be in charge around here. It’s ugly. Don’t do that. You’re usually up against better power players when you try it anyway.
That was 638 words, but this summarises it beautifully in 16:
Before you're asked to estimate, ask: "Can this assumption be proven faster, cheaper in smaller batch?" (see prev tweets) #NoEstimates
— Henrik Ebbeskog (@henebb) August 7, 2014
Latest posts by Martin Burns (see all)
- Colocated Teams, Distributed Organisations - January 20, 2018
- Christmas Reading: 6 Books That Will Change Your Thinking - December 22, 2017
- Now Is Not The Time for #NoProjects - December 14, 2017