Planning: from estimation ritual to derived plan
Estimation was never really about accuracy. It was a scheduling device for scarce human attention. When the attention stops being the constraint, the ritual stops paying for itself.
Picture a planning session that most people reading this have sat through some version of. Eleven people in a room, or eleven rectangles on a call. A ticket goes up on the screen. Someone reads it aloud. There is a short discussion about whether the API already returns the field. Someone says three. Someone says eight. The person who said eight explains that there is a migration involved. Everyone converges on five. The next ticket goes up.
Two hours later the team has produced a number. Call it thirty-four points. That number will be compared against a rolling average of the last four sprints, which is around thirty, and someone will observe that the team is being slightly ambitious this time. The number will then be used to decide what gets promised to a stakeholder in a different building.
Now change one variable. An agent picks up the first ticket eleven minutes after the session ends, and opens a pull request forty minutes after that. Not a great pull request. Not a finished one. But a real one, with a diff, with tests that run, with a shape you can argue about. The five-point estimate has been rendered irrelevant not because the estimate was wrong but because the thing it was estimating no longer takes the kind of time that points measure.
This is the first real collision between the SDLC and the ADLC, and it is worth being precise about what actually broke, because the naive read (“agents are fast so estimation is dead”) is wrong in an interesting way.
What estimation was actually for
Estimation was never primarily a forecasting technology. If it were, we would have abandoned it decades ago on the evidence, because the evidence has always been terrible. Teams that measured their own estimation accuracy honestly found it was somewhere between poor and random, and the industry response was not to stop estimating but to change the units, which is what you do when you are attached to a ritual rather than a result.
Estimation was doing three other jobs, and all three were real.
It was a forcing function for shared understanding. The argument about whether it was three or eight was where the team discovered that half of them thought the ticket meant one thing and half thought it meant another. The number was a byproduct. The disagreement was the product.
It was a scheduling device for scarce human attention. You had six developers and two weeks. That was a fixed budget of human hours, and estimation was how you decided which work to spend it on. Points were a proxy for a genuinely constrained resource.
It was a commitment ceremony. It let a team say a thing out loud to the business, and it let the business plan around that thing. The accuracy mattered less than the existence of a shared number to be accountable against.
Agents do not touch job one at all. They partially demolish job two. And they make job three actively dangerous.
The constraint moved and nobody moved the ritual
The scheduling job is the one that breaks hardest. Estimation assumes the bottleneck is implementation capacity: how many hours of developer attention you can pour into the sprint. Every artefact of agile planning encodes that assumption. Velocity is implementation throughput. Capacity planning is a headcount calculation. Sprint commitment is a promise about how much building you can do.
When a meaningful share of implementation moves to agents, that bottleneck relocates. It does not vanish, which is the part optimists get wrong. It relocates, and it lands in two places.
The first is specification. Somebody has to say precisely what “done” means for this piece of work, in terms specific enough that a system with no taste and no institutional memory will build the right thing. That is slow, it is cognitively expensive, and it does not parallelise well because it requires holding product intent in your head.
The second is review and integration. Somebody has to decide whether what came back is acceptable, and somebody has to deal with the fact that six changes landing in the same afternoon interact in ways that none of them anticipated individually.
So the honest version of capacity planning in an agentic team is not “how many developer-hours do we have.” It is “how many well-specified units of work can we produce, and how much review bandwidth do we have to absorb the results.” Those are different numbers, they belong to different people, and neither of them is what your velocity chart is measuring.
Here is the failure mode this produces, and it is common enough now to be predictable. A team adopts agents. Throughput of code goes up sharply. Velocity, measured in points, goes up too, because tickets are closing. Leadership sees the chart, concludes the team has capacity, and adds scope. The specification bottleneck was already saturated before the extra scope arrived. Now it is oversubscribed, and under-specified work starts flowing to agents, which produces confidently wrong output at high speed, which lands on a review function that was already the second bottleneck.
The chart went up. The system got worse. Nobody did anything unreasonable at any single step.
An asserted plan
- Humans decide in advance what will happen
- Written into a system of record
- The rest of the cycle is decay management
- Planning creates the plan, everything after maintains the gap
A derived plan
- Read from artefacts that cannot lie about themselves
- Branches, reviews, merges, deploys, test results
- Present tense is computed, not asserted
- The session asks what would make this done
What a derived plan is
The alternative is not “stop planning.” Anyone who tells you agents mean you can stop planning is selling something, and probably not even selling it well. The alternative is to change where the plan comes from.
A traditional plan is asserted. Humans decide in advance what will happen, write it into a system of record, and then spend the rest of the cycle maintaining the gap between that assertion and reality through status meetings, ticket grooming and a great deal of politeness.
A derived plan is read. The current state of the work is computed from artefacts that cannot lie about themselves: branches, commits, pull requests, review state, merges, deploys, test results. Forward projection is computed from that observed state plus explicit dependencies, rather than from a room full of people saying numbers.
The difference sounds academic until you notice what it does to the meeting. In an asserted plan, the planning session is where the plan gets created, and everything after it is decay management. In a derived plan, the planning session is where you argue about priority and definition, because the sequencing and the state tracking are being handled by something that reads reality continuously.
That is a genuinely better use of eleven people for two hours. Not “how big is this,” but “is this the right thing, and what exactly would make it done.”
What replaces the number
Teams get nervous here, because the business needs something. “We derive our plan from source control” is not an answer to “will the integration ship before the conference.” So what actually goes in the slot where the estimate used to be?
Three things, in roughly increasing order of usefulness.
Cycle time distributions instead of point estimates. You do not need to guess how long this ticket will take if you have honest historical data on how long tickets of this shape have actually taken, measured from first commit to merged and deployed. Not an average, a distribution, because the tail is what kills you. “Work like this has finished within four days eighty percent of the time” is both more honest and more useful than “five points.” The catch is that this requires accurate timestamps of real events, which is exactly what a hand-maintained board does not have and source control does.
Specification readiness as the leading indicator. In an agentic team, the strongest predictor of whether something will ship on time is whether anyone has written down what done means in checkable terms. Work with vague criteria will thrash. Work with sharp criteria will move fast and then merge. If you want one number on a dashboard to predict delivery, “percentage of upcoming work with machine-verifiable acceptance criteria” beats velocity, and it is not close.
Explicit review capacity. If review is a bottleneck, plan it like a bottleneck. Some teams now track review as a first-class capacity number the way they used to track developer-days. It feels strange for about a week and then feels obviously correct.
None of these three is a promise. That is a feature. Estimates were fake promises, and everybody in the room knew it, which is why the business learned to add a buffer and the team learned to pad, and the two of you spent a decade negotiating against each other’s distortions.
The uncomfortable middle
There is a period, and most teams are in it right now, where you cannot do either thing cleanly. You have agents producing a real fraction of your changes, so the estimate has gone soft. But you have not built the machinery to derive a plan, so the board is still an assertion, and it is now an assertion drifting at a faster rate than it used to.
The most common coping mechanism is to keep estimating and quietly stop believing the estimates. This is the worst of the options, because it preserves the ritual cost and discards the ritual’s only remaining benefit, which is that people took the number seriously enough to argue about the work.
If you are in that middle, the highest-leverage move is not to fix planning. It is to fix the input to planning. Get the state of work reading itself from source control so that at minimum your plan is arguing from real data. This is the specific thing a control layer like GroundTruth is for: linking every pull request to its ticket and writing back the true state so the board stops being a hand-maintained fiction. Once the current state is honest, the forward projection gets much easier, and the argument about how to forecast becomes tractable instead of theological.
What good looks like in practice
A rough sketch of how planning actually runs in a team that has made this shift. Treat it as a sketch, not a prescription, because the details vary a lot by domain.
There is no estimation session. There is a definition session, which is smaller (three or four people, not eleven) and which produces acceptance criteria specific enough that a machine could evaluate them. That session is where the disagreement about scope surfaces, doing the job that estimation used to do accidentally.
There is a prioritisation session, which is where the business actually participates, and which is about sequence and trade-off rather than size. This is shorter than you think, because most of the arguing that used to happen here was really arguing about capacity, and capacity is now a derived number rather than a negotiated one.
There is no status meeting, because status is derived. More on that in the piece on standups.
And there is a weekly look at the distributions: where is cycle time going, which classes of work are thrashing, where is review backing up, what fraction of upcoming work is properly specified. That is the meeting that used to be sprint retro, and it is more useful than retro was because it has data in it that nobody had to remember.
Where this breaks down
I want to be honest about the several places this argument gets thin.
Derived plans are excellent at present tense and mediocre at future tense. Reading ground truth tells you precisely where you are. It tells you much less about work that has not started, has no branch, and exists only as an idea. For anything more than a few weeks out, you are still forecasting, and forecasting from historical distributions is only as good as the assumption that future work resembles past work. In a fast-moving product, that assumption is doing a lot of unpaid labour.
Some organisations genuinely need the fake promise. If you are contracting, if you are selling against a fixed-price statement of work, if you are in a regulated programme with committed dates to a regulator, then “we derive our plan continuously” is not an acceptable answer to a contractual question. You will produce a date. The right response is not to pretend otherwise but to keep the ceremony where it is legally load-bearing and stop doing it everywhere else. Plenty of teams estimate for the contract and derive for the work, and that is a coherent position rather than a hypocritical one.
The estimation ritual carried social functions that nothing has replaced. It was one of the few recurring occasions where the whole team looked at the same thing together, and where a junior engineer heard a senior one explain why a seemingly small ticket was actually dangerous. Killing it without replacing that knowledge transfer is a real loss, and the teams that have done it badly report exactly this: faster delivery, thinner shared understanding, and a slow accumulation of decisions nobody remembers making.
Cycle time distributions can be gamed as easily as points. The moment cycle time becomes the metric leadership watches, work gets sliced into artificially small units to make the distribution look tight. This is the same pathology as points inflation wearing new clothes. Any metric that is used for evaluation rather than observation will be optimised against, and no amount of deriving it from source control changes that. Ground truth makes the number honest about what happened. It does not make the humans honest about why they shaped the work that way.
And it assumes the specification bottleneck is real for you. If your agents are handling a small slice of well-trodden work and your humans are still doing the hard parts by hand, then implementation capacity is still your constraint, estimation is still measuring the right thing, and you should leave your planning process alone. Rebuilding your life cycle for a bottleneck you have not hit yet is just a more sophisticated way to waste a quarter.
The takeaway
Estimation was a scheduling device for scarce human implementation capacity, plus a forcing function for shared understanding that it never advertised. Agents relocated the scarcity to specification and review, which means the ritual is now measuring the wrong resource while still costing the same two hours.
The replacement is not a better estimate. It is a plan whose present tense is read from source control rather than asserted in a meeting, whose forward view comes from honest cycle time distributions rather than points, and whose planning session spends its time on definition and priority instead of size.
Which puts an enormous amount of weight on that word “definition.” If the plan is derived and the agents build exactly what the criteria describe, then the criteria are now the most important artefact your team produces. The next piece is about that: why prose written for a human colleague fails as an instruction to a machine, and what acceptance criteria have to become instead.