Obviously, it is not estimates that are needed, but decisions. Simply because someone you report to requires that you provide estimates does not mean that it is a reasonable or useful approach to making decisions. It is merely the approach that is in place. However, if it is not your job to improve this process, you’ll have to put up with it.

Cheers,
Woody

So if I have to decide to develop or buy a solution to my cost management system for a government program. Let me see if I can walk this through.

(1) We own PeopleSoft and it’s procurement management system. That system is not well suited to customer (our customer) owned materials – We’re a Government Owned Contractor Operated facility. We could augment the processing, data, and UI for PS to deal with the subtleties of the GOCO environment.
(2) We could develop a separate cost management system using tools we are familiar with – J2EE connected to PeopleSoft.

How do I decide? We have an annualized budget for Operations, Development, and Maintenance of the product built here. There is a set-aside for just such things as we want to do. That budget is flowed down from the HQ of our customer every Oct 1st.

I need to decide to built or modify. I have a due date of end of calendar year for use, since the people wanting the capability have a due date to report to the Govt HQ the information they need.

How do I decide in the absence of an estimate for both options, showing that I have enough or not enough budget to do the work?

Thanks for you kind words. I’ve used the Grand Canyon hike as an example for many years. I’m sorry I had to tie it into software. This could easily be more “general” in nature as you noted. I’ll do better someday, I promise!

Cheers,
Woody

+ Michael

Having worked on both sides – defense/space and commercial IT – much can be learned on estimating in the presence of uncertainty for the IT side.

One critical starting point for “How and How Much” estimating is the answer the question, what is the value at risk? This establishes a baseline for the investment in estimating. High value at risk, better estimates.

The next understanding – in our domain – is that estimating is not “guessing.” Personal estimates, subject matter estimates are the least desirable. Reference Class Forecasting is a processes used for software intensive systems. RFC http://goo.gl/qsm6a provides a starting point for the estimiates. All estimates must be statistically adjusted for the reference class. New developments make use of RFC as well.

- This feels big, how do we break it down?
This is a size estimate—relative size. “Big” must be relative to something, so assumes other items of work are being done by the same person/team that are smaller.

- This will cost a lot—what’s the value it’ll give?
This is a cost estimate, followed by a request for a value estimate. The two together determine if the work should progress.

- These things seem quick to do…
This is an effort estimate. We guess these things will not take much effort, and will be completed quickly.

- I reckon I can get this done by Thursday.
This is a time estimate. One presumes it follows a sizing estimate for the speaker to have some sense of how long it would take.

- This is taking longer than we thought—can we simplify it?
This is a re-estimation of size after the work has been started, and more is known.

- We can probably get something meaningful for release in about 3-4 weeks.
Again, a time estimation. If the date is important for some reason I’d recommend checking in regularly (weekly or less) to see if the estimate of 3-4 weeks continues to be realistic, and if not looking for ways to either narrow scope or reset the date.

These are just some of the ways people estimate. Estimate (vb): to form an approximate judgment or opinion regarding the worth, amount, size, weight, etc., of; calculate approximately. —dictionary.com

If you consider my examples non-estimates I’m interested to know the definition you are using when you use the #NoEstimtes tag. If it’s something like “to talk in detail about a large group of items, and and give them effort numbers which are then used to make commitments” (or some other refined meaning) then it may be helpful to be explicit. As it is now, the #NoEstimates movement is rather confusing, and seems to generate semantic disagreements rather than useful dialog on practices. Which is a shame.

I’m in favor of estimating as a starting point for conversation:
- This feels big, how do we break it down?
- This will cost a lot—what’s the value it’ll give?
- These things seem quick to do…
- I reckon I can get this done by Thursday.
- This is taking longer than we thought—can we simplify it?
- We can probably get something meaningful for release in about 3-4 weeks.

Software development, like all creative making envisions a desirable future state. As we work, we make guesses on aspects such as cost/time/value. We can call these guesses estimates, or assessments, or projections. The term isn’t important. The truth is: they are guesses. To not make any guesses feels unnatural and contrived to me. The purpose of estimation is not to make promises. It is merely one factor that can lead to more meaningful conversation.

Guessing about the future is a useful, and natural human behavior. We use experience, gut feel, history to improve the quality of our guesses. Perhaps as well as seeking ways not to estimate (a useful pursuit, for sure), we can also seek ways to make our estimation practices more meaningful.

Apart from removing waste, not doing estimates has a big advantage; it encourages customers/business owners to become more involved while the work in progress because they want to ensure they are getting good value. This means we get more feedback and they get to say when we’ve gone far enough with the story.

So yeah, I think you’re right there is real value in exploring not doing estimates in product development. I feel for from qualified from making a judgement in other peoples contexts although I applaud your efforts in encouraging people to explore alternative in their situation.

Developers need stories in the backlog. That’s it. They don’t need estimates. Estimates have little to no value to visioning or producing a software product. In my experience, estimates are mainly championed by people who make a living off of the illusion of control that numbers give managers.

Folks on the conference circuit love to blather on about estimation techniques. It all seems kind of silly to the producers. Real (hours) or fake (points), most developers either underestimate (because of hubris) or sandbag (so they can gold plate, learn new stuff, or surf the web). Either way, the illusion of control is just that – an illusion.