Range Estimation versus Point Estimation

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

  1. 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
  2. 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!


About postagilist

Architect, Manager, Developer, Musician, Post-Agile thought leader
This entry was posted in Uncategorized and tagged , , , , , , . Bookmark the permalink.

5 Responses to Range Estimation versus Point Estimation

    • PostAgilist says:

      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.


  1. Pingback: 8 Practical Rules For Producing Decent Estimates « Arialdo Martini

  2. Great great post.
    I used one of your arguments in one of my posts about the same topic.
    I hope you won’t mind

  3. Pingback: #NoEstimates and all that | Post Agilist

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s