Estimation as Uncertainty Reduction
Drupal Camp Atlanta 2018
Making sense of estimation strategies and understanding why #noestimation is not as crazy as it sounds.
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?
In this session we’ll lay some groundwork with a review of different approaches, including direct estimation, indirect estimation and no estimation strategies, and develop the thinking behind the different approaches.
What are the preconditions for a traditional time against task, or Direct estimation strategy, to work. How about Indirect estimation strategies, such as Planning poker, Story points, Fibonacci spreads or the Cherry-pit Mustang thing; when and why do they work, and when do the fail? “No estimation” may sound like a crazy “that’s never going to fly around here” thing, but you may be surprised to find that in the right circumstances, applying a statistical analysis of actual performance can yield a fairly reliable guide for setting expectations, with the bonus of improved efficiency. At least you should know what it really means and roughly what it would take to get there. Finally we’ll review the practice of estimation calibration, which can help people improve their sense of size, useful when applied to any estimation strategy.
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.