Rough Order of Magnitude Estimate

author: Daniel Hjort date: 2010/11/25 location: Shanghai, China tags: estimate, planning, repost

In the recent article Avoiding the Infinite Abyss Andy Hunt writes about how the sheer amount of choice (like any natural number of hours) can paralyze the person/team doing the estimation of a task. He suggests using a limited number of choices like 1 hour, 1 day, 3 days and a week.

This reminds me of Rough Order of Magnitude Estimates. A technique used by for example physicists to make quick and often accurate enough estimates of natural phenomena. Often this is as close you can get with out actual measurement and calculation. And if we could calculate how long a software development task would take to complete based on measurement software development would be a lot different. So stick to rough estimates. Anything else is a waste of time.

Addendum (2011/09/18):

I found a preceeding article by Dan North about the perils of estimation.

He also adds this point:

To compound this, it turns out that estimation is fractal. The more fine-grained you break down the requirements, the more “edges” you will discover. This means that the more detailed you estimate, the more the total will tend towards infinity, simply due to rounding errors and the fear factors that we multiply into fine grained estimates.

This is something I have noticed but not really reflected enough on.

So he takes the above even further:

The experienced members of the team should be estimating feature sets of the order of person-weeks (or better yet, pair-weeks), not going down to the level of individual pair-days.

More effort can/should instead be put into deliberate discovery of the project risks.

Addendum (2011/09/30):

Taking it yet another notch, Jørn Hunskaar, say we could just give up on estimates:

Not giving any real value anymore, we decided to stop estimating stories. Later, when we applied Kanban, we removed the iterations as well. We’ve managed well without estimation for about eight months now, instead focusing on the flow and maximizing throughput.

Very interesting idea.

Addendum (2013/03/22):

Joshua Kerievsky writes about the perils of story points and the waste of overdone estimations.

He has been using variable length sprints and estimates on 'team week' level focusing more on the flow.

Addendum (2013/04/08):

In a tweet Jason Yip writes:

"If you say you "can't possibly estimate", I'd suggest looking up 'Fermi estimate' and read How to Measure Anything."

Addendum (2013/05/15):

Woody Zuill wrote a blog on how some software companies perhaps can use customers need for estimates as a filter when taking on work. If the customer need an estimate they most likely also have a Waterfall mentality and might not be a good fit for an Agile shop.

[ IndexPage | Edit on Github | Powered by PotBliki | © 2010-2014 Daniel Hjort - CC BY-SA 3.0 | ]

blog comments powered by Disqus