What Is Estimation?
uncertainty reduction beats prophecy any day
Project managers and developers are routinely asked to navigate ambiguity, such as being asked to produce an estimate against some hazy business objectives, or making firm commitments against obviously changing scope. But as important as estimation is to setting stakeholder expectations, almost everything I’ve read about software estimation isn’t really about estimation; there is a lot of discussion about managing the estimate in the development process, but there’s not a whole lot about what estimation actually is, or how to do it.
The heart of science is measurement
— Erik Brynjolfsson
Typically, when we’re asked for an estimate, we assemble our domain experts to size things up and have them take a stab at the most likely outcome for a task, expressed as a discrete value. By discrete value, I mean something like 1 week, 3 days, 4 hours: a value that is in the area of what we think will be the most likely outcome. To understand the implications of discrete value estimates, we need to consider how assumptions are handled.
The estimate is often taken as a target, a commitment for the developer to live up to, a promise to stakeholders on when something will be done.
We expect that after the work is done, the actual cost will turn out to be different from the estimate, because we know that there are factors that we don’t know about, or that we can’t control, which will affect the outcome.
So as we estimate, we substitute these unknowns with assumptions on what they might turn out to be. For example, if we’re estimating a story that is built around an unfamiliar 3rd party API, we know that there is a risk, but we don’t know where. It’s supposed to be a RESTful API, but who knows. When providing a discreet value estimate, we increase the size of the estimate to accommodate this uncertainty. The amount of increase becomes an implicit component of the estimate, representing our assumption about the nature of that risk.
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.