Estimation as Uncertainty Reduction
Atlassian Summit — Las Vegas 2019
The whole point of estimation is to support decisions. If an estimate doesn’t help resolve uncertainty about a decision we have to make, then it doesn’t have any value. When pro forma estimates are taken as performance targets it tends to result in negative value. But there is substantial value in the estimation process when is is understood as a a quantitatively expressed reduction of uncertainty based on observations.
Making sense of estimation strategies
As important as estimation is to setting customer/stakeholder expectations and ultimately to paying the bills, there is surprisingly little discussion about what makes for a sound estimation strategy.
There’s an assumption that estimation is something that good developers should be good at, with the unspoken the corollary that failure to meet estimates is somehow the mark of an amateur. Once burned, developers push back that they lack specification. Backlog refinement meetings are scheduled. Time is set aside for technical planning, with expectations set, but often the cycle is repeated, leading to the question, what is this estimation thing?
- Understanding the principle of information entropy as the basis for uncertainty reduction
- How to unbundle assumptions using range estimation
- How to qualify range estimates with confidence interval
- The array of measurement methods using Ration, Interval, Ordinal and Nominal scales
- Analytic, Analogous and Parametric techniques
- Story Decomposition Practices
We’ll go through a number of techniques to verify your estimates.
- When does it take to make traditional time-against-task estimation effective?
- What problems are we trying to resolve with Indirect estimation strategies, such as Planning poker, Story points, Fibonacci spreads or the Cherry-pit Mustang thing?
- What is “no estimation”, really? How would that work?
- estimation calibration, of “sense of size”
We hope to leave you with a better understanding of the various approaches to estimation, and to understand what they’re trying to achieve, to give you greater confidence in the choices you make in this critical area of software development.
Let's agree to define productivity in terms of throughput. We can debate the meaning of productivity in terms of additional measurements of the business value of delivered work, but as Eliyahu Goldratt pointed out in his critique of the Balanced Scorecard, there is a virtue in simplicity. Throughput doesn’t answer all our questions about business value, but it is a sufficient metric for the context of evaluating the relationship of practices with productivity.