To Estimate or Not To Estimate? That is the Question!
by Kelly Waters
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.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
Photo by bushn
2 June 2009 13:20
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