No Estimates

Sizing meetings are expensive. Eight people sit for ninety minutes agreeing on a number per item, and the exercise repeats every cycle. Expensive would be fine if the results held, and the frequency with which they don't is where this approach starts.

Theo went back over six cycles at Pagedeck. Items all sized at 8 points had taken anywhere from 2 to 11 days. More than a fivefold spread lived inside one number, so plans built on it slipping was the expected outcome. Over the same quarter, sizing meetings had consumed twelve hours. Nobody had gone back to check whether the numbers matched what happened until then.

No estimates proposes spending those twelve hours elsewhere. Instead of guessing how long the work ahead will take, count how many items actually finished over the last several weeks and compute the remainder from that. The goal isn't removing estimation for its own sake; it comes from the observation that records predict better than estimates do. The twelve hours were the visible cost; the plans built on unreliable numbers were the larger one.

Drop the sizing step and slice work into comparable sizes, then count what finishes. Six steps.

1. Slice items down to something that finishes in a few days. If it looks like more than three, split it in two. Slicing is the only up-front work this approach keeps, moving the effort from matching sizes to creating them. Slicing also surfaces unclear requirements earlier than a sizing argument does.
2. Count items completed per period. That number is throughput. Lay out the last eight weeks and you see a range like 5, 8, 6, 7. Use the range rather than collapsing it into one average.
3. Look at the distribution of how long single items took. Start to finish is cycle time; record the median alongside the value that 85 percent of items land under. A median of 3 days with an 85th percentile of 9 means usually three days, occasionally nine. Commitments get made against the 85th percentile rather than the median.
4. Divide remaining items by throughput per week. Twenty-four items left at six a week is four weeks.
5. Answer with a range, not a single number. At four to eight a week, 24 items is three to six weeks. That range sits closer to reality than one estimate does, and its width itself says whether the flow is steady.
6. Cap how much runs at once. A WIP limit reduces picking up the next item before the current one finishes, which tightens the cycle time distribution and narrows the forecast range with it. Half-finished work sitting in parallel is what makes a forecast unusable.

One premise holds this together: item sizes have to stay reasonably even. With half-day items and three-week items on the same list, counting items stops meaning anything. Skip step 1 and the other five spin uselessly.

It suits teams that can slice work into comparable pieces and keep it flowing. It fits especially well with kanban, which makes the flow of work visible and limits what's in progress, because it measures flow rather than planning inside fixed cycles.

It also suits work that arrives as requests. Handling support questions or fixing bugs produces items of naturally similar size, where the slicing step is barely needed. The record builds itself from the queue.

Three places it doesn't fit.

1. Work with a date and a scope written into a contract. Once the other party holds a commitment, there's no room to answer in ranges.
2. Work of a kind never done before. With no past record there's no number to divide by. Spending a few days to create a record and answering afterward works better, and the few days are cheaper than a wrong date.
3. Early products with wide size variation. When what gets built shifts week to week, the slicing baseline shifts along with it.

There's an organizational condition too. Answering "three to six weeks" to "when will it be done" has to be acceptable. Where a single date is demanded, a range reads as evasion, so the range has to arrive with a showing of how it was derived. The width narrowing happens on its own as records accumulate. Showing the range with its history is what turns it from a dodge into a forecast.

"Let's slice instead of sizing. Anything that looks like more than three days gets split."

Converting the work of matching sizes into the work of creating them.

"Throughput has been five to eight a week for eight weeks. For 24 items I'll answer three to five weeks."

Using the record directly as the forecast.

"This is a kind of work we've never done. Let's spend two days and talk again."

The approach can't answer without a record.

Theo and Mia trialed it for a quarter. The sizing meeting went away and a 20-minute slicing meeting replaced it. Weekly throughput ran between five and eight items, and the quarterly target was presented as a range.

Two things showed up at quarter's end. Actual completion landed inside the range they had committed to, and the twelve hours of meetings were gone. What it cost instead was two meetings convincing Grace to accept a range in reporting. Mia brought the eight-week record table alongside the range, and once the source of the numbers was visible the range passed without argument after that. What changed was not the forecast but what got shown alongside it.

The most common reading is that it means planning nothing, since the name says estimates aren't happening and planning sounds like the next casualty. But the approach doesn't abandon forecasting; it changes the material. Past records replace human guesses, and the answer still arrives as numbers. A range is a form of planning, not its absence. If anything it demands better record keeping, because the range has to come with its derivation. A team that tracks nothing cannot run this approach at all.

Reading estimation as always wasteful is the other one, usually by generalizing from one team's result. Some situations genuinely need a date first: a regulatory deadline, a signed contract. Those need a date rather than a range, and producing that answer requires estimating. This approach isn't a rule banning estimation; it's a judgment about where estimation fails to earn its cost. Which of the two a piece of work needs is itself a decision worth making explicitly.