Scrum in the Age of AI Agents: What Breaks, What Stays

I've been a practitioner and a critic of Scrum for fifteen years. I've implemented it on teams of five and teams of fifty. I've watched it cargo-culted into dysfunction — standups where nobody listens, retros where nothing changes, planning sessions that feel like hostage negotiations with a backlog. I've also seen it work beautifully: small teams shipping real software on a predictable cadence, learning and adapting every two weeks.

So when people ask me whether Scrum is dead, I don't have a simple answer. What I have is a more useful question: which of Scrum's assumptions still hold when AI agents are writing code alongside your team?

Because Scrum wasn't stupid. It was engineered for a specific set of constraints. And those constraints are changing faster than most teams are willing to admit.

Thanks for reading! Subscribe for free to receive new posts and support our work.

The assumptions Scrum was built on

Scrum emerged in a world with particular properties. It's worth naming them, because you can't evaluate a framework without understanding what it was designed to handle.

Assumption: Coding is the expensive, slow part.The two-week sprint was sized to the speed of human beings writing software. You could plan two weeks of work because you had a reasonable idea of how much code a team could produce. That assumption shaped everything — the length of the iteration, the size of the backlog items, the pacing of reviews and demos.

AI broke this one. First-draft code is now nearly free. A senior engineer with good AI tooling can produce in a day what used to take a week.

The fundamental unit of measurement that Scrum was calibrated to — human coding speed — is no longer the governing constraint.

Assumption: A team of five to nine people is the right size.Scrum's team size guidelines were based on coordination costs. Below five, you don't have enough coverage. Above nine, communication overhead explodes. This was reasonable when each person was primarily producing code by hand.

Under pressure. When AI handles more of the mechanical coding, you don't need as many people producing. But you may need just as many peopledeciding— making architectural choices, reviewing AI output, defining intent, ensuring coherence. The right team size is no longer a function of how much code you need. It's a function of how many decisions the work requires.

Assumption: Two-week iterations are the right cadence.The sprint length was a Goldilocks calculation: long enough to ship something meaningful, short enough to course-correct before going too far off track. But \"meaningful\" was calibrated to human speed. When a feature that used to fill a sprint now takes two days to build, a two-week iteration feels like putting a race car on a city block.

Assumption: The team works sequentially on a shared codebase.Scrum assumed a certain workflow: pick up a story, work on it, get it reviewed, merge it, move to the next one. Sequential. Orderly. AI enables massive parallelism — multiple features, multiple agents, multiple branches, all advancing simultaneously. Scrum has no native answer for parallel AI-assisted work.

Assumption: The daily standup syncs the team.This one is interesting because it's still valid — maybe more valid than ever. When work moves faster and more things are in flight simultaneously, the need for coordination doesn't go away. It intensifies. But the format may need to change.

What breaks

Let me walk through the specific Scrum mechanics that I've watched fail on AI-assisted teams. Not in theory — in practice, on real products with real teams, in the last twelve months.

Velocity as a metric becomes meaningless.Velocity — story points completed per sprint — was always a rough proxy. But it was ausefulrough proxy when the underlying unit of work was relatively consistent. AI-assisted output isn't consistent. Some tasks that would've been 8-point stories take twenty minutes. Some 3-point stories take two days because they require architectural decisions that AI can't make. The variance explodes, andvelocity becomes noise.Teams that cling to it are either gaming the numbers or making decisions based on fiction.

The question isn't \"how many points did we complete?\" It's \"did the thing we shipped actually move the needle?\" Replace velocity with outcome measurement — did the system improve? — and you're asking the right question. It's a harder question to answer, which is why most teams avoid it. But it's the only one that matters.

Sprint planning ceremonies invert their value.On a team I worked with last fall, we tracked where time went over a four-week period. The team was spending more hours in planning, grooming, and estimation sessions than they were spending on the actual work those sessions planned. Read that again. The process overhead exceeded the execution time. This wasn't a lazy team — they were following Scrum by the book. The book just wasn't written for a world where execution takes hours instead of days.

Planning still matters. But the granularity and ceremony around it needs to radically compress. You don't need a two-hour planning session when the work being planned will take a single afternoon.

The backlog as source of truth breaks down.Backlogs assume a certain granularity of work items. A \"story\" in Scrum is supposed to be a slice of user value deliverable within a sprint. But when AI can consume a larger chunk of work at once, the right unit of work changes. I've seen teams try to decompose work into traditional story sizes and end up with stories so small they're meaningless, or stories so large they're actually epics in disguise.

The better unit of work isn't a ticket. It's an intent. What are we trying to achieve? What does success look like? How will we know if it worked? Define the intent, and let the team — humans and AI together — figure out the decomposition. The backlog becomes a list of intents, not a list of implementation tasks. This is a subtle but profound shift in how you think about planning.

The Scrum Master role, as traditionally defined, doesn't survive this transition.When the team is three or four senior people with AI agents, who needs a dedicated process facilitator? The ceremonies that justified the role are compressing or disappearing. The impediment-removal function is still needed, but it doesn't require a full-time person — it's absorbed by the team or by whoever owns delivery.

This is uncomfortable for organizations that have invested heavily in Scrum Master careers. But the honest assessment is thatthe role, as traditionally defined, doesn't survive the transitionto AI-assisted small teams. The skills survive — facilitation, coaching, systems thinking. The dedicated role does not.

What stays

Not everything breaks. Some of Scrum's principles becomemoreimportant when AI enters the picture, not less.

Retrospectives: more critical than ever.AI tooling is evolving so rapidly that a team's workflow can become obsolete in a month. The practice of regularly pausing to ask \"what's working, what isn't, what should we change?\" is the difference between a team that adapts and one that calcifies. But here's the key: retrospective learnings have to actually change something. I've sat through hundreds of retros where the insights were genuine and the follow-through was zero. Learning only compounds when it's captured and acted on. A retro that doesn't produce at least one concrete change in how you work is theater.

The concept of \"done\" — but redefined.Scrum's \"definition of done\" was always important. It's now essential. AI can produce code thatlooksdone — it compiles, it passes the tests that exist, it generally does what you asked. But \"done\" in a meaningful sense means the feature works correctly for edge cases, it's secure, it's accessible, it's observable, and it can be rolled back if something goes wrong. That's not a checkbox exercise. That's evidence of completion. The teams that are shipping well have moved from \"definition of done\" to \"evidence of done\" — concrete proof that the thing works as intended, not just a checklist someone clicked through.

Timeboxing as a discipline.Even if the timebox size changes — and it should — the discipline of constraining work to a fixed period, shipping something, and getting feedback is timeless. The sprint might become a week instead of two. Or a day instead of a week. But the principle — don't go dark, ship incrementally, get feedback early — survives any technology shift. If anything, it matters more when individual velocity increases, because the temptation to go heads-down and build for weeks without feedback grows proportionally.

Stakeholder demos.Showing working software regularly to the people who care about it is still the best alignment mechanism we have. No status report, no burndown chart, no dashboard replaces the moment when a stakeholder sees the actual product and says \"yes, this is what I meant\" or \"no, this isn't right.\" AI changes the speed at which you arrive at that demo. It doesn't change its importance.

What replaces the rest?

I'm not going to prescribe a single rigid alternative — the new patterns are still emerging, and anyone selling you a finished replacement for Scrum in 2026 is ahead of the evidence. But I've seen enough to sketch the principles that the best teams are converging on.

Start every piece of work by defining what success looks like.Not a user story. Not a ticket description. A clear statement of intent: what we're building, why, what's in scope, what's explicitly not, and how we'll know if it worked. This takes thirty minutes, not three days. And it saves you from the single most expensive mistake in AI-assisted delivery:building the wrong thing very fast.

Document the decisions that matter.Not every decision. The material ones — the ones where you chose between options, where there were real tradeoffs, where the reasoning matters for future context. Write down what you decided, what you considered, and why. This isn't bureaucracy. This is the thing that prevents your team from re-litigating the same argument three weeks later when someone who wasn't in the room asks \"why did we do it this way?\"

Build safety gates proportional to the risk.Not every change requires the same scrutiny. A copy change and a payment-processing overhaul don't warrant the same process. Define your risk tiers. Low-risk changes get a fast path — maybe just automated checks and a quick review. High-risk changes get more: manual review, rollback validation, stakeholder sign-off. The goal is to be fast where you can be and careful where you must be. One-size-fits-all process is the enemy of both speed and safety.

Measure what matters and feed it back into the system.After you ship, check: did it work? Not \"did we deploy it\" — that's trivial now. \"Did the outcome improve? Did users behave differently? Did we learn something?\" Feed that answer back into how you plan the next piece of work. This is the loop that makes a team get better over time instead of just getting busier.

These aren't revolutionary ideas. Most of them sound like common sense. The revolutionary part is that most teams don't actually do them — they substitute ceremony for substance, and Scrum's rituals gave them permission to mistake motion for progress.

The real question

Scrum was never the point. Delivering working software in a coordinated way was the point.

Scrum was one answer to one set of constraints. The constraints changed. The answer needs to change with them.

This doesn't mean throwing out everything and starting from scratch. It means being honest about which parts of your process exist because they serve the work and which parts exist because they've become tradition. The teams that win in this transition are the ones willing to ask that question and act on the answer — even when the answer is uncomfortable.

AI didn't kill Scrum. It revealed which parts of Scrum were solving real problems and which parts were just filling time. The real problems — coordination, coherence, safety, learning — are harder than ever. The ceremonies that grew up around them may not be the right ceremonies anymore.

Next week: if coding isn't the bottleneck anymore, what is? I'm going to go deep on the orchestration problem — what happens when parallel AI-assisted work creates conflicts that no one anticipated, and why the coordination challenge is the one most teams are dangerously underestimating.

If this resonated, subscribe. We're writing about what's actually changing in software delivery — no hype, no hand-waving, just what we're seeing with real teams on real products.