I recently asked a group of engineers, product managers, UX, and QA this question. Here’s how they replied:

We use estimates to/so/because _____________________

• To force a conversation about each story … especially the complex ones
• So we can fill up our sprint with a certain number of story points
• To keep our work sustainable, and not commit to doing too much (in a sprint)
• So we can tell someone when the project will be done
• So I can communicate the current status of the project
• So I can point out how scope creep will impact the delivery date of the project
• So I know when the team will be ready to pick up a new project, and I can work with the project stakeholders to clarify requirements
• So we can measure the team’s effectiveness
• To prevent a shared resource from getting overloaded
• So we can measure individual contributor effectiveness
• To aid us in prioritization. We want to find small / valuable features
• Because that’s what you do in Agile, right?
• To hold people accountable. With a velocity goal they’ll be more motivated
• To add them all up, and figure out what is possible or not possible by a certain date
• To divvy up the costs for individual projects. Time tracking was too difficult so we used the estimated points instead
• So that we can measure the ROI for particular projects
• To calculate project risk. It is all about risk vs. reward How many of those feel like “good fits” for estimation? How many are bad fits? Might there be other ways to achieve the same end goal(s)?

In reading this list, consider these recurring themes:

• batch sizes (“large” vs. “small” projects)

• the Scrum methodology, and fixed iteration lengths

• External team dependencies and stakeholder needs

• The role of deadlines in your business model

• Performance management practices

• Level of trust and safety

• Accounting practices

• How teams are assigned to projects. Team autonomy in terms of selecting/pursuing solutions Team 1: “When will you be ready for us?” Team 2: “When will YOU be ready?”Depending on your context, you may be leveraging estimates to address multiple goals. Many of those goals are context dependent. If you can control certain variables in your environment, you can narrow the “job” you are hiring estimation to do. And frankly, some of these things are best served/achieved through other approaches. In those cases, estimates aren’t the best (or even a barely acceptable)

  tool for the job.

Given the list above, I can pick out 5–7 that have nothing to do with estimates or estimation.

Context matters. Let me pick a context from the last five years of my career (B2B SaaS):

• In optimization mode, we were releasing 5–10 improvements weekly (mini projects)
• We didn’t work in fixed iterations
• The work culture valued sustainable habits
• Teams were aligned around moving a particular metric. Many of the “projects” failed (we aborted the experiments early) while we doubled down on other efforts when they moved the needle
• We had minimal external dependencies
• Teams were measured in terms of outcomes produced, not code shipped or projects finished Or course #NoEstimates critics will tell me I don’t live in the real world, that I’m irresponsible, and that this is not how real business happens. Let me go hide in my imaginary cave and cower. But wait … we were still estimating.

In my context, estimates had a narrow job. The efforts were small. We didn’t need to thread the dependency needle. No customers were expecting things by specific dates. No marketing people needed to be informed months in advance of a release (a week’s notice was fine). You could calculate costs easily just by looking at the cost of the team. And the nature of the SaaS model meant that we were always adding/removing functionality from the product. There was very rarely a definitive done….as we were always adding/removing. We’d be pretty safe to answer “10–15d” for anything we were currently working on, and we’d be pretty close.

So stepping back, the “cost” was fixed, and the ROI was measured by looking at how the team tracked against improving specific metrics (and some agreed upon value for moving those metrics). And even still we estimated — albeit implicitly — when we thought about “small experiments”.

This is a very rare environment (more of a service ecology). It is probably an “extreme” environment compared to other domains, though it was a publicly traded company. Big projects, fixed dates, and lots of dependencies are more common. And many teams cannot connect their work directly to customer outcomes and get feedback so quickly.

One of the problems with the #NoEstimates movement is that it (very unintentionally, as expressed by certain practitioners) lacks empathy. It makes the blanket statement that estimates are bad for ALL uses. Which translates into them being bad for people trying to operate in their current circumstances/context. They’re basically saying … “So what if your marketing team needs to know what will be included in the next release!” Or “So what if you have a poor shared service that has to auction off its capacity!” Estimates become the bad guy instead of singling out the truly dysfunctional things they’re hired to do — e.g. “improve accountability”.

And then there is the class of estimation jobs where the outside context can be changed (e.g. dependencies removed, work delivered in smaller batches, more flow, tighter feedback loops, etc.) This doesn’t remove the need for estimation as a fundamental concept, but it very much changes the estimation emphasis. Here I think it is best to focus on the levers. “What could we do to work in smaller batches, and incorporate customer feedback more quickly?” “How could we do a better job at prioritizing based on cost of delay?” I see this as a continuous improvement effort.

Finally, In some environments I would argue that these levers (e.g. dependencies, overutilization) are a far greater problem than the need to estimate. No amount of estimation will help the company unravel its massive dependency issues or bloated planning process. Because of this, you can safely remove the practice until those problems are resolved. It is one less thing you’ll need to be worried about, and might even help focus the discussion. At some later point you, when the other issues are resolved, you can worry about estimates again, and figure out what you’ll hire them to do.

So the tl;dr of all this is:

• Context, context, context.
• What job are you hiring estimation to do?
• Is it the right tool for the job? Is it working? If it isn’t working, why?
• What levers do you have at your disposal that might impact the “job” of estimation?
• When does the process add value, and when does it act as dead weight? Cheers! Comments appreciated.