In a previous post about attending the Agile 2010 conference, I included some quotes from Arin Sime who presented a talk on using range estimates rather than single-point estimates:

  "Single point estimates are almost always overly optimistic."

  "There is a limit to how well a project can go, but no limit to how many problems can occur."

There are many examples out there to show that single point estimation is hard and in fact most people are pretty terrible at it.  See the "Further reading..." section at the end of this post if you are in doubt about estimation woes.

I was able to convince our team to use range estimation rather than single point estimates in our most recent team project. The project in question was building a small datamart that will become part of our larger data warehouse efforts. We received a data feed from an external source and processed it through ETL (Extract, Transform, Load), with most of our work in the "transform" portion of the process. The deliverable was a series of reports on our web site and we now have the data loaded for any future ad-hoc queries.

In our project plan we recorded three values for each task:

  1. Minimum - this would be most people's initial single point estimate

  2. Maximum - maximum reasonable value if things went really wrong with this task

  3. Two-Thirds method - the calculated point two-thirds of the distance between the minimum and maximum.

To calculate the two-thirds point:

  Two-thirds estimate = ( ( MAXimum - MINimum) * 2 / 3) + MINimum

Our initial project plan was not overly detailed, but had about 10 tasks that varied in size from a few hours up to 75 hours (on the maximum side). I believe that the large tasks were too big and should have been broken down. Regardless, the values were agreed upon as being "reasonable" by all members of the project team.

An example task:

  Task: Import raw data into the database
  Minimum: 12 hours
  Maximum: 20 hours
  Two-Thirds method: 17.3 hours

Adding up all of the project tasks gave us the following estimate for total project completion:

  Minimum: 129 hours
  Maximum: 226 hours
  Two-Thirds method: 193.7 hours

My team has not yet implemented Scrum, so after making the initial project plan it stagnated a bit as would be typical of non-agile projects.  We do not have a known team velocity, and we actually estimated in hours rather than "points".  In a lot of ways we did not run this as an Agile project.  However, we did perform a retrospective after the project was completed to see how good or bad we were at estimating.

Our actual time spent on the project was 191.5 hours, or almost exactly the 2/3 estimate!

It will be interesting to see how this changes over time, as we complete more team projects and track our estimating skills.

One observation... many of the individual tasks turned out to be way off from any of the original estimates. Some items took significantly less time, some items took more time. The interesting thing though is that in the end, the totals came out at the 2/3 estimate.

I have become a firm believer in ranged estimates in general, and this two-thirds method seems to be a great tool... especially for teams without a well-known velocity.

Further reading...

  Estimating on Agile Projects by Scott Ambler

  Software Estimation: You are not as good as you think (aka "Why you stink at estimation") by Arin Sime

  Slides from Range Estimation talk at Agile 2010 by Arin Sime

  Software Estimation Using Range Estimates in Scrum by Arin Sime