Sprint Planning Is Now a Routing Decision

Sprint planning was a rationing ritual. Its whole shape, the story points, the velocity, the capacity in hours, the two-week box, existed because human implementation was the scarce resource. You could only build so much per cycle, so the hard question was which few things to commit to ¹.

Coding agents removed that scarcity. You cannot hire five engineers for an afternoon, but you can start five agents in five minutes and stop them without a conversation. Implementation stops being the binding constraint. The goal of a sprint, a shippable increment by the end of the cycle, does not change. The constraint under it has moved ¹.

This article is about what the planning ceremony becomes when agents do the building. The short version: sprint planning stops being a capacity ritual and becomes a routing and review-budget decision. Teams that keep running it as capacity accounting hit one of two walls. They gridlock, an agent finishes a task in minutes and then waits days for the next refinement session. Or they create a growing queue of unreviewed pull requests that reads as velocity and is really invisible technical debt ²³. Both are planning failures, not agent failures.

What planning actually was

Rationing was the correct response to the constraint. When a team of six engineers can produce a bounded amount of working code in two weeks, the ceremony that decides which stories get those hours is doing real work. The planning poker, the velocity chart, the capacity spreadsheet, they all existed to answer one question: how much can we commit to, given the hours we have? ¹

The assumption underneath all of it was that complexity maps to effort in a roughly stable way. That assumption is what our earlier analysis of estimation after AI names as the thing that broke: AI split knowledge work into fast generation and slow validation, so a story point no longer predicts a delivery time ⁴. This article is the ceremony-level version of that same break. When the unit of estimation stops predicting time, the ceremony built around that unit stops doing its job.

What agents did to the constraint

The bottleneck moves to two places. Upstream, an agent ships only as fast as someone can write stories precise enough to hand it, so spec quality becomes a limit. Downstream, agents produce plausible diffs faster than anyone can read them, so review bandwidth becomes the other limit. A sprint plan that ignores both, and commits to a pile of work because the agents are fast, just relocates the bottleneck to review and calls it done ¹.

The planning question changes with it. The old question was how many story points fit in the sprint. The new one is how many well-specified, independently reviewable stories the team can approve and review this cycle ¹. That is a different ceremony. It is not smaller; it is doing a different job.

The two-track backlog: routing is the new planning work

The most concrete change is that planning now has to decide who does the work, not just what gets done. When autonomous coding agents handle a large share of implementation, the standard playbook breaks down, and the planning ceremony is where the team rebuilds it ².

The practical pattern is a two-track backlog. Before planning, segment the work by how well specified it is. Structured tasks with clear acceptance criteria, refactoring, test generation, boilerplate, documentation, data transformation, route to the agent track and get token budget estimates rather than story points, because the constraint is compute and review, not human effort. Ambiguous, architectural, security-sensitive work stays on the human track and keeps story point estimation, because it needs judgment an agent does not have. The most common category is hybrid: the human writes the technical design and the agent executes it ².

The routing decision is the planning work. A story that is really three stories comes back as a diff that is really three diffs, reviewable only as a lump, and the team ends up accepting or rejecting all three at once. Splitting happens before the agent runs, not after ¹. The Definition of Ready for an agent-routed task is heavier than a user story: data schemas, negative constraints, verification commands, context file references, API documentation ². If the story does not carry that context, it is not plannable; it is a decision deferred to a machine that will not ask ¹.

The review bottleneck is the real sprint limit

The single most important number in an agent sprint is not how much the agents can build. It is how much the humans can review. An agent can produce fifty pull requests in a day; a four-person team can review perhaps fifteen thoroughly. Plan sprint capacity so that agent output never outpaces human review ².

The formula is simple: agent capacity equals the minimum of the compute budget and the human review bandwidth times a review ratio ². Teams that ignore it create a growing queue of unreviewed pull requests, which is worse than having no agent at all, because it is invisible technical debt accumulating behind a facade of velocity ².

This is the same coordination tax Atlassian's State of Teams 2026 report measures at the organization level. AI accelerates individual execution, and the surge of output backs up at the human-judgment gates, code review, approvals, security checks, that have not changed. Work in progress piles up at the bottlenecks, queues get longer, and reviewers under cognitive overload start to rubber-stamp, which creates slop and rework ³. Atlassian estimates the resulting fragmentation tax costs the Fortune 500 about 161 billion dollars a year, roughly six hours per person per week lost to unclear goals, duplicated work, and shifting priorities ³.

The planning consequence is that the team should set a work-in-progress limit by review capacity, not by what the agents can run. Approving thirty specs in a cycle when the team can carefully review eight diffs a day is not ambition; it is planning malpractice, because it guarantees a backlog of unreviewed work and a temptation to rubber-stamp it under deadline ¹. A short, fully reviewed increment beats a long pile of maybe-working diffs every cycle ¹.

What to build and why: prioritization becomes the decision

Once implementation is cheap, the question that actually decides value is not can we build this, it is what does it cost us every week we do not ship it ⁵. That is the prioritization question, and it becomes the load-bearing decision in planning.

The economic framing has a name: cost of delay. The idea, from Don Reinertsen's work on product development flow, is that building things in the wrong order carries a real cost, and that cost compounds across every item waiting in the queue. The sequencing formula, weighted shortest job first, divides cost of delay by job size, so the item that returns the most value per unit of time ships first ⁵. Cost of delay itself is the sum of user and business value, time criticality, and risk reduction or opportunity enablement, each scored on a relative scale ⁵.

The 2026 twist is that AI has collapsed the denominator. A feature that used to be a thirteen-point epic now spikes as a three when a prototype settles the core design question in a day. When job size shrinks across the whole backlog, the cost of delay numerator dominates the ranking ⁵. That means the planning conversation stops being about effort, which is no longer the scarce thing, and becomes about value and urgency, which still are. The product owner's job shifts from filling out a rubric to auditing whether the inputs reflect what is actually true about the market ⁵.

The data backs the shift. In Atlassian's State of Teams 2026, the roughly fourteen percent of teams that paired AI with a unified work system, clear shared goals, explicit roles and handoffs, were up to 5.6 times more likely to say AI helps them plan and prioritize effectively ³. Coordination design, not access to another chatbot, is the decisive variable ³. The teams that get value out of AI in planning are the ones that redesigned the decision, not the ones that added a tool to the old ritual.

How to run it: the failure modes and the gate

When an agent sprint goes wrong, it usually goes wrong in one of four recognizable ways, and each traces back to a planning decision, not an agent one ¹.

The first is over-committing because the agents are fast. The team commits to far more stories than it can review, seduced by build speed, and the cycle ends with a mountain of unmerged diffs. The second is stories too big for one agent. An unsplit story sprawls across many files and comes back as a diff no one can review in one sitting, so it gets skimmed or bounced whole. The third is ignored dependencies. Two dependent stories run in parallel with no contract, their diffs conflict, and the rework erases the parallelism. The fourth is no acceptance criteria. A story goes to an agent without checkable criteria, so done is undefined, the agent guesses, and the reviewer has nothing to judge against ¹.

The fix is a spec-approval gate before any code is written. For each committed story, write the spec, the scope, the files in play, the verifiable acceptance criteria, the explicit exclusions, and approve it before an agent touches it. The spec is the review contract; the reviewer judges the diff against it, so writing it is half the review work done up front ¹. This is the planning-side twin of the requirements bottleneck argument: when implementation is cheap, the quality of the specification is what determines whether the sprint delivers ⁶.

The ceremony keeps its skeleton, define, decompose, commit, sequence, but the emphasis shifts to specs and review budget. A cycle plans in six steps: name the shippable increment in one or two sentences, decompose it into independent stories, write and approve the specs, set the work-in-progress limit by review capacity, sequence for dependencies, then run the loop, starting approved stories up to the limit and pulling the next one when a review slot frees ¹. The boundary that keeps it human is the same one the Scrum Guide always drew: the sprint goal, the sprint backlog, and the definition of done stay with the team, and agents advise rather than decide ⁷. Our definition of done for AI agents covers the third of those in depth ⁸.

Adroit on the ground

We run a delivery pipeline where agents draft a large share of the work, and the planning lesson we keep relearning is that the gate is the product. Nothing we produce ships because an agent produced it; it ships because a human approved the spec and then reviewed the result against it. The spec-approval step and the review step are separate, mandatory, and owned by a person, and the capacity of those two gates is what we plan around, not how fast the agents can generate output.

That is the same principle this article argues for, and it is why we treat the planning ceremony as a routing and review-budget decision rather than a capacity ritual. An external client does not need to know our internal system names to act on the lesson: when agents make implementation cheap, the scarce resource is the attention of the people who decide what is worth building and whether it is done, and the sprint plan has to be sized to that resource.

The ceremony is not obsolete; it is doing a different job

Sprint planning is not going away. It is more important than ever, because the decision it makes, what to build, in what order, and who builds it, is the one place a human must stay in the loop. The teams that manage the transition deliberately, with a two-track backlog, a spec-approval gate, and a review-budget WIP limit, see the speed gains without the review queue. The teams that bolt agents onto unchanged Scrum rituals see inflated velocity numbers, growing review queues, and invisible technical debt ².

The goal is stable. The constraint moved. Plan to the constraint that is actually binding, and the ceremony starts working again.