169.03% Estimation

Software development estimates is an art. When nothing is in place, assumptions should be done to build more realistic estimation based on what software architects/developers are providing. Even if there are many ways of padding estimates, usually based on experience, here is the technique I successfully used in the past.

I based my estimation technique mainly based on the PERT estimation technique. This technique is simple, it assumes that the realistic estimate has a weight that is 4 times more heavy than the optimistic and the pessimistic estimates.

So, the optimistic estimates are always provided by the development team. Usually, I ask to provide high-level estimates with a 50% level of confidence. Adding 25% overhead (10% management, 10% QA, 10% Operations) , we can build the realistic estimates by multiplying their number by 150%.

Now, it’s time to build the pessimistic estimates. If we are taking into consideration that development teams are

• not taking into consideration back-and-forth to clarify requirements (25% ?),
• their time while doing QA (25% ?),
• refactoring (25% ?),
• that they were optimistic in their level of confidence (100% instead of 50% ?) and
• the management overhead,

It’s a bit more than 3 times the original estimates that should be calculated. Going as far as 3.5x or 4x is not very credible to any manager… but a 3x is just too… round. So, I usually fall back on a scientific number, PI, which is 3.1416. If the organization is really mature, there are another numbers that could be used. The Euler’s number (2.7118), the square root of 5 (1.9021) or 3 (1.7320), but I would never go under the Golden Ratio (1.6180) … remember, these are estimates.

So, here is my calculation to build estimates: (Estimation + (4 x (Estimation x 150%)) + (Estimation x 3.1416)) / 6

or for simplicity, you can just use (Estimation x 169.03%).