Scrum in the Agentic Era: Which Ceremonies Survive

Picture the standup the morning after the agents ran overnight. Three changes that would have been a week of work are already drafted, tested, and sitting in review. The board moved on its own. And one by one, people realise they have nothing to report in the old sense — nothing was blocked, because nothing was being typed. So what, exactly, are we standing up about?

That awkward silence is the real question, dressed up. The version doing the rounds online — "if agents write the code, is Scrum dead?" — is the wrong one, and it leads teams to the wrong answers: either ripping the ceremonies out in a burst of enthusiasm, or defending them unchanged because they still fill the calendar. Both miss what actually happened. Scrum’s ceremonies were built for a world where engineering capacity was the scarce resource — planning rationed it, estimation forecast it, the standup unblocked it, the retro tuned it. Agentic delivery removes that scarcity. Generation becomes abundant, and the ceremonies are left optimising for a bottleneck that has quietly moved.

So the honest framing is neither "dead" nor "unchanged". The ceremonies survive as slots in the week; their *job* changes. Each one has to be re-pointed from coordinating production to governing acceptance. Get that right and Scrum becomes more useful in agentic delivery, not less — because the work it now coordinates (deciding what to build, whether to trust what was built, and how far to let agents act) is exactly the work that has become scarce.

The constraint moved; the calendar did not

Start with the mechanism. When a developer wrote most of the code, cycle time was dominated by the time to build. Speed up the building and you sped up delivery, which is why a decade of tooling — and a decade of ceremonies — aimed there. With agents drafting changes across many files in minutes, that step compresses, and the dominant cost shifts downstream to review and verification. Practitioner analyses now describe this directly: faster generation produces slower review, because a human still has to understand and accept each change, and there are suddenly far more of them. LeadDev catalogued the metrics this breaks; engineering teams such as Agoda have reported the bottleneck moving squarely into code review. This is the same shift we write about everywhere on this site — once generation is abundant, acceptance is the constraint — showing up in the team’s weekly rhythm.

Ceremonies optimised for scarce engineering capacity are mis-tuned when capacity is abundant and assurance is the scarce resource.

Refinement becomes specification

Backlog refinement used to mean slicing stories small enough to estimate and assign. That is the wrong unit now. The artefact an agent acts on is a specification precise enough to be executed — and the industry already has a name for it: spec-driven development. The guidance from GitHub and O’Reilly lands in the same place: write the intent, the constraints and the acceptance criteria unambiguously enough that they become executable inputs, then break the work into atomic, independently verifiable tasks, each with a human gate. So "grooming" stops being a sizing exercise. It becomes the authoring of the contract the agent will be held to — and the acceptance criteria stop being a footnote to the story and become the most important thing in it, because they are exactly what the evaluation harness will check.

Estimation: effort stops predicting value

Story points and velocity were always a proxy. They measured effort and trusted that effort tracked value closely enough to plan with. Agentic delivery weakens that link: the same outcome can cost wildly different amounts of human effort depending on how much review and rework the generated change demands. Be precise about the claim, though — it is tempting to say AI makes effort "free" and velocity therefore meaningless, and that overshoots the evidence. Effort is not free; it has moved, from typing to verifying. The defensible statement is narrower and more useful: effort is now decoupled from value, so effort-based metrics mislead when read alone. The fix is not to abandon measurement but to size the verification load rather than the typing, and to pair every effort metric with an acceptance or outcome metric — measure what lands, not what was generated.

When we instrumented our own delivery, story points and velocity told us almost nothing useful. Acceptance rate and rework told us everything — whether the work was actually landing.

Standup, review and retro: same slots, new jobs

Once you see the pattern, the rest of the ceremonies re-point themselves — the table further down is just this one insight applied six times. The standup is the clearest case. It stops being about unblocking the build, because nothing is blocked, and becomes about stewarding the review queue: what is waiting to be accepted, what is safe to accept, and where an agent’s autonomy needs a human to make the call. The sprint review follows — less a demo of what was built, more a showing of what was accepted: the evidence, the evaluation results, and, just as telling, what was rejected and why. And the retrospective stops tuning only the team’s process and starts tuning the machine the team now runs: the context the agents work from, the evaluations that gate them, the limits of their autonomy. Same hour in the calendar. A different question on the agenda.

Does the sprint still make sense?

If cycle time collapses, the sprint-as-batch — commit a fortnight of capacity, deliver it, review it — starts to look arbitrary. Some have responded by shortening the loop dramatically (Scrum.org has floated daily sprints); others propose a dual rhythm that separates the fast generate-and-verify loop from a slower planning-and-alignment cadence. This part is genuinely unsettled, and we hold it loosely. Our working view: the sprint survives, but as an assurance cadence rather than a production batch — a regular checkpoint where the team inspects acceptance, rework and the state of the harness, not how many points were burned down. The iteration was always meant to create a feedback loop; keep the loop, change what it inspects.

The Scrum Master: from facilitator to flow-and-assurance steward

The role most exposed by all of this is the Scrum Master — and the commentary is loud and contradictory, from "the role is in decline" to "it has never mattered more". Read across the sources and a believable middle appears, which we grade as observed, not settled. The transactional Scrum Master — the one who administers ceremonies — is genuinely at risk. The role itself is not. It re-points toward stewarding flow, governing agent autonomy, and curating the context and evaluations the team leans on. In many organisations that work will fold into engineering management, TPM or a delivery-assurance function rather than survive as a standalone title. The skill that appreciates is judgement about throughput and risk. The skill that depreciates is running the meeting. We would not bet the org chart on any one prediction yet — but we would invest in the assurance skills regardless of what the box ends up being called.

On our own agent-assisted work, the ceremony that changed most wasn’t planning — it was the standup. It quietly turned into a queue-management conversation about which generated changes were safe to accept that day. Nobody redesigned it on purpose; the new bottleneck simply pulled the meeting toward itself.

Re-point the ceremony: what to do on Monday

You do not need a new framework to act on this; you need to give each existing ceremony a new job description tuned to the constraint that now binds. Concretely:

Scrum is not dead in the agentic era, and it is not untouched. Its ceremonies were a good answer to a question — how do we coordinate scarce engineering capacity — that is no longer the binding one. Re-point them at the question that is, and the framework earns its place. For the organisational version of this argument, read why alignment beats agile; for the lifecycle it sits inside, the agentic SDLC; and for the metrics that should anchor the new cadence, how to measure AI engineering.