Monday, 16 February 2009 at 15:10
Using a Geometric Mean to Estimate a Piece of Software Development
My friend Tim was telling me about a problem he'd been having when talking to a client about software estimates and I found myself recommending using a geometric mean, although, right there and then over a deep-fried breakfast, I couldn't remember the precise details - so I'm writing them down here.
A geometric mean is another way of trying to get an estimate, slightly more complicated than just guessing, but not that much more complicated. Say you're trying to guess how long it would take to do a website. First of all, guess the maximum that it would take - say 3 months. Now guess the absolute minimum that it would take - say 2 weeks. Now, before we do anything else, put these things in the same units - 60 (excluding weekends) days and 10 days respectively.
OK, here comes the maths part, rather than "splitting the difference" i.e. taking the arithmetic mean between the two numbers. The book that I've been reading suggest that you take the geometric mean which is:
a = √bc
In our example, that comes out at:
ab = 10 x 60 = 600
√600 = 24.5 days
Of course, the arithmetic mean of the two estimates is:
(10 + 60) / 2 = 35 days
I think using a geometric mean may very well be a good way of "loosening up" people's estimating abilities. And also getting them familiar with landscape of possible outcomes of a software development project. Very often, people are just stuck with one figure and start to react with near hysteria when that line in the sand is passed.
Running a few trial numbers through a spreadsheet, it seems that one of the advantages of a geometric mean might be that terrible pessimism only has a mild effect on the outcome. For example for an estimate where the best case is a fortnight (10 days) and the worst case is a year (200 days), the geometric mean is 45.
By getting customers to think of the worst case scenario - maybe by using "yesterday's weather" of software development projects that they've been involved in in the past and then getting them to imagine the best case scenario, you're detaching them from one single figure and forcing them to grapple, just a little bit with the space of possibilities.
For further information, contact Mark@agilelab.co.uk (07736 807 604) or Matt@agilelab.co.uk (07713 634 830)