This is my personal blog. The views expressed on these pages are mine alone and not those of my employer.

Saturday, 8 November 2014

Solving the Software Estimation Enigma

Software developers are pants at estimation
M. Edmondson

There, I said it.  You and I both know it. It's one of the hardest tasks we face as a software developer. But guess what, there is a way that's worked for me and it's backed up by the likes of 'uncle' Bob and others.

First and foremost it's important to understand an estimate is not a single number. An estimate is a distribution. This means your estimate will be a range of numbers in which the task will complete. Think 6 hours, plus or minus 2.

The reason for this is that you'll always have to make assumptions at some level.  A range takes into account unknowns such as a web service being down, or finding you need to modify a method which uses a wretched spaghetti of reference values or [add your developer woe here].

So how do you create such a estimate? First break down the problem into the smallest feasible chunks of work.  Try to get as granular as you can, but don't worry too much if you're struggling.

Then decide the following 3 timings to complete the task:
  • b = best case
  • w = worst case
  • m = most likely case (i.e.what your estimate would've been before you read this)
b and m are complete edge cases, a one in a lifetime event.  For the maths to work these must have less than 1% chance of actually occurring.

Then simply plug them into the following equation to get the first part:

e = (b + 4m + w) / 6

v = (w - b) / 6
These two sets of magical numbers let you know:
  • e, how long the task will take
  • v, the variation on this number
You therefore tell the project manager / business the task will take:
"e plus or minus v"
This has rewarded me with surprising accuracy whilst also providing the benefit of communicating your certainty (v).

Do you agree?  How do you solve your estimation enigma?

1 comment: