Software estimates fail. Here’s what actually works

In this article, I explain why the software estimates developers give you are doomed to fail, and what you can do about it.

Why estimates fail

Estimates are a common source of misunderstanding between business and the development team.

The most basic facts about estimates are that:

• Business needs them
• They are inaccurate
• Time is money

The reason for requesting an estimate is completely logical – as a business, you want to know when your piece of software will be ready and how much it will cost.

When it takes longer than estimated, there’s a reason to be frustrated since you feel that something is taking longer than it should and you’re overpaying – then you request explanations.

The reality is that it’s like being angry at a fortune teller whose prediction didn’t come true. That’s why every developer will tell you one thing about estimates – they don’t work. See this article: #NoEstimates, An Introduction.

Sure, we can give you a number, but:

• Initial estimates often reflect wishful thinking rather than reality
• These numbers are typically generated based on incomplete information – they simply can’t be accurate
• The real question is – why assign a specific number to a feature when we already understand what you want to achieve?

In 9 out of 10 cases, requirements change after the first sprint.

Here’s what typically happens in projects – let’s take a real-life scenario:

Sprint 1: We create a backlog and plan basic features – user registration, login, and the main dashboard.

Sprint 2: Suddenly, new requirements emerge:

• Not every user will register themselves – we also need dependent accounts for their family members…
• …our user base will, for sure, prefer to log in with a popular social media platform like Facebook…
• …but they also need to share invitations to our app through all possible platforms…
• …and so on.

And from there, the project takes on a life of its own. So what was the point of the initial estimate?

This pattern repeats across projects. Just recently, in a situation similar to the scenario described above, we unexpectedly added a referral program with point calculations to an app after our client requested it. Here’s another example – a client insisted on week-by-week estimates, but requirements changed within the first week, and now the team is building something completely different from what was initially planned.

The nine women problem: Why more resources ≠ faster delivery

Here’s another challenge with estimates: once we provide them, clients sometimes try to ‘hack’ them immediately. Their logic is simple: if they double the team size, they’ll deliver twice as fast. But as the old software development saying goes: nine women can’t deliver a baby in one month.

There’s an optimum team size in software development, which is roughly 3-7 people working on a specific product/part of the product. Adding more people beyond that number creates additional friction that impacts the speed of delivery.

The hard truth about development estimates

The honest truth about software projects is that they will take as much time and effort as they need. A developer would be able to provide the perfect estimate only for a task they’ve just completed, which makes no sense for the business.

Usually, when given the task to predict the future, a developer will do their research, ask questions, and reduce uncertainty to the maximum extent to make the most informed guess. But this is only a judgment based on their past experiences and wishful thinking.

There are several biases that come into play during this process:

• Projects exceed estimates by about 30% on average
• Professionals often overestimate their accuracy: When they are 90% confident, they are correct only 60-70% of the time

When do you “need” estimates?

Estimates are typically ‘required’ at three project stages:

1. When a client is considering collaboration
2. When we’re estimating sprint tasks during active development
3. During ongoing collaboration, when a client needs estimates for a new, major part of the app (similar to point 1)

From our perspective at Pragmatic Coders, we don’t actually need these estimates. The key point is this: when someone asks for an estimate, they should first question why they need it. Often, they don’t.

Let’s break this down:

Software estimates for initial collaboration

• Year-ahead estimates won’t be useful anyway (too many things can change along the way)
• A better alternative: We ask about the client’s budget and critical paths to start generating revenue/reach production. We then track timelines and budgets along the way after each iteration
• This means starting with MVP and setting sail – the initial estimate becomes irrelevant

Software estimates for sprint planning

• We work in iterations
• By comparing previously delivered features, we can predict sprint capacity
• The real solution? Skip the estimate altogether and focus on what matters: delivering value within constraints

7 ways to make estimates work for you

1. Consider skipping estimates altogether (#noestimates) – chances are they are a waste of time and a source of frustration for everyone involved.
2. Adopt the right mindset – don’t treat them as something you can base your entire financial plan for the coming year on. The estimates are there to set expectations; they’re not a commitment.
3. Ask yourself: why do you need the estimate? Is your management asking for it? If so, there may not be much you can do.
4. However, if that’s not the case, an alternative approach would be to let the team know your goals and what matters most to you (What’s more important—time of delivery or fitting into the budget? Are you prepared to prioritize your requirements and reduce the scope if necessary?), and allow your software partners to adjust the solution to your needs.
5. Use the right kind of estimation at the right project stage – when just getting started, forget about getting the correct estimation for the year ahead.
6. Use the right granularity – sometimes estimation takes more effort than needed to deliver the specific thing we’re estimating.
7. If you really care about your estimate: clarify unknowns. There are things that we know, things that we think we know, things that we know we don’t know (known unknowns), and things that we don’t know we don’t know (unknown unknowns).

Beyond estimates: Alternative approaches to project planning

Not fixating on detailed upfront estimates can actually save time and improve focus on the value we aim to deliver.

What we do is ask about the client’s budget and critical paths to revenue/production, then optimize our approach accordingly.

By tracking deliverables against timelines and budgets as we go, we save ourselves unpleasant surprises. When you work with an experienced team, we can adapt the solution to meet your time and budget constraints.

Need to launch in a month? Let’s have a conversation about how to make that happen.