By Brian Kimmel —

The Three Continuums of Better Software Estimation

Three futuristic-looking slider bars stacked on top of each other with the labels, in order: EFFORT, OPTIMISM, and CERTAINTY

As a software engineer, you're frequently asked to estimate how long a task will take to complete. Estimation can be a tedious process and it's tempting to just throw out a (usually rosy) date. This approach can quickly get you and your team buried, working nights and weekends to heroically meet dates that were unrealistic to begin with. Better estimates are critical to your health and longevity as a software engineer and this framing can help you keep your workload sustainable, avoid burnout, and as a side effect, give your audience better estimates.

Define "Better"

It's easy to define "better" here, right? A better estimate is one where the estimated date provided before the work starts matches the real date that the work was delivered. But what if the team works 80 hour weeks to meet their deadlines and needs a week of recovery time after every production release? Or the opposite; what if the team spent 1 month estimating 3 months of work and hit their date exactly? "Better" doesn't always mean "more accurate." A good estimate will give the organization the information it needs to coordinate and make decisions most efficiently.

When a product manager asks how long something will take, they're usually trying to answer a specific question, such as:

  • When can we tell a client this feature will be done?
  • How does this project affect another team that is dependent on this API to release the new version of their product?
  • Where can I put this project on our publicly available roadmap?
  • How close are we to hitting our quarterly targets?

Surprisingly, the best possible estimate for each of the above scenarios can be different, even for the same body of work.

Estimating work is just like any project. You're used to defining requirements, asking questions, being clear about the definition of done, etc. when you're building things. You should follow the same process when tasked with estimating a body of work. There are a few questions that you can ask to help you figure out your targets for each of the 3 continuums:

Who is the audience for this estimate? The estimate may be for internal projections, internal teams, or it may be widely distributed to clients (or all three.)

What are the consequences of over- or under-estimating this work? If you overestimate, will you miss out on a valuable contract? If you underestimate, will you end up working overtime to catch up, only to have the project ultimately cancelled? Do other teams depend on the timing of delivery of this work?

To what level of detail is this work specified? Are we t-shirt sizing for a long-term project or is there enough information to break the work down into tasks and assign hours to each task?

Getting answers to these three questions will give you valuable insight into where on the three continuums of effort, optimism, and certainty this estimate should fall.

Effort

The amount of effort you put into an estimate can increase your accuracy, up to a point. For almost every estimation exercise, however, there is a point of diminishing returns. The two extreme approaches of this continuum are:

  1. Respond with an estimate as soon as possible (off-the-cuff); this approach can lead to inaccurate estimates.
  2. Try to get a full and complete understanding of the work, only then providing an estimate; this approach seems "correct" at first, but can actually imply false certainty, which is also inaccurate.

Finding the point of diminishing returns here is key to providing the right estimate.

If the work has detailed specifications and the estimate is being used directly in a high-profile contract with a client, it makes sense to take more time to analyze all of the requirements.

If you're setting quarterly targets, and you only have high-level requirements, discussing minutiae is not an efficient use of time. To be clear, the minutiae and requirements will be discussed (during sprint planning, for example,) but answering every question may not be required for high-level estimates.

Whether you're estimating the work by yourself or with your team, it's important to focus on details only if the outcome of the discussion would affect the estimate. Try not to mix up requirements communication with estimation, especially when you're estimating at a high level.

Optimism

Between 20% and 66% of software projects fail, depending on your criteria for failure. At first glance, you might say that as an industry, we are critically failing in our ability to estimate software projects. And you'd be right, but why?

One factor that contributes to our failure to estimate well is the natural tendency to give optimistic estimates. Pressure from stakeholders, lack of knowledge of the requirements, personal pride, and the inherent uncertainty in trying to predict the future, all contribute to a culture where software engineers are set up to give rosy estimates.

So that's an easy problem to fix, right? Just pad all estimates by 30% and you should be good. This works and has worked for years in resource-rich environments. However, in an environment where your teams, proposals, and governance are competing for resources with other teams, and those teams are providing optimistic estimates with no padding, you'll be starved for funding.

This is why it's crucial to understand your audience and the consequences of over or under estimating for the particular body of work that you're estimating. There are situations where it's appropriate to sacrifice accuracy for optimism and your estimate should be optimistic, and there are situations where going over time or budget is unacceptable.

There are two big ways that you can control your level of optimism when providing an estimate: feedback loops and padding

Feedback loops

Feedback loops just mean that you have some mechanism for checking your previous estimates against reality, with an eye towards increasing accuracy.

Retrospectives are a great place to have this discussion with the rest of your team. Make sure that there's time to talk through how much was estimated vs. how much was done during your retrospectives so that you can continuously improve your accuracy.

A small note: many teams have a formalized feedback loop for task- or story-level estimations, but don't actively try to improve their longer-term estimates. Having retrospectives per-release, per-quarter and beyond can help you plan further into the future (to the extent to which that's possible!)

Padding

Padding is an age-old method for ensuring that your projects don't run over-time or over-budget. It used to be conventional wisdom that each level of management would add 20-30% to every estimate before communicating it out. This method works, but it has a few key drawbacks.

The first is that it's a very imprecise tool. That could be ok in certain situations where you absolutely, positively must deliver on time. It's impreciseness has the side effect that it's one-size fits all and doesn't scale well. The magnitude of padding on a long-term project with a high degree of uncertainty may be totally different than the padding on a small, well-specified project.

The second drawback is Parkinson's law, "work expands so as to fill the time available for its completion." There is some evidence that this law applies to software engineering and sticking with a defined strategy for estimation, rather than adding a flat padding percent can help mitigate Parkinson's law.

I would recommend that you use padding sparingly, and when you do, use a defined and transparent methodology that ties the magnitude of padding to level of risk.

Certainty

If you haven't already, stop reading this and go read Steve McConnell's Software Estimation: Demystifying the Black Art. At the heart of this book is a diagram called The Cone of Uncertainty. The concept is simple: the earlier in the project you're estimating a body of work, the less accurate the estimate will be.

It's important to note that the uncertainty does not come from the skill or abilities of the people estimating. There is nothing you can do to remove the uncertainty without spending time. Whether you spend that time articulating requirements or iterating, even the most accurate possible estimator can't do better than a .25-4x range at the very beginning of a project.

We have two ways of incorporating uncertainty into our estimates that can be used in concert: We can improve the specifications, and/or accept and communicate the level of uncertainty.

Improve the Specifications

Even at a high level, there should be some definition of done. The key is to have the appropriate definition of done for the specificity of the estimate. For example, if you're estimating building a complex new page, it's not important to have pixel-perfect mockups for a high-level estimation. Make sure that at a minimum, you have answers to any question that would affect the estimate.

Sometimes you can't get answers to every question you have about the requirements. For that situation, you're going to have to make an assumption about the answer. When you make specification assumptions in order to provide an estimate, make sure to clearly document those assumptions.

As for how to decide on which assumption to choose, ask the person writing requirements (Product Manager, SME, Business Liaison, etc.,) to take their best guess. If they won't venture a guess, you can always choose the option that would take the most time. The key is to document that as an assumption.

Accept/Communicate the Level of Uncertainty

There are a few ways to accept and communicate the level of uncertainty in your estimates. You can include a certainty percentage along with a time, or provide a range of dates rather than a hard deadline. I've found that the game of telephone can strip this extra risk information out of your estimates. The person or team to whom you are providing the estimate may intentionally or unintentionally omit the percentage or choose a date within the range when they are passing on the information to another party.

Another way to communicate the level of uncertainty is to codify that in your process. Repeated usage of different types of estimates can acclimate the whole organization to your level of uncertainty for different types of estimates. For this, it helps to give names to different uncertainty levels for different types of work and ensure there is a shared understanding of what they mean.

A popular taxonomy (from most uncertainty to least uncertainty) is Initiative, Epic, Story, Task. Some organizations also use Theme and Feature. For estimation, it's more important that there's a shared understanding of what level of uncertainty each of these maps to than the actual words you use to describe those levels.

The Key to "Better" estimates

The key to better estimates is to understand that, just like all software deliverables, the "why" matters just as much as the "what" does. The task of estimation itself has requirements that you need to understand. When you find out more about what each estimate will be used for, you can tweak the sliders on each of the three continuums of effort, optimism, and certainty to provide a customized result that above all, meets the requirements of the estimate itself.

Bonus Estimation Advice

You may understand the above, and be working toward clarifying a shared understanding within your organization, but not everyone will exactly align on this framework. For that, I have a few helpful tips:

Never provide off-the-cuff estimates If someone tries to pressure you into estimating something over the phone without having any requirements in writing and without giving you time to think, I advise you not to give an estimate if at all possible. Asking for off-the-cuff estimates and pressuring software engineers for a quick answer is a way to codify and enforce unrealistic timelines, leading to burnout. If someone can't wait for you to have an amount of time with the requirements that's appropriate for the level of uncertainty, then they are usually trying to trap you into giving a rosy estimate and reserving the right for future feature creep. Protect your mental and physical health and well-being by having clear boundaries about this.

Only estimate work that you or your team will be doing. Estimates are not transferrable, you can't tell someone how long it will take another person to complete a software development task. If you are a leader or manager, don't estimate tasks that your team will be implementing, bring them into the estimation process. Part of the estimation process is a commitment from the estimator to aim for the date provided (given all assumptions and caveats mentioned above.) This commitment gives the people doing the work accountability and buy-in for the estimate. You can't make that commitment for another person or team.