Why Agile Estimates Suck – And What To Do About It

In a fast-paced tech-based startup, engineering is always in the crosshairs. There are never enough resources to get everything done when it needs to be done – everyone is always tapping their feet waiting for the things they need. Trying to get all the company’s most important priorities executed by a technical team that is always too small is like trying to sip a milkshake through a soda straw – no matter how much pressure you bring to bear, only so much is going to make it through. And the whole process sucks.

Most startups recognize the soda straw situation and the need to prioritize, so at least the most important stuff makes it out of the straw first. But that is all the more reason to be able to accurately predict when the next round of work will make it out. Hence the sometimes desperate need for good in-sprint work estimates.

In my experience, however, no matter how good your team is, trying to get accurate estimates is extremely difficult. Here are three reasons why:

1. Getting on the same page is hard

Unless a story has been rigorously defined before estimation, there’s always a difference between what’s in the minds of the originator and the person/people building it. The more individuals are involved, the higher the complexity factor (see The Mythical Man Month for Fred Brooks’ hallowed concept of ‘communications overhead’). Resolving those communication differences takes time – either in design effort, discussion or re-work, and the last two are wildcards in terms of time. Who can predict how long it will take to reach an adequate understanding? Reducing this ‘meeting of the minds’ friction can be done in several ways:

What To Do About it

  • Work together for a while. People develop communication shorthands and shared experiences. After a while, you can say, “let’s do it the way we did last fall, only with a twist,” and people will get it.
  • Do rigorous story definition up front. The more description, wireframing and mockups you can do, the easier it is to get on the same page.
  • Collaborate on story definition. Have the product owner and the developer sit down and work together on story definition.
  • Split ‘design’ time out from execution time. Review the requirements and definitions and think through different approaches to select the optimal one. Then estimate completion.

2. We don’t know what we don’t know

It’s hard to estimate things that you’ve never done before. Most stories are, by definition, something that has never been done, at least in the context of the current project. It’s logical that unprecedented tasks will bump up against unprecedented problems: dependencies and complexities are inevitable, and only tend to become clear upon closer examination.

The obvious answer is to pad estimates to take the unprecedented into account, but it’s a false solution if the goal is accuracy and predictability. For some stories you’ll pad too much, and for others not enough. It’s literally impossible to pad accurately.

What To Do About it

  • Break out ‘discovery’ time within your overall estimate. Try to have the discipline to allot a chunk of time for research separate from execution, and keep an eye on how much of that time has been used. ‘Discovery’ time should relate to how familiar the task is to the developer – the more unfamiliar, the longer the discovery.
  • Be transparent. During standups, be honest and transparent about difficulties you’re encountering during discovery and seek solutions from others.  Once you run out of discovery time, recognize that your estimate is in jeopardy and react accordingly.
  • Be willing to change direction. If discovery time is running out, consider re-evaluating the story definition or approach to see if there’s another way to get a good result within the time allotted.

3. Changing focus adds overhead

Agile was designed for single-purpose teams focused on a given product. In startups, teams are almost always working on more than one context area at a time (front end functionality, infrastructure enhancements, bugfixing, small tasks, etc.) and context-shifting between these areas adds friction to the process. It’s one thing to pull a story off the backlog in the afternoon and execute it within the same code you worked on in the morning – it’s another thing to switch between code, databases, hardware, and issues every few hours. Addressing this gets into management and organizational issues:

What To Do About It

  • During sprints, try to minimize each person’s context-shifts. Assign stories of a given nature to the same developer, or at least group them so they can work on a string of them in a row.
  • Split up your teams. If you have enough people, try to break up contributors into work-focused groups, at least on a sprint-by-sprint basis.
  • Defend your team from distractions. The unexpected drop-by from a product owner, the low-priority bug that someone HAS to get fixed, the obligatory but badly-timed meeting – all these require putting work aside and resuming it later. If possible, group non-critical work into certain days or certain times of day.

Keep Agile in Context

While elegant and extremely useful in principle, Agile can and should to be adapted to individual contexts. Different teams, different people, and different businesses require different approaches.

It sometimes makes sense to work backwards: carve out a chunk of time for a task first, and then design the work to fit that chunk. If you know that X, Y, and Z need to be done by next Monday, define the execution of those stories with that in mind. Most stories can have multiple solutions, and you should try to select the solution that delivers most value given the time allowed. In startup development, nothing is ever done and development is iterative, so you know you’ll come back to it later anyway. Sometimes it’s better to ship a preliminary solution and improve it down the road than delay the whole thing until everything is optimal.

Finally: Be Okay With Inaccuracy

Especially in startups, it’s important to recognize that there are never enough people or time. Accurate estimates only matter if they affect business outcomes, so keep those business outcomes in mind. The debilitating effect of chronic inaccuracy creates its own motivational drag – so focus on collective accuracy for the business, not just around small chunks of work.

Michael Sattler

With a career spent in founding and technical leadership roles with new and enterprise-level organizations, Michael Sattler is a veteran in technology strategy, operations, and product management. He’s spent decades in B2B and B2C SaaS product development, software and application design, engineering operations, new venture creation, and innovation practices.

He has scaled and managed technical teams from 2-50+ across three continents, led large-scale cross-functional program management, and founded or co-founded six companies.