Estimation

Estimation is Difficult

We make estimates at work and at home all the time. For example, how much something might cost, how many people will show up at an event, how long it will take us to get from one place to another, how many people we will hire in the next year, and, the point of this article: how long it will take to develop software. If estimation were easy, then we could accurately predict estimated values. The fact that we often get these sorts of things quite wrong is a strong indicator that estimation is difficult.

Even though doing so is difficult and we are often wrong, we still feel pressure to quickly make precise estimates because this precision gives us a (false) sense of confidence—we want to believe we know exactly what we are getting into. But much like George Box’s famous quote on models—“All models are wrong, but some are useful”—the goal should be to produce estimates that are useful, acknowledging that the very nature of an “estimate” indicates that it is probably not exact.

I’ll share my thoughts on making imperfect yet useful estimates for developing software, but first I want to take a short detour and discuss estimating the time to take a trip. I hope to point out some considerations and pitfalls that are common to all types of assessments.

Estimating Travel Time

How long will your commute take you on your next workday? If you are working from home, consider another common trip, like going to the grocery store. Either way, it should be something that you are pretty familiar with and concerning which you can easily make an accurate estimate.

What if you need to go to New York City, how long would that take? Now you have more to consider, such as how close you are and whether you are in the US (or can legally get into the US). You could guesstimate the time or you could do a little research and look into flight times. You probably know less about this kind of trip and can foresee a number of ways in which your estimate could be off. There are many ways to get to New York City, but you should still be able to come up with something reasonable.

What if you are asked how long it would take you to get to a particular restaurant in Vanuatu (the one I took the cover photo from)? This is not a place most people are familiar with, and it took a series of flights for me to get to. In this situation you would either make a wild guess or would be required to spend time gathering information in order to come up with something useful.

So What?

These simple examples lead to some insights that are applicable to estimation in general, but are often overlooked when estimating the time to develop software. The goal of this article is to illustrate some of the challenges and techniques involved in estimation that should be considered when estimating work that must done at various scales.

For instance, when estimating travel time, it becomes clear that a number of factors are at play. In reality you are making assumptions about routes, vehicles, people who may assist you, money, and other factors. If you truly had an unlimited budget, you could hire a private jet and get to that restaurant in Vanuatu quite quickly. The assumptions behind an estimate are usually implied, but it is often important to make them explicit.

Clearly the scale of the challenge affects how you go about making the estimate, how much time and effort you will put into it, and how accurate it will be. This tends to be true regardless of what you are estimating.

A common instinct is to give precise answers for estimates, such as: “It will take me 45 minutes to get to work.” Part of the reason for this is that precise answers give people confidence in the estimate. But precision does not necessarily mean accuracy. This is a common anti-pattern that is particularly relevant when you are making larger estimates. A time range would more accurately reflect the likely outcomes; for instance, “30 to 90 minutes to get to work, and 30 to 96 hours to get to the restaurant in Vanuatu.” Note that it is normal for larger estimates to involve larger ranges, as they tend to present greater risks and unknowns.

Finally, ensure that you have a clear definition of the goal before conducting your estimate. In the last scenario I didn’t specify the restaurant. Where exactly is it in Vanuatu? When is it open? Does it still exist? (I was there in 2018.) It is surprising how often estimates are made without a clear understanding of all the constraints, particularly concerning the expected deliverable.

Two Categories of Estimates

There are many types of estimates related to the development of software engineering, each required for its own reasons and containing its own quirks. But I find that most estimates of the length of time it will take to deliver software fall into two general categories—tactical and strategic.

Note that I was slightly misleading in that last paragraph. You almost never want to try to estimate the precise length of time until software will be delivered, but rather provide a range of time it will likely take to do so, given particular constraints, a certain methodology, and a clear definition of proper delivery, all of which will affect the final estimate.

Tactical Estimates

Tactical estimates are for work that is shorter in duration and fairly well understood, much like the morning commute scenario. Put another way, if your estimate is for a large amount of time with many constraints or unknowns, it probably isn’t a tactical estimate. This sometimes happens, however, as part of an attempt to shoehorn large projects into short amounts of time.

Specific examples of true tactical estimates include small, self-contained features, small bug fixes, UI tweaks, and individual stories.These might take a team or two of engineers hours, days, or a few weeks to produce. Given the reduced scope of such a project, there should be few constraints, unknowns, or interruptions.

If complete clarity on the task at hand is lacking, a small amount of research (Spikes) may be called for.

With good practices it should be possible to produce fairly accurate estimates in these situations that facilitate realistic commitments. While these small projects tend to be less strategically important, regular delivery of committed work is the cornerstone of successfully executing on larger projects.

Strategic Estimates

Strategic estimates relates to a broader category, encompassing anything from multimonth- to multiyear-long projects. These estimates might involve many people or entire companies, as well as quite a few constraints and unknowns.

As in the scenario in which you need to get to a particular restaurant in Vanuatu, strategic estimates are harder to make and more likely to lack precision.

Specific examples include product roadmap items and the development of entire features or product lines.

It is incredibly difficult to make precise predictions about large projects. You should instead aim for useful predictions that give insight into the scale of the work. This is important because strategic estimates are used for staffing, budgeting, sales, contracts, and funding decisions. They are often the first step in reifying a company’s vision.

Large-scale projects are magnets for delay and change because of the time scales involved. They are also more likely to involve new product areas, domains, and technologies, thus further complicating estimates (and the work itself).

The Waterfall Trap

Given the complexity involved and the importance of these types of estimates, it is easy to fall into the Waterfall Trap, according to which you invest huge amounts of time and effort in constructing the estimates in an attempt to perfect them before beginning work. The appeal is obvious: it would be great to know everything about upcoming work before beginning it. But this assumes a prescience that your team doesn’t have: only in limited situations (e.g., with respect to tactical estimates) are you likely to know everything about the work before you begin it. The effort you need to put into the estimate becomes the work itself.

Stick with estimates that are useful, rather than attempting to create perfect ones. There are techniques you can use to quickly get reasonable clarity on the scale of the project and the areas to initially address. In the next post, I will suggest some of these that I have found useful in creating software engineering estimates.