Agile Zone is brought to you in partnership with:

Kelly Waters is Web Technology Director for IPC Media, one of the UK's largest publishers of consumer magazines and web sites. Kelly has been in software development for about 25 years and is a well-known narrator of agile development principles and practices, as a result of his popular blog 'Agile Software Development Made Easy!' (www.agile-software-development.com). Kelly is a DZone MVB and is not an employee of DZone and has posted 40 posts at DZone. You can read more from them at their website. View Full User Profile

To Estimate or Not - That Is the Question

06.03.2009
| 1898 views |
  • submit to reddit
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.
References
Published at DZone with permission of Kelly Waters, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: