當一半工作由 AI 智能體完成，團隊如何安排 Sprint？

Your team adopted AI coding agents, and the early results looked incredible. Features that took days now take hours. Then the second sprint hit, and something felt off. Velocity charts went haywire. Reviews piled up. Standups got weird, "I'm done, I'm just waiting on review" from three people at once. Your estimation stopped meaning anything. The work was getting faster, but the process was groaning.

Here's what's happening. Scrum, story points, your whole agile apparatus, was designed around one quiet assumption: writing code is the slow, expensive, bottleneck part of building software. Nearly every ceremony you run optimizes for that. When agents write half the code, that assumption is no longer true, and the bottleneck moves from writing to verifying. Your process is still standing guard at the old chokepoint while the traffic jam forms somewhere else.

You don't need to abandon agile. You need to move it to where the work actually is now. Here's what changes, concretely.

Estimation: You're Now Sizing Verification, Not Implementation

Story points were always a proxy for implementation effort. How hard is this to build? That's the question every estimate answered, even when teams pretended it was about "complexity."

When an agent does the building, that question gets a lot less interesting. A feature an agent can scaffold in fifteen minutes might still take a senior engineer a full day to review, reason about, test against edge cases, and trust enough to ship. The effort didn't vanish. It relocated, from the keyboard to the judgment.

So estimate the part that's now expensive. When you size a story, ask: how hard is this to verify? A task touching authentication, money, or data integrity carries enormous verification cost no matter how fast an agent generates it. A cosmetic change is cheap to build and cheap to check. Those two are no longer the same size just because they're similar amounts of code.

A practical move many teams make: stop pointing implementation and start pointing review and verification risk. Some teams add a separate, explicit "verification effort" signal to each story so it's visible in planning. However you do it, the principle holds, the expensive thing is now trust, so estimate trust.

Review Becomes the Job, Not a Chore at the End

This is the biggest cultural shift, and the one teams underestimate most.

In the old world, your engineers spent most of their day writing code they understood deeply because they were authoring it. Review was a smaller slice, a colleague glancing over a few hundred lines of a teammate's work at the end.

Now your team spends much of its day reading and judging code it didn't write, generated by an agent, often more of it than a human would have produced by hand. That's a fundamentally different activity, and a more tiring one. Reading unfamiliar code is exhausting precisely because you have to reverse-engineer someone else's thought process, and it gets harder when AI wrote it: CodeRabbit's analysis found readability issues are roughly 3x more common in AI-generated pull requests than in human-written ones. Spotting the subtle bug, checking the edge cases the agent confidently ignored, is harder than writing, not easier. And it's now the main event.

Plan for it. Treat review as primary work with real capacity allocated, not as overhead squeezed into the cracks. If your sprint plan assumes engineers spend their time building, you've mis-budgeted, because they're spending it verifying. The teams that struggle with agents aren't the ones whose agents write bad code. They're the ones who never reallocated time from writing to reviewing, so review silently becomes the bottleneck nobody planned for.

Smaller Batches, Because Big Agent Output Is Unreviewable

Agents can generate a lot of code fast, and the instinct is to let them, one prompt, one giant pull request, one big leap forward. Resist it.

A 2,000-line agent-generated PR is effectively unreviewable. Your engineer either rubber-stamps it (and you've shipped code nobody understood) or spends two days untangling it (and you've lost the speed you adopted agents for). Both outcomes are bad.

The fix is the same discipline agile always preached, just newly urgent: small, verifiable increments. This isn't new wisdom — DORA's research identifies "working in small batches" as a core capability, and DORA now calls the discipline "especially important when using AI coding assistants," warning that "while AI excels at generating large blocks of code quickly, large changes are difficult to review, test, and integrate safely." Break work so each agent-produced change is small enough that a human can actually read it, reason about it, and trust it in a sitting. Smaller batches mean faster, more reliable review, less risk per merge, and problems caught early instead of buried in a wall of generated code. The economics flipped: when writing was expensive, big batches amortized the cost. When verifying is expensive, small batches are how you keep verification tractable.

Design the Human-in-the-Loop Deliberately

In an agent-augmented sprint, the most important planning question for each piece of work is no longer "who builds this?" It's "where does a human need to be in the loop?"

For some tasks, the answer is "lightly", an agent builds, a human reviews the diff, done. For others, especially anything touching security, compliance, money, data migrations, or core architecture, you want a human deciding the approach before the agent builds, and scrutinizing carefully after. And for a few high-stakes changes, you may want a human writing the critical path themselves and letting the agent handle the surrounding scaffolding.

Make these checkpoints explicit in how you plan and define "done." A task isn't "agent writes it." A task is "agent writes it, human verifies these specific things, human approves this specific gate." Designing where the human judgment lives, intentionally, per task, is now a core part of sprint planning, not an afterthought. Get it right and you get speed and safety. Leave it implicit and you'll oscillate between rubber-stamping and bottlenecking.

Redefine Velocity Around Verified Outcomes

Velocity has always been a slippery metric, but agents break it outright. If you measure throughput by code volume, an agent can make any sprint look heroic while shipping a pile of unreviewed, possibly broken work. Lines of code was always a bad measure; now it's an actively dangerous one.

Move your definition of progress to the only thing that still means something: verified, deployed, working outcomes. Not code generated. Code reviewed, tested, merged, and running in production doing what it was supposed to do. Count features that are genuinely done, trusted, shipped, delivering value, and ignore the raw output that an agent can inflate at will.

This also keeps incentives honest. If your team is measured on verified outcomes, nobody is rewarded for letting an agent flood the repo with code no human stands behind. The number that matters is the number that survives review and reaches users.

Putting It Together in the Sprint

None of this requires a new framework. It requires pointing your existing one at the new bottleneck.

In planning, estimate verification effort, not implementation effort, and explicitly budget capacity for review as primary work.
In refinement, decide the human-in-the-loop checkpoints per story and bake them into the definition of done.
In execution, keep agent output in small, reviewable batches, no unreviewable mega-PRs.
In standup, treat "waiting on review" as the real bottleneck signal it now is, and swarm it, rather than letting verified-but-unreviewed work pile up invisibly.
In the retro and metrics, track verified, deployed outcomes, and ignore raw code volume entirely.

The pattern underneath all of it: every ceremony you run was tuned for a world where writing was the constraint. Re-tune each one for a world where verification is. That's the whole adjustment.

At Particle41, our delivery model pairs senior engineers with AI agents on every engagement, so we've had to redesign our own sprint mechanics around exactly this shift, moving the weight of the process from authorship to verification, from big batches to small ones, from output to outcomes. The teams that get the most out of agents aren't the ones with the cleverest prompts. They're the ones who noticed the bottleneck moved, and moved their process with it.

Sources

DORA, "Working in small batches" (capability) — small batches as a core software-delivery capability, and DORA's specific guidance that this discipline is "especially important when using AI coding assistants" because large AI-generated changes are hard to review, test, and integrate safely.
Aleks Volochnev, "It's harder to review code than to write it — especially with AI code," CodeRabbit (2025) — reading unfamiliar code requires reverse-engineering another's reasoning, and readability issues are roughly 3x more common in AI-generated pull requests than human-written ones.

Originally published at particle41.com