No Estimates in Practice: What to Tell a Client Instead of a Number

Introduction

Few topics in software management generate more heat and less practical guidance. One side argues that estimates are waste and teams should stop producing them. The other points out that business runs on commitments and asks how exactly you plan to sign a contract.

Both are arguing about a stronger claim than the useful version makes. This article is the practical middle: what to actually do on Monday, what to say to a client who wants a number, and the three situations where the honest answer is that you should estimate after all.

What Does #NoEstimates Actually Mean?

The useful claim is narrow: per-item effort estimation, in points or hours, is an expensive input that rarely improves the forecast enough to justify its cost, because historical throughput forecasts just as well and is free. The claim is about the estimation ritual, not about refusing to answer when something will be done.

It does not claim that dates do not matter, that planning is unnecessary, or that you should tell a customer you cannot say. Those readings are what make the idea sound unserious, and they are not what anyone advocating it in practice is proposing.

What Replaces It

Two things, and both are cheaper than what they replace.

Right-sizing instead of sizing

You do not ask "how many points is this?" You ask one binary question: is this bigger than about a week? If yes, split it before starting. If you cannot tell, it is bigger than a week.

This takes seconds per item rather than a meeting, and it delivers most of what estimation was for. The value of sizing was never the number; it was that the conversation surfaced hidden complexity. Right-sizing surfaces the same complexity, because you cannot answer the question without thinking about the work. See breaking work into tasks.

Throughput forecasting instead of adding up estimates

Count remaining items, look at historical weekly throughput, produce a date with a confidence level attached. See Monte Carlo forecasting and throughput.

The forecast is usually better than the sum of estimates, for a specific reason: individual estimates are optimistic and the errors do not cancel, because the ways work goes wrong are one-directional. Historical throughput already contains every bad week the team actually had.

The Client Conversation

This is the part that decides whether any of it works. A client asks for a delivery date, and the wrong answer is a lecture about probabilistic forecasting.

Client: "How long will the reporting module take?"

Wrong: "We don't really do estimates, we use flow metrics."

That answer sounds like you are declining to be accountable, and no amount of correctness will recover it.

Right: "Looks like about fourteen items. Over the last three months we've been finishing five to six a week, so I'd plan on the 20th. That's the date I'd hold us to. It could land as early as the 9th if nothing surprises us, but I wouldn't build your launch around that."

Notice what happened. You gave a date, you gave the reasoning, and the reasoning was evidence about your actual past performance rather than a guess about the future. That is a stronger position than an estimate, not a weaker one, and clients generally respond to it as such.

When scope grows, the same evidence works in your favour: "we're at twenty items now, not fourteen, so the 20th becomes the 30th." The conversation is about item count, which is observable, rather than about whether the team is working hard enough, which is not. See client communication and managing scope.

Three Times You Should Still Estimate

Any honest treatment has to concede these, and most do not.

1. Fixed-bid contracts

If you are signing for a fixed price, you need a cost number before any work exists, and there is no throughput history for a project that has not started. Estimate it. Use whatever technique you trust, add a real contingency, and understand that the estimate is a commercial instrument rather than a prediction. Forecasting takes over once delivery begins and you have four weeks of data.

2. Go or no-go decisions on large bets

When the question is whether to do something at all, and the answer flips between "two weeks" and "two quarters", you need a rough magnitude before committing. This is not per-item estimation; it is a single sizing judgement on a large decision, and it is worth the half day.

3. When you have no history

A brand new team, a brand new domain, or a first project has no throughput to draw on. Estimate for the first month, start counting completions immediately, and switch as soon as you have eight weeks of data.

The pattern across all three: estimate when you lack history or when the number is commercial rather than predictive. Forecast whenever you have history, which after the first two months is almost always.

Migrating a Team Off Story Points

Four weeks, and the order matters.

• Week 1: Keep estimating exactly as you do now. Additionally, start recording weekly completed item counts. Change nothing else.
• Week 2: Add the right-sizing question to refinement, alongside pointing. Split anything over a week.
• Week 3: Produce both forecasts for the same piece of work, the points-based one and the throughput-based one, and show the team the comparison. This is the step that does the convincing, and it needs no argument from you.
• Week 4: Drop pointing. Keep right-sizing. Keep counting.

The failure mode is dropping estimation in week one, before any throughput history exists. The team then has no way to answer date questions for two months, concludes the whole thing was ideology, and goes back to points with a grudge. Collect the data first. See why small teams should skip Scrum for the wider transition.

What to Do This Week

Start counting completed items per week. That is the whole first step, it changes nothing about how anyone works, and in two months it gives you the option of this entire approach.

Then read Monte Carlo forecasting for what to do with those numbers, and the flow metrics guide for the rest of the picture.