Javier Castro

Posted on Nov 3

The Daily Standup Deserves to Die. The Sprint Review Doesn't.

#whatreplacesthesprint

AI has automated away the informational content of Scrum — which means the only ceremonies worth keeping are the ones that were never really about information at all.

Picture this: it's 9:30 AM, eight engineers join a Zoom call, and for twelve minutes they take turns reciting what they did yesterday and what they're doing today, confirming — one by one — that they have no blockers. The Scrum Master types notes into a Confluence doc nobody will read. The meeting ends. Everyone context-switches back to whatever AI tool is currently writing their code at twice the speed they can review it. Nothing changed. Nothing needed to.

This is the daily standup in 2026. The provocative claim worth making here isn't "Agile is dead" — that's a decade-old obituary with bad predictive accuracy. The real claim is narrower and more uncomfortable: AI has already automated away the informational content of most Scrum ceremonies, exposing which ones were always just information pipelines wearing a collaboration costume. The daily standup is the obvious casualty. The sprint retrospective, properly redesigned, may be the ceremony that matters most right now — precisely because AI makes its failure mode worse.

The Productivity Paradox Nobody Wants to Discuss

Start with the data, because it's messier than vendor slide decks suggest.

METR, the nonprofit AI evaluation research group, ran a randomized controlled trial on how early-2025 AI tools affect the productivity of experienced open-source developers working on their own repositories. Developers using AI tools took 19% longer than those working without them. AI made them slower. The perception gap is the more disturbing detail: initial developer forecasts predicted a 24% speedup; post-task self-assessment reported a 20% speedup; objective measurement revealed a 19% slowdown.

This is not a reason to throw out AI tooling. METR's own researchers note the study reflects a specific window of models and a specific type of task — experienced developers on complex, mature codebases — and METR itself now labels the result as historical, saying it no longer necessarily reflects current AI tools or current developer workflows. But the perception gap is durable evidence of something structural: teams are operating on vibes, not measurement.

At the codebase level, the problems compound. GitClear, based on analysis of 211 million lines of code, found that AI coding assistants are eroding code quality by increasing duplicated and copy/pasted code. The number of code blocks with five or more duplicated lines increased by eight times during 2024. And 2024 was the first year on record where within-commit copy/paste exceeded "moved" (refactored) code. GitClear's 2026 update extended the picture further: refactoring fell from 21% to under 4% of code changes, while duplicated code blocks per million changed lines rose 81% over the same window.

Here is what this means for delivery teams running Scrum: AI is shipping code faster, but that code is increasingly a debt instrument. AI accelerates writing code, but Scrum was never primarily about writing speed — it's about coordination, prioritization, and managing complexity and stakeholder alignment. Faster code generation makes deciding what to build, and coordinating across people, the bigger bottleneck. Congratulations on the velocity.

The Standup Is Already Doing Its Job Asynchronously

The daily standup was invented to answer three questions: What did you finish? What are you working on? What's blocking you? Those are information-retrieval tasks. In 2026, they are solved problems.

AI can replace the status-update portion of standups by pulling progress data from GitHub, Jira, or Linear automatically. Tools like Spinach, Geekbot, and Linear's built-in async updates generate pre-meeting summaries from actual commit history before anyone opens their laptop. Instead of building a sprint from scratch, the team reviews an AI-generated proposal. Teams report cutting planning meetings from two hours to thirty minutes.

Kent Beck, inventor of Extreme Programming and chief scientist at Mechanical Orchard, told LeadDev that if everybody's working in the same room, "a daily stand-up doesn't provide value for the cost." "A stand-up brings with it a daily coordination cost where everyone has to be there at the same time," he continued. "The time spent at the stand-up can't be doing other things."

Beck made that observation before AI could auto-generate the entire content of the meeting from version control history. The economic case has only gotten more one-sided. There's an irony at the heart of daily standups: they exist because Scrum values communication, but they often make communication worse. The ceremony's original purpose was to surface blockers fast. Instead it became a serialized status broadcast — exactly the kind of thing AI handles better than humans, at a fraction of the cost.

Microsoft's 2024 Work Trend Index found that 78% of developers consider "meeting overload" their biggest productivity challenge. The standup isn't the only culprit, but it's the most defensible sacrifice. Cut it — or go fully async — and the actual information flow doesn't degrade. It improves, because engineers stop treating their morning commit as the thing they'll narrate at 9:30 and start treating it as something they'd actually want read by a machine.

Sprint Planning: Keep the Decision, Cut the Theater

The case against planning meetings is similar, but the cuts are more surgical.

Teams may spend less time during sprint planning discussing the mechanics of work and more time strategically coordinating the use of AI and redefining the Definition of Done as they experiment with new tools. That reframe is correct. The problem isn't sprint planning as a concept — it's sprint planning as a manual process. Estimating story points by gut feel was always a low-signal exercise. AI now does it better: if your team historically underestimates database migrations by 50%, an AI assistant can point that out before you commit to the sprint.

Choosing the backlog, writing the goal, prioritizing, committing to capacity — all of that requires deciding what should happen, based on context that often lives outside the data AI can access. That's the part worth protecting. The ceremony should shrink to the irreducibly human decision layer: where are we going, and why. Everything else — story splitting, acceptance criteria, capacity math — is clerical work that machines do without coffee.

By 2027, weekly grooming meetings will become anachronistic at AI-mature teams. Continuous AI-assisted grooming — where stories are split, INVEST-checked, and acceptance criteria expanded as they enter the backlog — replaces the weekly gathering. Backlog refinement as a separate ceremony is already a candidate for elimination in teams using tools like Jira's AI Assistant or Linear's continuous triage. The sprint planning meeting collapses to thirty minutes of goal-setting if the pre-work is handled algorithmically.

The Sprint Review: Counterintuitively, Keep It

Here's where the argument gets interesting, because the conventional wisdom runs the other way. If code ships faster, sprint reviews become less meaningful — smaller scope, lower stakes per cycle. That analysis is wrong.

As sprint frequency increases, the scope shown in each review naturally shrinks. This might look like the review matters less. It's the opposite. Stakeholder feedback on a focused, narrower slice of working software is more actionable than feedback on a sprawling two-week dump. The sprint review's actual function — getting early signal from people outside the delivery team about whether the product is pointing in the right direction — becomes more valuable, not less, when AI is generating code at speed. Bad direction, implemented fast, is an expensive problem.

By 2025, although 78% of companies were using AI, about 80% reported no significant business impact — a "generative AI paradox" attributed to teams producing features without sufficient product guidance or validation. That's not a tooling problem. That's what happens when a feedback loop breaks. The sprint review exists precisely to close that loop with the humans who can tell you whether the feature actually matters. No AI tool has a substitute for a product manager watching a real user's face during a demo.

The Retrospective: Most Valuable Ceremony, Worst Follow-Through, New Purpose

The sprint retrospective would be the most valuable ceremony in Scrum — if it weren't also the one with the worst follow-through. AI can run the same ceremony and actually keep the results, because the lesson gets loaded before the next session instead of filed and forgotten.

That framing gets at the real problem. Most retrospectives end with action items in a Confluence page that nobody reads before the next retrospective. AI-assisted retros fix the retrieval problem, not the conversation problem. Surfacing a pattern across retrospectives is valuable. Deciding what the team should do about it is different — and that's not a job to outsource. Retro insights should be presented as conversation starters, not conclusions. A retrospective is a team accountability exercise, and handing the conclusion to an algorithm undermines what the ceremony exists to build.

But there's a new purpose the retrospective needs to absorb, because no other ceremony is doing it: if Scrum's pillars of transparency, inspection, and adaptation were important before, they're doubly so now. AI can generate a flood of output and data that a team can drown in or be misled by. Questions like "what AI-generated code did we ship that nobody fully reviewed?" and "which sprint commitments were we optimistic about because Copilot made it look easy?" belong in the retrospective now. They belong nowhere else.

A Proposal You Can Actually Bring to Monday's Planning Call

Here's the concrete version:

Kill the daily standup. Replace it with an auto-generated async digest — Linear, Geekbot, or whatever reads your actual commit and ticket activity — with a standing agreement that humans only convene synchronously if a blocker has been in the system for more than four hours and wasn't self-resolved. The information doesn't disappear; the theater does.

Shrink sprint planning to goal-setting only. Let AI handle story prep, estimation, and backlog sequencing before the meeting. Protect thirty minutes for the team to say, out loud, what the sprint is actually for — and whether the backlog reflects that. If those two things don't match, no AI tool will tell you.

Protect the sprint review. Not because it's sacred, but because it's the only ceremony that puts working software in front of people who can tell you whether you're building the wrong thing at impressive speed. With AI-accelerated delivery, this signal is the constraint. Treat it like one.

Redesign the retrospective around AI governance. Add an explicit check on code quality and review coverage alongside the usual team dynamics discussion. Not as bureaucracy — as consequence management. Someone needs to be asking where the duplication went, and whether the AI-assisted sprint created technical debt the team can't see from the inside.

The question to bring to your team isn't "should we cut ceremonies?" It's sharper: for each ceremony, ask what information it produces and whether a machine is already producing that information more reliably. Whatever survives that filter is worth keeping. Whatever doesn't was probably a cargo cult long before anyone wrote the first prompt.

The real threat to Scrum isn't AI. It's teams that automate their way to the illusion of coordination while skipping the judgment calls that actually determine whether the product is worth building. The ceremonies that survive are the ones that force those judgment calls into the open, with humans in the room who are paid to disagree. There are fewer of those than most Scrum practitioners would like to admit — but more than the "Agile is dead" crowd will ever give credit for.

DEV Community