Be More Productive

Get the most from your processes now!

Tuning into Predictability

Covid Cancellation

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.

Estimation vs Prediction

Predictability builds and holds trust, a core Agile value, better than does delivering more with less reliability.

— David J. Anderson

Estimation is not prediction, and predictability does not result for forecasting future events. Predictability in software delivery is achieved by identifying and eliminating constraints on the flow of work. You don’t have to estimate the work in order to achieve flow, at least not in the way most people think of estimation: assigning time values to forecast the effort that will be required, pretty much as waste of everyone’s time.

Many teams embracing #noestimation forego the numbers game altogether, using more reliable flow metrics against unestimated work provide a more accurate read on future team capacity.

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.

pattern language

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.