Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

To Estimate or Not - That Is the Question

DZone's Guide to

To Estimate or Not - That Is the Question

· Agile Zone ·
Free Resource

You've been hearing a lot about agile software development, get started with the eBook: Agile Product Development from 321 Gang

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.

Download the free agile tools checklist from 321 Gang. This guide will help you choose the right agile tools to position your team for success. 

Topics:

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}