Agent-authored work severed the last link between task size and effort, so sizing rituals lost their reason to exist. Forecast from throughput, and stop asking anyone to guess.
By JP LeBlanc
Estimation is over, and there's no argument left worth having. #NoEstimates was already right before agents wrote a line of code: task size correlates weakly with how long something takes, and averaging five guesses destroys the one useful thing a sizing meeting produces, which is the outlier who knows something the other four don't. Agent-authored work finishes the argument. The variance between two similar-looking tasks is now set almost entirely by how completely each one was specified before anyone started, a property invisible before the work begins and impossible to size in a room beforehand. Forecast from throughput. Stop asking anyone to guess.
The honest case for estimation was never the number. It was the disagreement the exercise dragged into the open: five engineers privately holding five different pictures of the same ticket, one of them quietly assuming a dependency the other four hadn't considered. Estimation is a conversation, and the conversation was worth every minute it cost. The number that came out the other end, the 3 or the 8 or the "medium," was never worth anything on its own. It got treated as data anyway, fed into velocity charts and roadmap slides, because a number is easier to defend in a steering meeting than "we talked about it and felt better afterward."
That was always a little dishonest. It's now actively misleading, because the thing the number claimed to measure, effort, has come loose from the thing that actually predicts delivery time.
A designer on our team rebuilt two pages carrying ninety percent of the platform's traffic in three days, working with an agent, against an estimate that had called for two months. Nobody in the room that produced the two-month number was wrong about the old way of building those pages. They were estimating a different activity than the one that actually happened.
That gap isn't a rounding error you correct by getting better at estimating. It's structural. When writing code was the bottleneck, task size and elapsed time moved together closely enough that a room of experienced people could guess within a reasonable band. Once generation is fast and cheap, what decides whether a task takes an hour or a week is how precisely it was specified: whether the invariants were named, whether the edge cases were written down or left for someone to discover at 2am. The spec is what gets reviewed now, and specification quality isn't a property you can inspect from across a room. You find out by starting.
The tempting compromise is a residual case for sizing: something like "this class of task tends to run predictably even now," a smaller, humbler version of the old ritual rather than its replacement. It doesn't hold up. Put the two-page rebuild next to a similarly scoped page with a vaguer spec and they look identical in a planning meeting. Nothing about either ticket tells you which one takes three days and which one takes three weeks. The estimating instinct itself, not just its accuracy, is the thing that stopped working. A leader who hasn't built with the tools can't even tell when an estimate is off by five times.
None of this means you stop trying to know when things will ship. It means you stop asking anyone to predict it and start measuring it instead.
Take the throughput your team has actually produced over the last several weeks, human and agent work mixed together the way it really ships, and use that distribution to forecast the next batch of similar work. Not a single average, since the average is exactly what destroyed the outlier's information in the first place, but the real spread: how often work like this finished in under a day, how often it took two weeks, and where the long tail sits. A distribution built from actual outcomes carries information no committee guess ever did, because it already absorbed every source of variance nobody thought to mention in the room.
This isn't fortune-telling dressed in new language, and the distinction matters. Planning without fortune-telling means committing to outcomes and holding dates loosely, or the reverse, and being explicit about which one you're actually promising. A throughput forecast tells you the range a similar batch of work has landed in before. It does not tell you this specific ticket lands on a specific Tuesday, and the moment someone asks it to do that, you're back in the planning-poker room, just pretending a new kind of precision.
Expect people to flinch the first few times a forecast comes back as a range instead of a date. A range looks like an admission of uncertainty in a room that wants a commitment. It is one. The old estimate wasn't more certain. It was just wearing a single number instead of the wide one it should have had all along.
The strongest pushback is that throughput forecasting needs history you might not have yet, especially on genuinely new work where nothing in your last quarter resembles what's coming. That's a real limitation, not a rhetorical one. On truly novel work, forecast from the nearest comparable team or project you can find, and say plainly that the range is wider than usual, rather than reaching for a number that feels more confident than the evidence supports.
What doesn't survive is the fallback to the old ritual for that case. A room of people guessing sizes for novel work was never more accurate than an honest, wide range. It just felt more like a plan, and a plan that feels solid without being solid is worse than one that admits what it doesn't know.
Stop estimating. Start measuring what already happened, and let that tell you what's coming.