The case against #NoEstimates, part 2: why estimates matter

Last time, I provided an introduction to a very odd and very vocal recent movement known as #NoEstimates, which seeks ways to reduce or eliminate the use of estimates in software development. I started off my discussion of it by going through some basic common-sense business reasons to reject it. Those reasons for rejection boiled down to:

• estimates are flat-out natural, ubiquitous, and unavoidable in practical life and in business;
• expressing general reluctance to do them unfortunately reinforces the often negative perception of IT people as aloof, uncooperative, and unsavvy about business imperatives.

Let’s look now at the many other solid reasons to keep estimates in the software development and project management toolbox:

Estimates help in project selection over a wider time frame, and they assist in filling in a project portfolio evenly to align with overall team/company capacity. Specifically: companies often need to determine which projects to sink time and company resources into: e.g., needing to pick just three out of a list of fifteen proposed projects for a given time period. This is a common and recurring dilemma in every company I’ve ever worked at, where demand for various business functionality always exceeds the supply of resources to fulfill it.

In such a ubiquitous scenario, what makes anyone think that the anticipated cost and duration for delivering each potential project should not figure into the decision process that selects the “vital few” from among the many choices? Why would you possibly rule out considering those factors to the best of your ability? Yes, of course they should be weighed along with value, risk, and other factors, but cost and schedule will always be among the key considerations to juggle.

You’re thinking that assessing probable cost and schedule can’t be done, because you’re uncomfortable with uncertainty, and perhaps you might get it wrong? I’m going to be blunt: then you’re not ready to play strategically in the business arena.

Estimates reduce overreliance on experimenting with “red herring” projects. Nothing is wrong with selective and judicious experimentation on a small scale, focused on learning and adjusting, but the universal NoEstimates answer to the project selection conundrum is to “just start”. Well, simply as a practical matter, you can’t “just start” 15 different projects as an experiment and gather enough useful, consistent information on all of them to feed into your decision meaningfully. Even if you could and did, you’d still have to use your gut (i.e., you’d have to estimate) based on what that information is telling you, since very few of the unknowns associated with each of the potential projects would have been eliminated via the short experiment. The NoEstimates panacea of “story slicing” doesn’t help you here at this up-front stage: unless (and even if!) you story-slice the entire project (which would be BDUF), unknowns will almost certainly continue to lurk in your backlog, some big, some small.

There’s simply no way around it: at some point, if you want to choose purposefully among competing options of similar value, you have to take a shot at determining what each project is likely to take (cost, schedule, dependencies), despite imperfect information.

You don’t like it that there’s a possibility that you might get it wrong and pick the “wrong” projects? Bluntly, again: then you’re not ready to play strategically in the business arena.

Estimates help establish a common understanding of what we believe will be delivered, when, and at what cost, and they help us identify key dependencies. With a rational estimating process involved in project evaluation, everyone up front gets to (indeed, everyone has to) talk about those all-important factors, argue about their impact, and weigh in on the various trade-offs affecting the decision. Yes, that understanding may indeed ultimately prove to have been incorrect or incomplete, but the alternative seems to entail little more than proceeding blindly and choosing on utter whim.

Could this kind of deep discussion happen without producing a “number” (the estimate) as the outcome? Perhaps, but the push to produce (and justify) a specific sizing number tends to facilitate such discussion especially well, and force a degree of sunlight onto the underbellies of issues that might otherwise be ignored. It makes you take a relatively concrete stand, far more than just engaging in chitchat.

Do you worry you’ll be blamed if you miss assessing a key factor that later blows your estimate out of the water? Then you’re not ready to play strategically in the business arena.

Estimates help determine level of staffing, marketing budget, etc. Estimates help line up the railroad cars: the contingencies of gated efforts such as ad campaigns and marketing launches, merchandise rollouts, cross-vendor coordinated partnerships, user training curricula, etc. How could one possibly align all that reliably, on time, without making estimates, setting targets, monitoring timelines, and adjusting judiciously as you go?

Are you reluctant to make your team accountable to meet jointly agreed-upon interim milestones that are needed to accommodate other elements in the organization and their tasks on the overall project? Then you’re not ready to play strategically in the business arena.

Estimates help us make collective, reasonable commitments. A willingness to make reasonable commitments leads to a culture of accountability, which leads to high performance when facing a goal. I’ve argued elsewhere that this is fundamental human nature.

Without going into detail about goal-setting theory, I’ll just say it flatly: concrete goals are key to success. Specifically,  “studies involving specific and challenging goals led to higher performance than did easy or no goals.”

Of course: if unchecked, the combination of unrealistic goals, fiat-driven commitments, and subsequent constantly looming and seemingly arbitrary deadlines could turn into the proverbial death march. But let’s focus on avoiding those kinds of bad practices rather than letting our working processes get defined entirely by the possibility of them occurring. Rather, let’s build a culture of accountability, where people understand that in the course of ordinary business, commitments need to be set and that they need to be agreed upon in collaboration. A culture of collaboratively making and reliably delivering on commitments is an enormous positive, and it should never be automatically equated with a culture of fear.

Does it make you too nervous to set a schedule and make a reasonable commitment without perfect information? Then you’re not ready to play strategically in the business arena.

Estimates provide a reference point: a “line in the sand”. When a work item runs over estimate, it can provide a useful indicator that something is awry, or that related assumptions need to be revisited. Without such a reference point, after all, who’s to say that anything has gone awry at all? As George Dinwiddie wrote, “Estimates are based on assumptions, and using them as a hypothesis can provide early notice that those assumptions might be incorrect when actuals differ from the estimate.” In short, the process of estimating, in and of itself, has by-products and benefits far beyond the sheer “number” or other indicator of sizing that emerges at the end.

Here’s a great summary of similar points on the multiple benefits of estimates, translated from a blog post in German:

   Estimates are important …

• so that requirements can be clarified
• so that misunderstandings can be resolved at an early stage
• so that there is transparency about deadlines and targets
• so that task prerequisites and open issues can be clarified
• so that all parties can arrive at a common commitment.

In summary, let’s harken back to common sense once again: given these positive aspects and effects that a rational estimating process can provide, exactly why would anyone state that a desirable goal is “to push forward into limiting estimates, down to zero where possible”? 

Frankly, as is probably obvious, I don’t think there’s a good answer to that question. But in my next post, I’ll go through the various specific arguments against estimating that have been made by NoEstimates advocates, and respond to each one.