Simple estimation rules for young programmers: 2,3,5

I am not a project manager-born killer, but I learned a lot in my tiny life (and with 20+ experience, I am more or less in the middle of my career).

My rules when I must do an estimation are

1. Tune your estimation on the context. To make simple the explanation, I will divide the estimation in categories; for instance take the fine grained and big cost estimation ones. All fine-grained estimation tasks should be between 2 and 10 days (it is an example). Big cost models are done with 10x or 20x days multiplexer Avoid mixing small estimation with bigger one (i.e. do not mix a task of 5 days with a task of 20 days, reason below).
2. Never never never estimate a task less than two days. As one of my boss said, if you ends before your estimation, no one will complain; but be late of a day...also you have no chances to increase it after declaring it. Every time you open your IDE or answer to a call, two days are gone. In a small company I worked for, it was forbidden to have less than two days on a SAP time capture, because admin's customer invoice management overhead was higher than supposed gain.
3. For fine grained estimation follow the 2,3,5 rules, if possibile

If you follow me, you will end up with a set of tasks with a low standard deviation from the average value. Why this is important? Because estimation is an art.

Suppose you have done a wrong estimation on a task, haven't you?

On average, small estimation error will cancel themselves.

For instance if "Setup Java ORM" will take 6 days instead of 4, and "Setup new maven project" will take 2 days instead of 4:

Estimation 4+4 = 8

Reality: 6+2= 8

Instead if you make a wrong estimation of +10% on a 20 days task and the opposite error (-10%) on a 2 days task....

Estimation 20+1 =21

Reality  22 (+10%) + 1 ,8( -10%) = 23,8

As you see you cannot compensate the tiny one with the big one, and if you have plenty of tasks with this delta, your project is almost useless, believe me.

The Agile smart way

Another ingredient is the ability to estimate.

Human senses are logarithmic. You can tell the difference between 2 grams and 10 grams, but not between 10Kg and 10,20 Kg. The same seems apply to planning and events prediction.

So we are very good to estimate very small tasks, but we suck for huge task estimation.

On some big banks, the demand excel for external supplier is a killer for wrong small estimate (it will catch them easily) but it is fair coarse for big one.

Agile planning poker solve this issue with sequence like

1, 2, 3, 5, 8, 13, 20...

The idea is to avoid the easy "everything is 10 days"... and to push forward huge numbers on tasks we already know we suck to predict (=the huge one).

My humble suggestion is to use a strict sequence like 2,3,5 

 

Last but not least, the Dilbert strip https://dilbert.com/strip/2007-09-03