« March 2007 | Main | May 2007 »
April 25, 2007
The Truths about Estimation
Recently, I've been overhearing collegues going through a lengthy estimation process - and all the angst that accompanies such exercises. Doing so reminded me of my own estimation nightmares and some of the general rules I've developed/appropriated which I thought I'd share. Probably not a whole lot new and/or original here, but putting these thoughts to paper is a good way to remind myself of what's important...
Estimation is just guessing
Dress it up with fancy names all you like, but at it's heart an estimate is a guess. Whilst I wouldn't recommend using these terms synonymously with clients, so many of the problems people have with estimates are based on over-reliance of their accuracy, so a little expectation setting generally doesn't go astray.
An estimate is not a quote
This is an old chessnut, but I found myself explaining the difference between the two terms to an experienced client PM recently, so perhaps it's not as common knowledge as I'd thought...
Think of it this way: ask someone how long it takes them to travel to work each day. Now ask them the same question again, adding that if they're later than they said, they'll be fired immediately. Now look at the difference between the two responses. The first is an estimate, the second a quote.
All estimation is analogous... eventually
Analogous estimation is the technical phrase applied to the technique of "if it looks like a duck and walks like a duck, then it will probably take 10 weeks because I built a duck last year in 10 weeks". All estimation models were derived from empirical research and are therefore effectively analogous estimation.
Why is this important? Because once you realize that all estimation models are based on numerous highly variable assumptions, you start to see the reason why so many estimates are staggeringly inaccurate.
The quality of the estimate will not exceed the quality of the analysis upon which it is based
I think this pearl of wisdom was passed to me by Robin Gibson a few years ago - not sure of the original source.
This is another take on the Garbage In, Garbage Out principle. In short, you cannot expect a high quality estimate without high quality analysis as input into the estimation. If there are high levels of risk around requirements or large numbers of requirements are missing, then the quality of the estimate will suffer. There is no way around this.
The precision and scale of the estimate should match
(I've seen this one in popular software engineering literature somewhere, but cannot for the life of me remember where.)
There's no point presenting an estimate for several years of work in days. Similarly a short estimate of a couple of days should not be presented as a fraction of a month. Make the precision of the estimate similar in order to the scale. In other words:
| If your estimate is... | ... then it should be presented as |
| 800 days | over 2 years |
| 350 days | 1 year |
| 125 days | 4 months |
| 20 days | 1 month |
| 11 days | 2 weeks |
Given the imprecise nature of estimation, there's no point in over-specifying the precision: doing so will lead to a false sense of confidence in the accuracy of the estimate.
There are always too many variables in an estimate to quantify/predict
So assuming you did build a duck last year in 10 weeks, how likely is it to take 10 weeks this time around. Consider the following:
- Is it exactly the same sort of duck? Are there no hidden requirements that end up making it more of a goose?
- Will you be using the exact same team as last time? The same developers? The same testers? The same BAs? The same infrastructure and support teams?
- Will you be using the exact same technology stack as last time?
- Will the environments into which your duck is being deployed be the same as last time, or is there a new version of PondSphere (TM) to contend with? And a new team to manage the deployment?
- Does all forms of duck manufacture now have to be certified as SOX compliant?
Invariably the answer to at least one of these questions is "no", at which point your use of analogous estimation will give a rough guide at best.
Padding an estimate only gives the impression of accuracy
Although most people have seen the research stating the only way to truly get accurate estimates of any kind is to get right into development, I've worked in many environments where estimates within a 20% tolerance are required well before any form of development has commenced.
Practically, the illusion of accuracy is usually achieved by padding the estimates so amply that the risk associated with early estimation techniques is mitigated by the size of the contingency.
Achieving accuracy in estimation isn't worth the effort
Of course, this all depends on your value system, but I think it is fair to say that there should be more important things in a development project than accurate estimates - faster time to market and responding to changing customer requirements being some of them.
Unfortunately, I've seen way too many project environment where external constraints (often project budgeting mechanisms) force accurate estimation and planning to be a more highly held value than they perhaps should be.
Estimates are quantifiable, people aren't
For some inexplicable reason, people working on software development projects tend to not like being considered as quantifiable resources with predictable behaviour. We're still some way from generating an estimation model that can factor in the marriage breakup of the lead architect half way through the first release and the growing animosity between the BA and PM since the Christmas party.
But as long as people accept that an estimate is a guess likely to be inaccurate for the vast majority of the time, this shouldn't be a problem, should it?
Posted by Andy Marks at 04:35 PM | Comments (0) | TrackBack