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!
PostAgilist
Post Agilist 
This is how I do it:
http://manage.techwell.com/articles/weekly/software-project-estimation
Yes definitely worth reading.
I was going to go into a bit about “shaping” the circle (due to uncertainty or tendencies) using various methods including adding statistical noise to it, which you go into in fair detail in that post.
It might be an interesting spreadsheet template to build; start with a range estimate, then use actual numbers as a feedback loop to determine how much shaping and noising the circle needs to tighten up the CEP, or feed the numbers back to the developers to use in shaping their estimates.
On the subject of uncertainty, I discuss ways of dealing with it beyond the stastical approaches we are talking about here in the “My Approach” page above.
PostAgilist
Pingback: 8 Practical Rules For Producing Decent Estimates « Arialdo Martini
Great great post.
I used one of your arguments in one of my posts about the same topic.
I hope you won’t mind
Pingback: #NoEstimates and all that | Post Agilist