Should You Estimate? The Definitive Answer.
Let's settle this once and for all.
In a nutshell
Estimating (and resulting predictability) offers numerous benefits but also comes with significant drawbacks.
Many of these benefits can also be achieved through other means, without precise estimating.
Moreover, estimates are just half of the story. The second pillar of achieving predictability is reducing variability.
It's also vital to be deliberate about what level of predictability you actually need.
One of the most polarizing topics in software development
Estimates are a contentious subject. Managers and businesses want them, while developers hate them. The debate over whether and how to estimate is almost as old as programming itself.
When people ask me about estimation, they either come already strongly biased towards always or never estimating, or they focus too much on the minor details. The complete picture, however, is far more nuanced and highly context-dependent.
To understand whether, when, and how you should estimate, you need to start with one fundamental question:
A million-dollar question: Why do we estimate?
The short answer: predictability.
A.k.a.: How much will it cost? When will it be ready?
But why do we need to know this? For example, for:
Prioritization. To compare the size/cost versus expected value/impact of a feature, to decide if it's worth pursuing.
Budgeting, resource allocation. To understand how many teams should focus on a project, for how long, and how much will it cost us.
Synchronizing teams on bigger projects. To ensure smooth handovers and avoid blockages when teams depend on each other.
Synchronizing releases of multiple related products. For example, launching a new iPhone alongside new versions of iOS, XCode IDE, and the Swift language.
Planning marketing campaigns, press releases, or public demos. To prepare and announce them enough in advance.
Pricing projects for external customers. To be able to agree on the cost and delivery date upfront, before the project starts.
Meeting hard deadlines. While most deadlines are self-imposed (which is a topic worthy of its own discussion) some are externally mandated, such as legislative or tax-related ones.
High predictability also brings two massive bonuses:
Building Trust. Delivering on your promises is a great way to earn trust from business, stakeholders, customers, and management.
Boosting Team Morale. Consistently delivering on your promises also builds self-confidence and morale.
Whoa. Sounds great. But it's not always so rosy...
The drawbacks of estimating
While predictability brings many benefits, it comes with a cost—often steep. For example:
Estimating takes time. Often a lot. And releasing earlier usually brings more value than releasing on a precise date.
It creates pressure. This can negatively affect quality, create stress, and burn the team out.
There's a fundamental tension between predictability and agility. Predicting something upfront is, by definition, at odds with discovery, experimentation, and iterative approaches.
It kills creativity and innovation. The clarity and control required for accurate predictions don't align with the randomness of creative freedom.
It creates false confidence. Believing in a precise deadline, when in reality, your estimate is grossly off, can put your business at risk.
It can destroy trust and morale. Estimating correctly every time is hard. And failing to meet estimates damages trust and morale pretty fast - much more than making no promises at all.
Given so many drawbacks, is there another way to achieve similar benefits?
Indeed, there often is.
Estimation alternatives
Many of our goals can be achieved without precise estimates. For example:
Prioritization. Often, a rough, gut-feel estimate suffices to determine if something is worth pursuing. Especially considering that estimating value/impact is even less precise.
Budgeting, pricing, resource management. These can be managed with more agile approaches like "time & materials" or a fixed budget, supported by transparency and frequent feedback.
Synchronizing teams. Cross-functional teams, well-defined areas of responsibility, clean architecture, and eliminating waterfall stages allow teams to work more independently, without tight synchronization.
Upfront delivery dates and marketing events. Fuzzier promises ("next quarter") are often sufficient. And when you need to commit to a fixed date, a variable scope approach, implementing the most important "vertical slices" first, and gradual releases behind feature flags can give you enough flexibility.
Trust and morale. Frequent high-quality releases, delivering value early and often, de-risking through mockups and prototypes, high transparency, and good communication and expectations management, can build trust even more effectively than meeting deadlines.
Hard deadlines and synchronizing releases. This one is harder, but even here, a variable scope and fixed budget approach, with a sufficiently large buffer, can mitigate the need for precise estimates.
As you can see, precise estimation can be often avoided. Moreover, predictability isn't just about estimates.
Reducing variability: the second pillar of predictability
The more variable something is, the harder it is to predict (duh!).
Imagine a car compared to a metro train.
A car must wait at traffic lights, can get stuck in a traffic jam, and may be delayed due to bad weather conditions. All of which are difficult to foresee and estimate.
A metro train, on the other hand, doesn't stop at the crossroads or get stuck in traffic. And since it runs in a tunnel, it's not affected by the weather. In effect, you can predict its arrival down to minutes, if not seconds.
If there are no variable elements, you don't have to estimate (guess). Instead, you can simply measure and rely on your measurements to be repeatable.
Plus, repeatable measurements not only eliminate the need for estimation but also open up a whole new world of benefits. For example, the ability to provide Service Level Agreements (SLAs) to your clients.
What's more, reducing variability doesn't create tension with agility - it actually facilitates it.
So, if low variability is so desirable, how can we achieve it?
How to reduce variability
Variability can be reduced by making processes more consistent and by eliminating surprises (or at least anticipating them and minimizing their impact).
A few examples of how this can be achieved:
De-risking and risk management. Through prototyping, contingency plans, pre-mortems, and tackling the most difficult or unclear things first.
Minimizing surprises in the code. Through a clean code base, consistent coding conventions, automation, design systems, and component libraries.
Frequent integration and deployments. To prevent surprises from accumulating and compounding over an extended period.
Solid QA process. Ensuring a low and predictable bug rate and tech support response times.
Timeboxing. Things done in fixed-size chunks are more repeatable and easier to predict and statistically analyze.
Splitting big projects. The smaller the tasks, the less room there is for variability, the easier they are to estimate, and there are bigger batches of them - which makes statistical analysis more reliable and minimizes the impact of outliers.
However, before you start applying these strategies, ask yourself how much predictability you actually need.
How much predictability is enough?
Predictability has many benefits. But more predictability isn't always better.
It doesn't make sense to plan, estimate, and de-risk your daily commute to work as meticulously as a multi-leg flight for a once-in-a-lifetime business opportunity.
To avoid wasting too much effort, you should be conscious of these factors:
Do you need short- or long-term estimates? Are you more interested in what you will deliver this sprint, when your current project will end, or what your roadmap for the next 6 months will look like?
What accuracy and precision are required? Do you need to know the exact day of the project delivery? Or will a week, month, or even a quarter suffice? Is it acceptable to miss this deadline by a day? A week? A month?
How narrow your "cone of uncertainty" has to be? Do you need to know the exact release date before the project even starts, halfway through, or just a few weeks before it ends?
There are no universal answers to these questions. They are heavily context-dependent and should be answered on a case-by-case basis.
So, should you estimate (in a given case)?
There's no universal "always/never" answer. You need to consider:
What's your primary reason for estimating in this particular case? What (and whose) needs are you trying to address? Can they be addressed more efficiently in a different way?
What precision and accuracy do you need? Why? Are you even able to meet them? How hard this particular project is to estimate?
What will happen if you don't estimate? What will happen if you estimate wrong? Which one has worse consequences?
What will you gain if your estimates are on point? What will you lose? Is predictability or agility more important in this particular case? Why?
Bottom line
The definitive answer to "Should you estimate?" is that there's no universal answer.
It's highly contextual and depends on your particular needs and capabilities. Estimation has both benefits and drawbacks, and can be often replaced with alternative approaches. It's also closely linked to variability, with its own slew of techniques to improve it. Plus, it requires a different approach depending on the scope, precision, accuracy, and how far in advance you need it.
You must also consider the bigger picture: Do you need estimates and predictability frequently enough to invest in your capability to do them well (even if you don't necessarily need them for this particular project)? Or will you gain more from investing in being agile and innovative, even if you fail to provide necessary estimates from time to time?