Is Scrum outdated in the age of AI?

Every few years, someone declares the end of Scrum. First, DevOps was supposed to kill it, then remote work, then scaling. Now, AI is supposed to kill it. It’s worth taking this question seriously, because after years of working as a Scrum Master, I’ve learned that behind every headline like this usually lies a single real question. This time is no exception. However, the question isn’t: “Is Scrum dead?” Rather, it is: Does the way we implemented Scrum a few or several years ago still fit software development, where more and more work is being done by AI agents?

My answer is neither “yes” nor a simple “no.” It is: Scrum is not obsolete in the AI era. What can be obsolete is its rigid, ritualistic implementation. Whether Scrum still helps the team depends on whether we treat it as a lightweight framework based on empiricism, or as a set of meetings, estimates, and dashboards that no one inspects anymore. And this distinction has never been more important than it is now.

In short: what does AI really change in Scrum?

AI does not mean that teams no longer need Scrum, Sprint Review, Retrospective, or Definition of Done. What it does mean is that old assumptions about where the biggest constraint in the process lies are starting to break down.
For years, many teams organized their work around the assumption that the slowest, most expensive, and most uncertain part of delivery was writing the code itself. In the age of AI agents, that assumption is increasingly no longer true.
Code still needs to be correct. It still needs to fit the system. It still requires judgment. But the act of generating code itself, the activity around which many teams have unconsciously arranged their practices, is no longer the only bottleneck.
The new bottleneck is shifting in two directions: left, toward specification, and right, toward verification.

Scrum Guide does not describe a ritual. It describes a framework.

Let’s start by being fair. The Scrum Guide requires surprisingly little. It describes the three pillars of empiricism: transparency, inspection, and adaptation. It defines the accountabilities of the Product Owner, Developers, and Scrum Master. It identifies the events, artifacts, and rules that connect them. That is all. Everything else, meaning what we often call “our Scrum,” is already a layer of practices we have added ourselves: the way we estimate, how we interpret Definition of Done, the tools we use, the rhythm of meetings, the refinement format, the way we run Sprint Review, dashboards, reports, dependencies, exceptions, and local compromises. It is in this layer, not in the Scrum Guide itself, that a silent assumption sits — one that most teams brought into Scrum and never named: “Software development is the expensive, slow, and uncertain part of delivery, so our practices must primarily manage the throughput of the development team.” For years, that assumption was useful. That is why it became so deeply embedded in the way we implement Scrum that we stopped noticing it. And now, it is beginning to break down.

What does AI really change in software development?

Let’s be precise, because the noise around AI in software development is deafening. AI agents do not “build complex applications in a few hours” in a real enterprise environment. That is a sales slogan. What is actually happening is less spectacular in headlines, but far more important in practice: the cost of producing code is decreasing for a large class of tasks. This includes drafting solutions, scaffolding, refactoring, connecting layers, generating tests, filling in repetitive fragments, and translating intent into syntax.

The code still needs to be understood. It still needs to be checked against the architecture. It still needs to be assessed for technical debt, regression, and security risks. Someone who understands the domain, the system, and the consequences of decisions is still needed. But if the cost of generating implementation decreases, the expensive question is no longer only: “Who will write this?” Increasingly, the question becomes: “What exactly are we supposed to build, and how will we know that the result is correct?” And as Scrum Masters, we know this rule very well: if you optimize the process around a constraint that no longer constrains, you are optimizing the wrong thing. The team feels busy. The charts look healthy. Velocity may even increase. And yet the organization may be accelerating toward the wrong destination.

The new bottleneck: specification

The first shift happens to the left, toward specification. When an AI agent can produce a plausible-looking implementation of almost anything in a matter of minutes, the expensive question becomes: an implementation of what, exactly?

An imprecise Product Backlog Item has always been a problem. In the age of AI, the problem becomes bigger, because an imprecise PBI can very quickly produce a confident, elegant, and incorrect result.

The rarest skill in the team is no longer simply “being able to write code.” The ability to define the problem precisely enough for the generated solution to actually be the right one is becoming increasingly valuable. This means that a Product Backlog Item in the age of AI should answer these questions more clearly:

• • What user or business problem are we solving?
  • What outcome do we want to achieve?
  • What should the solution not do?
  • What are the domain, technical, and regulatory constraints?
  • How will we know that the AI agent’s output is correct?

This is not bureaucracy. It is a way of reducing risk. In the age of AI, a weak backlog does not slow the team down. It accelerates the production of wrong solutions.

The new bottleneck: verification

The second shift happens to the right, toward verification. The output of an AI agent is probabilistic. The same prompt, similar context, and a similar task may produce correct code once, and another time produce a subtle vulnerability, a mismatch with the intended outcome, or a solution that only looks reasonable at the syntax level. There is no point at which you can say: “We trust this agent now, so we can stop checking.”

That is why Code Review, tests, security review, architectural validation, and verification against the actual business intent are no longer just a phase at the end. They become continuous work, just as valuable as production itself. This is not an argument against Scrum. It is exactly the kind of contextual change that empiricism was designed for. You verify because you observe, not because you trust.

Definition of Done in the age of AI

If a team uses AI agents in the delivery loop, the Definition of Done cannot remain a document from three reorganizations ago.

Definition of Done should begin to cover not only whether the code works, but also whether the agent’s output has been verified in terms of quality, business intent, security, and maintainability.

In practice, Definition of Done for working with AI may include:

• Has the code generated by AI been reviewed by a human?
• Do the tests cover not only the happy path, but also edge cases?
• Is the solution aligned with the intent of the Product Backlog Item?
• Has the security impact been checked?
• Does the team understand the generated solution well enough to maintain it?

The most important change is not adding a single checkbox that says “AI code reviewed.” The most important change is recognizing that generating code is not proof that the work is done.

Story Points and Velocity were never a measure of working hours

Here we need to disarm an oversimplification that naturally comes up in discussions like this, and that is heard from management more often than we would like. A story point was never a measure of human effort alone. Any team that has estimated for longer than a quarter knows that a point contains much more: the volume of work, technical complexity, uncertainty, risk, and the problems of the environment in which we work. If you know that the test environment breaks every other day, that you have a dependency on a team that responds after a week, and that a specific integration has historically always caused resistance, all of that must be reflected in the estimate. That is exactly why a story point is a relative unit assigned to a specific team. It is not a conversion into hours. That is its entire strength.

So what does AI really change?

Not that estimation stops working. What changes is the composition of what makes up a point. The component of “translating intent into code” shrinks dramatically. But complexity does not shrink. Uncertainty does not shrink. You could even argue that it increases, because the probabilistic output of an AI agent is now added to the equation. The effort of verification increases. Integration risk remains. An unstable test environment still needs to be accounted for, because an AI agent will not magically fix it when dozens of people are working on it in parallel. The practical consequence is simple and not revolutionary: teams will need to rebaseline their points. Old reference stories no longer mean what they used to mean, because the distribution of effort inside them has changed. We have always done this when the stack, team composition, domain, or architecture changed.

The practice itself still holds up. Velocity is similar. Velocity has always been an empirical signal of a specific team’s capacity, used for forecasting. It was never a measure of productivity. It was never a basis for comparing teams. It should never have been a KPI for management. Teams that used Velocity correctly will simply rebaseline it and continue forecasting.

Teams that misused Velocity as a measure of “how much we produced” will discover that AI exposes this misuse completely. The volume of generated code becomes cheap and stops meaning anything. It is not Velocity that failed here. What failed was the way it was used.
AI simply turns on a red warning light above an error that had been there from the beginning.

Sprint Review should show outcomes, not just features

If AI agents accelerate code generation, Sprint Review should not become a longer list of things that “we managed to deliver.”

That would be exactly the trap that is easy to fall into: more code, more features, more movement, but not necessarily more value.

Sprint Review in the age of AI should answer these questions more clearly:

• What outcome did we achieve?
• What did we learn?
• Did we solve the right problem?
• What did verification show?
• Where did the AI agent accelerate the work?
• Where did it generate risk?

This is still Scrum. It is simply Scrum used according to its intent: as a mechanism for inspection and adaptation, not as a ceremony checked off in the calendar.

Retrospective as a place for inspecting the work of people and agents

In teams using AI, the Retrospective should no longer be limited to questions about communication, flow, and organizational impediments.

It should also include work with AI agents:

• Where did AI actually shorten the time?
• Where did it increase the cost of verification?
• Which types of tasks are suitable for the agent?
• Which tasks should remain with humans?
• Where did hallucinations or subtle errors occur?
• What needs to change in the Definition of Done or refinement?

The teams that will struggle the most will not be those using Scrum. The teams that will struggle the most will be those running a frozen configuration of Scrum and defending the ritual instead of practicing inspection.

So, is Scrum outdated?

After all this, my answer as a Scrum Master is this:

Our implementation of Scrum may be outdated. A frozen configuration from years ago, where value is validated through features instead of outcomes, Velocity hangs on a management dashboard, and Definition of Done has not been revised for three reorganizations. That does age, yes. But that is not Scrum. That is a ritual we have mistaken for a framework.

Scrum describes itself as a lightweight and deliberately incomplete framework. It is a frame into which a team places its own techniques, tools, and practices, and then tunes them to the context. That is not a weakness that needs to be compensated for in the age of AI. It is exactly the feature that allows Scrum to survive this era. The core of Scrum adapts without being stretched.

Empiricism, transparency, inspection, and adaptation matter even more when working with probabilistic AI agents. A small, cross-functional team still works; only now, “cross-functional” also includes people who can specify precisely and people who rigorously verify the output of AI.

Definition of Done can absorb verification of the agent’s output. Sprint Review can show outcomes instead of features. The Retrospective can become the place where the team examines what failed in working with AI and adapts the process accordingly. The Sprint can shorten toward the rhythm of the real feedback loop. None of this breaks Scrum. All of it is Scrum used as it was intended.

What should teams recalibrate first?

If you are working in Scrum today and introducing AI agents into the delivery loop, I would not start by renaming meetings or abandoning Sprints.

I would start with five things.

• Product Backlog Item – does it describe the problem, outcome, and constraints precisely enough to prevent an AI agent from generating a plausible-looking mistake?
• Definition of Done – does it cover verification of AI-generated code, security, tests, and alignment with business intent?
• Code Review – does the team check not only style and correctness, but also the sense of the solution, hidden assumptions, and risks?
• Sprint Review – do you show outcomes and product decisions, or only a list of features?
• Retrospective – do you analyze how AI has changed the team’s work, where it helped, and where it increased the cost of control?

This is what makes Scrum agile. Not the mere presence of Sprints, Plannings, and Daily Scrums.

Scrum gave us permission to adapt it on day one. The age of AI is simply the moment when it is finally worth using that permission.

FAQ