Understand one thing before jumping into #NoEstimates debate: product and software development for *real* use is a DISCOVERY problem, not a delivery problem. Estimation focus on delivery, not DISCOVERY
To discover anything we need to pay for that discovery. How much are we willing to invest to make that discovery? When we arrive at the discovery, was it worth the investment?
This is the Value at Risk paradigm that can be implemented in real options. [1][2]
If we don't make the estimate of the cost to achieve the Value at Risk, then we will only know if that investment was worth it too late to either cancel the effort or change our formula for justifying the investment.
This is the sunk cost fallacy that plagues most of the programs we work in our software-intensive system of systems world.
The Sunk Cost Fallacy. The Misconception: You make rational decisions based on the future value of objects, investments, and experiences.
The Truth: Your decisions are tainted by the emotional investments you accumulate, and the more you invest in something the harder it becomes to abandon it.
To avoid the sunk cost fallacy and assess what cost you are willing to commit to for the Value at Risk commitment, you need to make an estimate. It can be a not to exceed estimate, a rough order of magnitude estimate, but it still needs to be an estimate.
There is NO principle by which you can make a credible, risk informed decision in the presence of uncertainty without estimating to impact of that decision.
Redefining the terms Discovery and Delivery does not change the need to estimate. Since delivery requires you discover what to deliver, the order of the deliverables, the dependencies of the deliverables, the uncertainties (reducible and irreducible) associated with the discovery processes that produce the deliverables.
The Fallacy
The fallacy is that Estimates are not needed during the discovery phase of the product development. Estimates are in fact critical to the business performance, the managerial finance activities during that discovery phase. This is the very basis of managerial finance, the microeconomics of decision-making for product development. Microeconomics is the basis of our decision-making processes when we're spending money in the presence of uncertainty, scare resources, and need to decide between multiple choices.
If you don't need to decide, if you have no uncertanties, if you don't have scare resources, then go right ahead and spend other people's money without estimating the outcomes of your decisions.
Just to restate the principles of why we need to make estimates in the presence of uncertainty, no matter what we're working on...
Microeconomics is a branch of economics that studies the behavior of individuals and firms in making decisions regarding the allocation of scarce resources (time, money, facilities, and talent) and the interactions between individuals (inside and outside the firm) and firms themselves.
See for some more background on Microeconomics and decision making in the presence of uncertainty for projects - and uncertainty is ALWAYS present on projects, especially software development projects, start here...
- The Microeconomics of Decision Making in the Presence of Uncertainty - Re-Deux
- The Microeconomics of a Project-Driven Organization
- Behavioural Economics, Estimating, and Decision Making in Presence of Uncertainty
- Economics of Software Development
- Economics of Software Development, second edition
Resources
[1] "Value at Risk in Real Options," Giuseppe Alesii, Review of Financial Economics, Volume 14, Issues 3–4, 2005, Pages 189-208
[2] "Value-at-Risk Analysis for Real Options in Complex Engineered Systems," Rania Hassan, Richard de Neufville, Oliver de Weck, and Daniel Hastings, and Douglas McKinnon, IEEE SMC, 2005
