One topic of interest to all developers is the subject of estimation.
Should it be done in hours? Days? T-Shirt Sizes? Point based? Range based?
In this post I’m going to talk about Range based versus Point based estimation.
Imagine, if you will, two types of gunsights. One the familiar cross type, and the other with a small circle around where the middle of the cross would be.
The odds that the bullet, will go exactly into the middle of the cross, is very unlikely for a number of factors, but the odds that it would go somewhere into a small circle, are in fact, quite high.
This is called the circular error probability. It is the same when playing golf. You may not hit it to a particular spot, 175 yds away, but you might reliably hit it in a circle somewhere between 170 and 180 yds away.
This is what range estimation is.
Instead of saying the task will take 8 hours (point based estimation), say it will take 4-12 hours, or whatever the correct CEP value may be.
There are a lot of advantages to this
- Averaging a large number of tasks like this reduces the overall error in the estimation system, as overshots will be corrected (stastically) by undershots leading to more overall accuracy at the project level
- It prevents the blame game
What’s the blame game? Easy. If you use point based estimation, the odds of getting it right are unlikely. The likely case is you will underestimate, and probably get blamed, or overestimate, and be blamed.
This takes the blame game out of the equation, while acknowledging variabilities in estimates.
Feel free to give range a try — it even goes well with real time units!