Why Scrum Stops Working in the AI Era

Part 1 of the Post-Scrum series

Scrum has been the default way to run software teams for twenty years. It worked because it was tuned to a specific reality: implementation was expensive, so every ceremony was there to protect against costly mistakes. AI broke that assumption. This post is about what happens to Scrum when the thing it was designed to protect is no longer the expensive part of the job.

How AI Changed the Cost of Implementation

A week used to be the upper bound for a single development task. Anything bigger got split. That week-long task now takes a day or two. Rework that used to cost days costs an afternoon. AI didn't just speed things up. It changed the cost structure that every process framework is built on.

The Agile philosophy isn't the problem here. Short iterations, continuous feedback, responding to change: those principles are more relevant than ever. What stops working is Scrum's specific machinery built around them.

Scrum was designed for expensive implementation. Every ceremony is insurance: refinement protects understanding, estimation protects forecasting, sprint planning protects priorities, daily standup protects coordination. When a wrong direction costs weeks of work, that insurance makes sense. You protect expensive things.

When the biggest task a developer should take shrinks from a week to a day or two, the premiums stop making sense.

Decisions as the New Bottleneck

If implementation is cheap, what is expensive? Decisions. What to build, how to build it, for whom. Code is becoming a disposable artifact, while specification is the asset.

Greg Young said it in 2014: "Optimize for deleteability." Write code you can throw away in a week. Back then, most teams could not afford to think that way because rewriting a module meant weeks of work. It was good advice that few could follow.

Now, with AI, a developer can rewrite a module in a day. The vision came true, not because developers changed how they think, but because the cost of implementation dropped enough that code truly became disposable.

The Ceremony-by-Ceremony Breakdown

A ceremony pays for itself when the cost of the mistake it prevents is clearly higher than the cost of running it. When a task took a week, a one-hour meeting of five people preventing a week of rework had obvious ROI. When a task takes a day and rework costs half a day, that same meeting costs more than the problem it solves.

This is what happens to each ceremony under the new economics.

Estimation

Estimation protected against bad forecasting. Story points, planning poker, velocity charts. All designed to answer: how much can we deliver in two weeks?

When the biggest tasks compress from a week to a day or two, estimation collapses. Most tasks land in the same range. Planning poker for a one-day task is like insuring a five-dollar package.

Allen Holub has said it well: just pick the most valuable items from the backlog and work on those. Story points add ceremony without adding clarity. He was right even before AI accelerated this. Now it's obvious.

Refinement

Refinement protected against misunderstood requirements. Five (or more) people in a room, reviewing the backlog, asking questions to the Product Owner. The function is real: business and IT speak different languages, and that won't change.

In a traditional setup, the Product Owner wrote a few sentences about a feature, brought it to refinement, and the team spent an hour pulling out the missing details. What format? What edge cases? What happens when the list is empty? The PO often didn't know these questions existed until the team asked them. Refinement was the mechanism that forced precision out of vague intent. And it was expensive: five people, regularly, for an hour or more, because the input wasn't precise enough for developers to start working without that conversation.

AI changes both sides of this. The PO can now work with AI to prepare tasks before any developer is involved. The AI asks the same clarifying questions the team used to ask in refinement: what about edge cases, what are the acceptance criteria, what does "export" actually mean? The PO answers them upfront, at their own pace, without booking five people for an hour. On the developer side, the remaining questions surface during implementation. The developer does discovery on real code, not hypotheticals, and goes back to the PO with specific concerns. One or two people instead of five, at the moment of work rather than a week before.

Refinement doesn't disappear. It dissolves into the workflow and loses its ceremony form.

Sprint Planning

Sprint planning protected against wrong priorities. The team decided together what to work on for the next two weeks.

However, if tasks are many and relatively quick to implement, planning them two weeks ahead is questionable. A prioritized queue works better. Pull the next most valuable item when you finish the current one. This is what Kanban teams have done for years. AI just made the argument harder to ignore.

Daily Standup

Context-dependent. A small senior team coordinates naturally through pull requests and chat. A large or distributed team may need a sync point. But it doesn't have to be a daily ritual with a fixed format.

One option is to make it async: a written status update (what I did, what I'm doing, any blockers), with the team lead scanning for problems and a standing offer of "available for a call in the next half hour if anyone needs to talk." Another is to keep a live sync but make it every other day, or only when someone requests it. The point is to serve the function (coordination, unblocking) without the rigidity.

Retrospective

Paradoxically, the retrospective becomes more important than ever. The way teams work with AI changes fast enough that constant calibration is necessary. What prompting patterns work? Which tasks should go to AI and which stay manual? How do we structure context for the coding assistant?

The retrospective is the only ceremony that protects decisions about process, not about implementation. It scales up, not down.

Demo and Review

The demo doesn't disappear, but it stops being a ceremony by default. Building the wrong thing still costs opportunity, and faster implementation doesn't recover that.

The demo also serves alignment. It shows everyone what has been delivered, what changed in the product, and what they may be working on next. In a model where developers pull from a queue and work independently, the demo becomes one of the few moments where the whole team sees the bigger picture. Without it, people optimize locally and lose sight of where the product is heading.

The format is up to the team. It might be synchronous, once a week, with the whole team in a room. It might be fully async: developers upload short recordings and detailed descriptions, others review on their own time. It might stay a ceremony if the team decides that works. The point is that it no longer has to be one. The function (visibility, alignment, feedback) stays. The rigid format becomes a choice, not a requirement.

How Scrum Masked the Real Bottleneck

Business and IT have always spoken different languages. Business thought IT should "just understand." IT didn't understand why business couldn't see the ambiguity in their own descriptions. A few sentences per feature, maybe a rough mockup, and then surprise on both sides: business wondered why developers took so long and delivered something different. Developers wondered why business couldn't articulate what it actually wanted.

Neither side was wrong. The input to the development process isn't what business says. It's what IT understands from what business says. The gap between the two was always the real bottleneck.

Scrum tried to close this gap for twenty years. Refinement, user stories, acceptance criteria, definition of ready. The whole machinery existed because this translation problem was real and expensive. And Scrum managed it through iterativeness: "You don't need to know everything upfront, we'll iterate." It worked because each iteration took two weeks and cost relatively little compared to waterfall.

AI exposed the problem. Iteration now takes hours, but the quality of each iteration depends on the quality of input. Garbage in, garbage out. Just faster.

AI has the same questions programmers used to have. It either assumes its own answers (vibe coding territory, where each assumption is a coin flip and the probability of getting the whole feature right drops exponentially) or it stops and asks. And the bottleneck lands on the business side.

AI doesn't speed up a bad process. It revealed that the bottleneck was always input, the quality of product thinking. Scrum masked it, but now it's visible.

Three Ways Companies Respond to the Visible Bottleneck

Once the bottleneck is exposed, the organizational response determines whether AI actually helps. AI gives teams speed. What companies do with that speed separates those who grow from those who burn through the opportunity.

Scenario A: more output for the same investment. Keep the IT team. Invest in business analytics: more product people, better specifications, AI-assisted discovery. The bottleneck doesn't form because input quality grows proportionally to delivery capacity. The company grows.

Scenario B: same output for less investment. Reduce the IT team. Input stays the same. Delivery pace holds because AI compensates for fewer developers. The company saves cost while maintaining its current trajectory.

Scenario C: the illusion. Change nothing. Assume programmers will deliver more because they have AI. Input quality stays the same (the same vague descriptions, the same incomplete requirements), AI has nothing to generate better code from. The developer spends time clarifying, or the AI guesses. Best case: faster delivery of mediocre solutions. Worst case: vibe-coded features that look like they work but don't do what the business wanted.

Scenarios A and B are deliberate choices. Scenario C is what happens by default.

Why Input Quality Determines AI ROI

Companies thinking "give programmers AI and it will be faster" will hit Scenario C. Companies that understand the investment must go into input quality, into analytics, product ownership, and discovery, will be the ones that benefit.

The Product Owner becomes a very important part of the process. Not a backlog manager. Not a prioritizer of story points. A provider of quality input. AI can help here too: the PO can work with AI to break down epics, generate the questions that a team used to ask in refinement, and clarify edge cases before a developer ever picks up the task. But the thinking still has to come from a human who understands the business.

Sonya Siderova put it well: "Agile isn't dead. It's optimizing a constraint that moved." The constraint moved from implementation to decisions. Scrum's apparatus of ceremonies still optimizes the old one.

So what does a process built around the new constraint look like day to day? That's the topic of Part 2: Pulse, a pull-based workflow with a cadence that keeps teams from burning out in continuous flow.

Articles in this series

• Why Scrum Stops Working in the AI Era
• Pulse: Software Development Without Sprints
• Product-Centered Team for the AI Era