To Estimate or Not To Estimate? That is the Question!

To Estimate or Not To Estimate, That is the Question!Lean software development shares many of the key principles of agile software development.

Although one of the key aspects of lean development is all about identifying and eliminating waste from the development process…

One of the most hotly debated aspects of this is estimating. It clearly doesn’t contribute to the end product itself, but is estimating really waste? Or does it really add value to the process?

This post on the LitheSpeed blog, ‘To Estimate or Not To Estimate, That is the Question‘, asks exactly that.

The answer? I guess it really is a matter of opinion. My personal answer – Like most things in life, I think it depends!

I think I agree with Sanjiv. If you’re working on high priority bugs, in severity order, and they must be fixed, estimating how long they will take provides little value, except to help manage expectations about when the bugs might be gone, which may or may not be useful depending on your circumstances.

On the other hand, if you need to create a business case in order to secure funding for a special project, or you need to commit to a deadline to fit in with other dependencies like a launch date, estimating is clearly necessary, whether it adds value to the end product or not.

I think actually that’s really the wrong question though. Clearly there are many scenarios in business where you do need to estimate when something might be done. But you may not need to estimate the size of each feature or the effort of each task in order to predict a delivery date.

With a large enough sample size, keeping track of the average time per feature, or cycle time, could potentially be a reliable way of predicting how long something might take, without actually estimating it.

My concern about this approach is that, statistically, all items must be as near as possible to average to achieve any level of predictability on a single piece of work. I’m sure on a large project, everything averages out. By definition it must do!

But on smaller pieces of work, where you’re working to short timescales, any feature that is higher than average gets delivered later than expected. And that can cause problems.

Kelly.

Photo by bushn

One Response to “To Estimate or Not To Estimate? That is the Question!”

  1. Mike Bria says:

    Good post. I particularly like and agree with the point that “estimating” (when required) does not necessarily imply putting numbers on individual stories. Really, it’s obvious, but always overlooked.

    Also, wanted to point you to a related read I posted on InfoQ last August:
    http://www.infoq.com/news/2008/08/estimates-wasteful

    Cheers!
    MB

Leave a Reply

What is 1 + 1 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”

DAN PULHAM, DIGITAL DIRECTOR
TELSTRA