To Estimate or Not - That Is the Question
The Agile Zone is brought to you in partnership with JetBrains. Learn how Agile Boards in YouTrack are designed to help teams plan, visualize and manage their work in an efficient manner, with support for both Scrum and Kanban processes.
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.