Sprint planning and estimation in the age of AI

Teams that adopted AI in development usually keep the planning ceremony exactly as it was, then find their estimates got worse. It is not an illusion: AI moves precisely the variable that estimation by analogy assumes is stable.

Why estimates get worse before they get better

Story points work because the team compares a new task against similar tasks already delivered. That assumes the cost of a given type of task is reasonably predictable.

AI widens the spread of that cost. The same effort bucket now covers cases where the assistant does nearly everything and cases where it gets in the way, and what decides is not apparent complexity: it is how new the code is, how much implicit context exists, and how verifiable the result is.

The result: the average may improve, but the range gets so wide the number stops being useful for a commitment.

Estimate task type, not just size

A cheap and effective adjustment is adding one dimension to the planning conversation: besides "how big", ask "how much of this is familiar territory?".

Three bands are enough:

• Green. New code, common pattern, result verifiable by tests. This is where AI helps most and estimates can safely shrink.
• Yellow. Existing code with good test coverage. Moderate gains, estimates close to historical.
• Red. Core, older code with implicit business rules and thin coverage. Here AI can cost time, and the estimate should not shrink.

The classification takes a minute per item and explains most of the variation that currently shows up as "we got the estimate wrong".

Scrum does not ask for points

It is worth remembering what the Scrum Guide actually requires of planning: establishing why the sprint is valuable, what can be delivered, and how the work will get done. It prescribes no story points, no velocity, no planning poker.

That opens a choice many teams postpone: when item predictability drops, counting small items usually forecasts better than summing points on large ones. Slicing more finely and measuring throughput is more robust to the variance AI introduced.

Let cadence speak louder than estimates

The Agile Manifesto already put working software above documentation and responding to change above following a plan. Flow metrics are more aligned with that than estimate precision is.

DORA's four metrics remain the best small set for this: lead time for changes, deployment frequency, change failure rate and time to restore service. They capture whether the team is delivering safely, which is the real question behind "did the sprint fit?".

One detail matters when adopting AI: read all four together. Shipping faster while failure rate climbs is not a gain, it is debt being transferred to whoever is on call.

Where AI helps in the ceremony itself

Without turning planning into automation theatre, three uses pay for themselves:

• Slicing. Hand the large item to the model and ask for three different vertical decompositions, each delivering end-to-end value. Use it as a starting point, not a decision.
• Risk surfacing. Ask for the implicit assumptions and edge cases in the item. Good for escaping "it looked simple".
• Code context. Ask which files and integrations the item likely touches, so you can classify green, yellow or red with more information.

What does not work is asking the model to estimate. It does not know your technical debt, your review queue, or who is on holiday.

Watch cognitive load

The work on developer experience proposes three dimensions: feedback loops, cognitive load and flow state. AI moves all three, and not always favourably.

Reviewing code you did not write carries high cognitive load. A team generating far more code than it used to review feels that first as fatigue and later as a quality drop. Planning has to reserve review capacity, not just writing capacity.

What this means for your team

Add the green, yellow and red classification to refinement for three sprints and compare estimation error by band. You will probably find the problem was concentrated in red.

Reserve explicit review capacity in the sprint, proportional to the volume AI started generating. And track DORA's four metrics side by side, so you do not celebrate speed that is being paid for in stability.