Scrum is obsolete in the AI era

Scrum was built around one assumption: writing code is the slow, expensive part of making software. Plan two weeks of work, estimate it, protect the team while they build it, then look at the result together.

That assumption no longer holds. A coding agent can produce a patch across a whole repository in minutes. Yet many teams still plan as if that patch takes three days, and they still measure progress in story points.

Faster code is not faster delivery

The obvious hope is that agents plus Scrum simply means more done per sprint. The evidence so far is not that simple.

In a randomized controlled trial, METR asked experienced open-source developers to work on mature repositories they knew well. With AI tools, they took 19% longer to finish their tasks.¹ Part of the lost time went to rewriting prompts and to reviewing code that looked right but was subtly wrong.

That study used early-2025 tools, and the tools have improved since. I don’t read it as proof that AI slows everyone down. I read it as a warning: typing was never the whole job. When code gets cheap, the cost moves to everything around it, including deciding what to build, checking that it’s correct, and agreeing on how it fits with the rest of the system.

Scrum has little to say about those costs, because they weren’t the bottleneck when it was designed.

The Scrum most teams actually run

To be fair, the Scrum Guide describes something better than what most of us have lived through. It talks about cross-functional teams that deliver a useful increment every sprint.² It doesn’t even mention story points.

In practice, many companies run what Forrester called “Water-Scrum-Fall” back in 2011.³ Work arrives as a batch of tickets. Frontend, backend and QA pass it from one to the next. Progress is reported as velocity. The ceremonies are agile, and the delivery underneath them is not.

This setup was already slow, but humans hid the problem by working at a human pace. Agents remove that cover.

Three things that break

Review queues grow. Agents open pull requests faster than people can review them. The problem is worst when architecture rules live in people’s heads, because then only those people can check the work. The sprint board says “in review” while the real queue quietly gets longer. The team’s limit is now how much code it can understand, and Scrum has no event or metric for that. Before long, reviewers fatigue and begin rubber-stamping, turning code review into theater.

Agents test their own mistakes. When one agent writes both the code and its tests, its wrong assumptions end up in both. If the model misinterprets a requirement, it writes a green test asserting its own bug. The tests pass, the ticket moves to done, and the definition of done is met. Yet nobody independently checked anything. A green build used to say something about the care a person had taken. From a self-testing agent, it says much less.

Nobody owns the connections. An agent doesn’t care about team boundaries, so one change can touch several modules in a single afternoon. Conway observed in 1968 that systems mirror the communication structure of the people who build them.⁴ Agents break that link: code now connects things whose owners have never spoken. Research on ownership has long tied unclear ownership to more defects,⁵ and a ticket assigned to one person doesn’t tell you who has to agree on a change that crosses three modules.

Why velocity makes it worse

Story points were always a rough proxy for effort. When an agent does the typing, effort stops meaning much. A five-point ticket might take twenty minutes to generate and two days to review. So what is the five measuring?

Worse, it rewards the wrong thing. If the number that goes up is tickets closed or code shipped, agents will happily make it go up. You get more code, more review load and more hidden coupling, and a chart that says the team has never been faster.

Scope guarding protects the wrong thing

Scrum also protects the sprint. The Guide says no changes should be made that endanger the Sprint Goal,² and many teams turn that into scope guarding: once the sprint starts, the scope is locked and someone’s job is to defend it. New ideas go to the backlog. On contract or enterprise projects, they often have to go through a formal Change Request (CR), with an impact analysis, a new estimate and a sign-off.

That made sense when a change meant days of a developer’s time. Guarding scope protected the scarcest thing the team had.

Now picture a stakeholder asking for a small change on day three. An agent could draft it in twenty minutes, but the CR takes a week of meetings and approvals.

The process now costs more than the code it was meant to protect, and the team learns about the idea’s value two weeks later than it could have.

This doesn’t mean every request should go straight to an agent. Cheap code still has to be reviewed, tested and owned, so an unguarded scope would just flood the review queue faster. The control has to move. The useful question is no longer “does this fit the sprint?” but “how risky is this change, and who has to agree on it?” A small, isolated change may need little more than automated checks. A change to a shared API or a database needs its owners involved, whatever the sprint plan says.

What is actually obsolete

I’m not saying the ideas behind Scrum were wrong. Short feedback loops, inspecting real results and teams that own their outcome all matter more now, not less.

What’s obsolete is the operating model built on top of them: the two-week batch, the estimation ritual, scope guarding and the CR paperwork around it, the handoffs between roles and velocity as the measure of health. All of it was designed to manage scarce coding time, and coding time is no longer what’s scarce. Human attention is. So are clear specifications and trustworthy verification.

The shape of what comes next

If the sprint is the wrong container for cheap code, what takes its place? Not chaos, and certainly not a return to big-bang delivery. The replacement looks like three shifts in how teams operate:

From sprint batches to continuous flow. When implementation was slow, batching made sense to coordinate testing and deployment. When an agent drafts a patch in minutes, waiting two weeks for a sprint review is pure latency. High-performing teams are already shifting toward continuous pull: take a scoped problem, draft it, verify it, and ship it.

From writing code to writing specifications. The engineer’s primary craft moves upstream. Clear boundaries, schema contracts, and precise acceptance criteria are what stop agents from producing plausible nonsense. If you cannot specify what you want with rigor, an agent will simply generate technical debt faster than anyone before it.

From manual gatekeeping to automated harnesses. You cannot inspect every line of machine-generated code through sheer willpower without burning out your best developers. Safety has to live in automated test harnesses, architectural rules enforced by linters, and ephemeral preview environments. Human review is reserved for intent, architecture, and tradeoffs—not syntax checking.

Adding agents to a process designed for a different bottleneck won’t make it faster. It will only make its weak points fail sooner. The question for any team adopting agents isn’t how many more points they can fit into a sprint. It’s having the clarity to realize they don’t need the sprint at all.