A team coding with AI:
which Scrum rituals to adjust?

For a few months now, the same scene has been playing out in almost every product team. Each developer now has an assistant that writes the code for them, an agent that generates the tests, a tool that summarises the tickets and proposes a fix before you have even finished reading the bug. Code output has surged. And very quickly comes the awkward question: are we still doing Scrum the way we used to?

The short answer is no. The useful answer is more interesting.

AI does not break Scrum. It moves the risk. A team's bottleneck is no longer writing the code: it is deciding what to build, verifying what has been produced, and keeping everyone aligned on a goal that makes sense. And that is exactly what the rituals are for. So some become more important than before, others change function without changing name, and two you might be tempted to trim are precisely the ones to leave alone.

I have argued before that Scrum is a tool, not an identity. It has never been more true. The right question is not "how do we protect our rituals from AI?", but "what is each ritual for, now that the easy part is automated?". Here is the framework I apply, ritual by ritual.

1. What AI really changes (and what it does not)

A coding assistant speeds up the most visible part of the work: producing lines. But producing lines was never a good team's bottleneck. What costs is understanding the problem, choosing a defensible solution, integrating it without breaking the rest, and being sure it actually works. AI makes typing nearly free and leaves everything else exactly where it was.

The result is counter-intuitive. Speeding up the step that was not the problem does not make the team proportionally faster. It shifts the pressure downstream: more code produced means more code to understand, to review, to test, to hold together. The queue does not vanish, it moves one notch along.

And there is a category of work AI does not touch at all: genuinely complex work, where the solution is not known in advance and you have to experiment to learn. That is exactly the ground Scrum was designed for. AI quickly generates a plausible answer to a badly framed question; it does not ask the question for you.

AI makes writing nearly free. It makes neither the decision easier, nor the verification less necessary.

2. The daily standup: from "who is doing what" to "what is genuinely done"

The classic standup goes round the table: yesterday, today, blockers. In an AI-assisted team, that format loses even more of its meaning. When anyone can generate a draft feature in a morning, knowing "who is coding what" tells you nothing useful. Work moves fast and messily; the declared state of progress no longer means much.

The signal that matters has moved. It is no longer "how far along is your code?", but "what is actually integrated, reviewed and verified?". A ticket whose code was written entirely by AI is not "almost done": it is at the front of the review queue, that is, at the start of the expensive part, not the end.

So the standup has to stop measuring activity and start measuring flow. What I surface every morning: what is waiting for review, what is blocking an integration, what has been produced without a human having understood it. The rest, AI already knows.

3. Sprint planning: estimate the uncertainty, not the typing effort

A good part of our estimates was measuring, without saying so, the time it would take to write the code. Story points were a proxy for an effort of which writing was a major component. When that component collapses, an estimate anchored to it becomes misleading: the task looks tiny because the code will come out in ten minutes, and you forget the half-day needed to understand it, secure it and wire it into the rest.

Planning has to recentre on what remains uncertain. A well-defined task, in a domain you know, where AI will produce code the team can review quickly: it really is small, own that. A task that touches a sensitive spot, a poorly tested area, a fragile dependency, or whose side effects nobody understands yet: it is big, no matter how many lines AI would spit out. Estimate the review and the integration, not the generation.

It is also the moment to remember that velocity in points will never tell an executive whether the team is delivering value. It will tell them even less once line count stops being a constraint. Planning exists to decide where to put the team's scarce attention, not to fill a points quota.

4. The definition of done: the ritual to tighten, not loosen

This is the most threatened ritual, and paradoxically the one to reinforce. AI-generated code has a treacherous property: it looks right. It compiles, it follows the conventions, it passes the obvious tests. And it can be subtly wrong, mishandle an edge case, open a vulnerability, or test its own presence rather than the expected behaviour. "It looks fine" is not a definition of done.

Generating code is not the same as maintaining it: something I have already spelled out about no-code, low-code and automation, and it holds word for word for AI-assisted code. The definition of done is the net that catches the gap between "produced" and "reliable". It has to become more explicit, not less.

A few non-negotiables I add to a definition of done when a team codes with AI:

• A real human review. Not a ten-second "LGTM": someone has read the code, understood it, and stands behind it. If nobody on the team can explain what a piece of code does, it is not done, it is debt.
• Tests that verify behaviour. A test generated alongside the code, by the same tool, may simply validate what the code does, not what it should do. The test has to come from intent, not from the result.
• A security and provenance check. Where do the suggested dependencies come from? Does the code touch sensitive data? An AI will happily propose an obscure library or a secret in plain text; the definition of done is where you catch it.
• A named owner. Assisted code has no author in the usual sense. Someone still has to answer for it in six months, when it needs to change.

5. Code review: the team's new bottleneck

If writing becomes free and review stays human, the team's real capacity is now measured by what it can seriously review, not by what it can produce. Review moves from an end-of-cycle formality to a central constraint. That is where the queue forms, and that is where you have to set limits.

In practice, I borrow Kanban's most useful discipline: a work-in-progress limit on review. You do not launch ten parallel efforts just because AI can start them all; you cap the number of things waiting for review, because that is the team's true ceiling. Smaller batches, short pull requests, a review done early and in pairs when the subject is sensitive. A team that produces three times more code and reviews at the same speed as before is not three times faster: it accumulates three times more unreviewed debt.

It is also a matter of stance, not just tooling. Reviewing code a colleague thought through and wrote is an act of collaboration. Reviewing code nobody really wrote demands a different kind of vigilance, closer to an audit. That shift has to be prepared and supported: it is a good part of what I come to install when I work with a team.

6. The retrospective: leave it alone

Here is the first ritual to leave strictly intact. The retrospective produces no code, is not measured in points, and has no automatable equivalent. It is the moment when a team looks honestly at how it works, names what slows it down, and decides to change something. No agent will do that for it, because the raw material is trust between people, not data.

Better still: in a team adopting AI, the retrospective matters more than ever. Working habits shift every week, new tools come in, the relationship to the code changes. Without a regular space to digest all that, the team endures the change instead of steering it. If you had to cut a single ritual to save time, this is absolutely not the one.

7. The sprint goal: leave that alone too

The second untouchable ritual is the most discreet and the most vital. The sprint goal speaks of neither code nor method: it says why this sprint exists, what outcome it targets for a user or for the business. How the code is produced is none of its concern. And that is precisely why it becomes the team's most important anchor.

The real danger of a team that codes very fast is not coding badly. It is efficiently building the wrong thing. When producing costs almost nothing, the temptation is to produce a lot, without asking whether it serves a goal. The sprint goal is the guardrail: it turns code output into direction. Without it, AI mostly hands you the means to aim at the wrong target faster than before.

What really matters here

AI does not replace Scrum and does not make it obsolete. It shifts the team's centre of gravity, from writing to deciding and verifying, and your rituals have to follow that shift.

• Adjust the standup: measure real flow (what is integrated, reviewed, verified), not declared activity.
• Adjust planning: estimate the uncertainty, the review and the integration, never the typing effort.
• Tighten the definition of done: human review, behaviour tests, security and provenance, a named owner.
• Treat review as the real bottleneck: limit work in progress, shrink batch size, review early.
• Do not touch the retrospective: it is the human space that steers change, and change is accelerating.
• Do not touch the sprint goal: it is the anchor that stops you from building the wrong thing fast.

A good Scrum Master, in an AI-assisted team, does not defend their ceremonies: they redirect the team's attention to where the risk has migrated. The framework does not change name. It changes function.

Further reading

• Scrum is not a religion. Here is when to drop it, to decide whether the framework is still the right tool, before you even bring AI into it.
• No-code, low-code and automation: the 2026 guide for decision-makers, the same logic on the technology side: what these tools actually do, and where they trap you.

In the teams I work with, the arrival of AI almost never poses a tooling problem: everyone already has the tools. It poses a problem of rituals that have become habits, repeated without asking what they are for now. Putting each ritual back in front of its function is often all it takes for a fast team to become a reliable one again. You can read what the teams I have supported say about it.