Software Development Estimates, An Analogy

In my previous role there was little understanding by the business of what software development actually entailed and perhaps the biggest source of tension were estimates, which were completely and utterly misunderstood.

An estimate was taken to be a firm guarantee of delivery and thus any delays in hitting the expected delivery date was taken as a failure. 

I tried different things to try to explain the intricacies of estimates:

• The Dictionary Approach

Essentially, remind the business of the dictionary definition of an estimate, namely: An approximate calculation or judgement of the value, number, quantity, or extent of something.

• The Probabilistic or Confidence Level Approach

Provide a probability associated with the estimate, e.g. I have 75% certainty that this feature will be completed within 5 days and 99% certainty that it will be completed within 8 days.

• The Error Bar Approach

Provide the estimate with a error level to take into account estimation errors, e.g. This feature will take 5 ± 3 days to complete.

The final approach, which worked reasonably well, was The Analogy Approach, but first a little story:

About a year into the job, we had a meeting in Birmingham, for which Google Maps estimated a travel time of 1 hour and 10 minutes, however it took 2 hours. 

There had been an accident leaving the office so traffic was slow, we were stuck behind a tractor for a few miles and then there was more slow running on the motorway.

A few weeks later, we had another meeting in the Birmingham area, Google Maps estimated a driving time of 1 hour and 5 minutes and this time we made it in just over one hour.

So The Analogy Approach is to use an analogy easily understood by the business namely:

Software development estimates are like the travel time on Google Maps.

This works really well as an analogy as heavier than normal traffic (problem is harder to solve the anticipated), accidents (laptop has decided to give up the ghost), being stuck behind a slow moving vehicle (waiting for another developer to complete his/her part), rerouting (having to use a different approach to solve the problem) are all unplanned and unforeseen delays that affect travel time in the same way that development estimates are hit by unplanned and unforeseen issues.

I would like to say that my analogy solved the issues once and for all and that I was never challenged on an inaccurate estimate, but I would be lying. What I can say was that I had a clear and easily understandable analogy to remind the business when challenged on another inaccurate estimate.