The conversation on Twitter around No Estimates #NoEstimates brings a smile. Here's some samples
- Marketing needs a rough idea of when alpha-level code will be available. Allowing a few weeks for alpha testing and a few more for beta testing provides a time line. That may well be good enough.
That's called an estimate. A rough estimate for sure, but it's an estimate
From the same blog (a good one BTW)...
- We're on an enterprise system now and management needs to know how long and how much cost it will take to get to a Minimal Viable Product. The first release has to be functionally complete in order to be competitive. Everyone understands that this effort will take several months to get to beta-level code. Management needs some idea of what they’re getting into, how long it will take, and how much it will cost.
Now we're into the realm of actual estimating
Are No Estimates Better Than Estimates?
Before answering this another question needs to be answered...
What is the value at risk?
This means how much money and time are you willing to risk without understanding how much time and money is at risk.
So before anyone can answer the question about estimating value, that question needs to be answered by the owner of the money. NOT to consumer of the money.
This at risk question rarely comes up in the agile world. It doesn't come up enough in our formal FAR/DFARS acquisition work either. The at risk question is a risk management question. Agile claims to be a risk management process - which of course is laughable in our DOD/NASA/NRC/FDA/NNSA risk management world. All software intensive by the way.
So before venturing further, what's the value at risk must be answered. Then the owner of that risk, can tell those who should be working in the best interest of the owner of the risk, if an estimate is needed. Not the other way aorund.
Without this answer, the discussion on #NoEstimate is just sharing of personal opinions in the absence of any value at risk.
