How to Customize Your Scrum for the AI Age

Leaders and their teams are wrestling with some version of the same question. Why plan a two-week Sprint when an agent can ship a feature in an afternoon? Do we still need a Daily Scrum when agents work through the night? My answer is that Scrum still holds, and matters more than before, provided you are willing to customize it. AI has collapsed the cost of writing code. It has not collapsed the cost of deciding what is worth building, or of proving that what you built creates value. Scrum was built for exactly that complexity, which has now moved to the center. The bottleneck shifted from typing code to human decision latency, review capacity, and outcome validation. So Scrum needs re-tuning. Keep the empirical loop, run it at the altitude of features and outcomes, and stop letting output metrics stand in for value.

The framework leaves room for exactly this kind of customizing. The Scrum Guide says that “the Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory.” The Guide stops there and does not tell you what to add. The rest of this post is my point rather than the Guide’s. You choose the practices you wrap around the framework. Choose them badly and teams end up blaming Scrum for problems Scrum never claimed to solve. Spec-driven development, WIP limits on active specs, and working agreements your agents can read are the AI-age instance of that. Most AI adoptions are quietly failing inside the gap the framework deliberately leaves open.

Scrum exists to help teams work through complexity: figuring out which products will be useful and valuable, and learning whether what we built works before betting more on it. The hard part has always been creating useful, valuable products. Generating the lines of code was the tractable half of the job. An AI lifecycle offloads the low-level how of API wiring and boilerplate to agents. Defining the what and validating the why remain as demanding as ever. Cheap generation reinforces that complexity, because it moves the constraint to human decision latency and review capacity while making it harder to see. I make that argument at length in AI didn’t kill agile, it moved the bottleneck.

It is worth being precise about what agentic coding does to empiricism. A spec-driven lifecycle multiplies artifacts that look like progress: capability canvases, detailed specs, plans, generated pull requests, agent run logs. The Increment is defined more narrowly than that. An Increment is a concrete stepping stone toward the Product Goal, additive to all prior Increments “and thoroughly verified.” Work does not count as part of an Increment until it meets the Definition of Done. The AI-age load lands squarely on thoroughly verified. Generation multiplied the volume of work arriving for verification without adding a minute of capacity to verify it. The clause that used to read as a quiet quality reminder is now the binding constraint on how much a team can honestly call Done. The Definition of Done is the discipline that keeps “usable” as the bar while the paper trail around it grows. Spec-driven development genuinely improves time to transparency, because we reach a usable Increment sooner.

Inspection changes less than people expect, since most teams already inspect whether the product works as specified. The older shift, from output to outcome, still carries the weight, and AI is orthogonal to it: you can accelerate an output-focused lifecycle and get the same results, only sooner. Spend the freed attention on adaptation. Change the specification and the assumptions under it as soon as the evidence says we were wrong.

Agentic coding lets each person generate far more output across a wider surface, so the same team can produce more usable Increments with fewer dependencies. A team of typically ten or fewer can take on bigger Product Goals. It is tempting to file agents alongside the IDE and the compiler as more tooling. A compiler is deterministic and an agent is not: the same spec against the same codebase can yield different answers on different runs. That is why accountability cannot move to the agent.

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. AI now carries much of the classic legwork: drafting backlog items and synthesizing research. What that frees up should go into value itself: the Product Goal, the business results behind it, and the leading indicators that tell you early whether a bet is paying off.

The Developers are the people committed to creating any aspect of a usable Increment each Sprint. In an AI lifecycle much of that authorship happens in specifications: context, constraints, examples, and validation criteria that agents execute against. They design the systems and verify what comes back. Accountability for the Increment’s quality stays with them. Reviewing generated code is a different skill with different failure modes and far higher volume. So review capacity becomes something the team has to size explicitly. Take how many items a named reviewer can carry to the Definition of Done in a day, averaged over the last two Sprints, multiplied by the reviewers you actually have. That product is your ceiling on Done work, whatever your agents generate. The team flow companion covers how to measure it.

The Scrum Master is accountable for the Scrum Team’s effectiveness. That job gets larger. Helping a team through disruptive change is that accountability at work. It now extends to shaping the human-agent operating model and protecting the team’s attention, which is less popular than it sounds when everything suddenly looks buildable.

The Scrum Master’s first listed accountability is worth pausing on in a post about customizing Scrum, because it is the one in tension with the title. That accountability is establishing Scrum as defined in the Scrum Guide. Those two things are compatible. The distinction is the whole argument here. Everything this post proposes changing sits in the space the framework deliberately leaves undefined. None of it removes an accountability, an event, or an artifact. The Scrum Master is the person who has to hold that line. It gets tested when “we are customizing for AI” starts being offered as a reason to skip the Retrospective or let the Definition of Done soften because the volume got inconvenient. Customizing the parts the framework left open is legitimate work. Dropping the parts it defined is not Scrum anymore.

The Sprint is the heartbeat of Scrum, a fixed-length container that holds focus and bounds risk. AI changes the ambition. A team of typically ten or fewer people can do remarkable things in a Sprint now. It can also stay stuck on the same legacy bottlenecks even though coding got faster. The Sprint is the container that shows you which. Sprint Planning still produces a Sprint Backlog, only at a higher altitude. The Sprint Goal, the selected Product Backlog items, and the plan for delivering them all center on why the Sprint is valuable and how humans and agents will swarm the work. Since generation is no longer the limit, the sharper question is our review and validation capacity: how many specs can realistically reach done.

The Daily Scrum matters more now, because agents stall waiting on human feedback and a daily cadence may not be frequent enough. In one enterprise team I coached through its first two quarters with agents, the event had become a queue-status readout. Each person recited which agent runs finished overnight and which pull requests were waiting. Nobody asked whether any of it moved the Sprint Goal. A different question fixed it: walk the board for what is aging and what waits on a person. It took three Dailies before the room stopped reciting.

The Sprint Review inspects the outcome of the Sprint and determines future adaptations. Here that means opening with real user data and business results. A feature parade tends to happen instead. That same team had turned its Review into exactly that: twelve generated features demoed in forty minutes, none with usage data behind it, because ten had never made it past release approval and the two that shipped had been live for under a day. We still walked the whole Increment, since the Review exists for that. We did it in fifteen minutes and spent the rest of the hour on why ten of the twelve were stuck. The team had gotten much faster at building while the organization had gotten no faster at releasing. The Review is the event where that gap has to surface as an adaptation.

Most teams under-run the Sprint Retrospective, which carries more weight in an AI lifecycle than any other event. Its subject has widened beyond how people worked together to how the human-agent system performed. That means asking which specs turned out to be too thin for an agent to execute against, where verification became the queue, and which agent-produced work had to be redone and why. Those three questions produce concrete changes to guardrails and spec patterns, the changes that make the next Sprint different.

All three artifacts and their commitments survive. Only their altitude shifts. The Product Backlog still orders what the team might build and still carries the Product Goal, but its items move up toward features and capabilities. Story-level detail now lives in specs that the Product Owner and the Developers shape together during refinement, with agents executing against what they agree on. The Product Goal can evolve in months where it used to hold for quarters, which argues for inspecting it at every Sprint Review.

The Sprint Backlog survives at a higher level, still carrying the Sprint Goal. Each item is often a feature, with its spec as the plan for realizing it. Collaboration and focus toward a Sprint-level goal still make the work a Sprint. That shared focus gets easy to lose when everyone has their own agents running.

The Increment remains as relevant as ever. So does its commitment, the Definition of Done. With agents generating more of the code it can get considerably stronger, with more automated verification and tighter gates. It also keeps the organization’s real constraint visible: release, compliance, integration, and adoption do not accelerate just because code generation did.

Scrum’s five values all get tested by a disruption this size. Focus changes the most, because it lost the thing that used to enforce it.

The Guide asks the Scrum Team to put its primary focus on the work of the Sprint and the best possible progress toward its goals. For twenty years that value had a physical backstop nobody named. A team could only build so much in two weeks, so the number of things it could genuinely have in flight was capped by hands and hours; Focus mostly described a limit the work imposed anyway, and a team that over-committed found out by Wednesday. That backstop is gone. Agents will start the fourth, fifth and sixth thing without complaint. None of them will tell you that the team now has more open work than any human can carry to Done. Nothing in the physics of the work will enforce Focus anymore, which makes it the value most likely to erode without anyone deciding to erode it. The team must now choose Focus and then defend it, with an explicit agreement about how many specs stay open at once.

Respect still runs between people. Only its surface area changed. Some of the work now arriving for review has no person behind it, which makes respect in review a harder call. Deference belongs to the human who chose to ship the work, shaped its spec, and put their name on the pull request. Courage gets a new object too. It now most often means saying that the demo looked impressive and none of it should merge. Openness runs in the same direction. It means being transparent about how much of the Increment an agent wrote and how thoroughly it was verified, at exactly the moment when not saying would be easier and would look better. Commitment holds steady, which is worth noting on its own, since a Sprint Goal is one of the few things agents cannot dilute.

Inside the Sprint an inner loop runs continuously: the team decomposes a high-level capability canvas into detailed specs, agents execute against them, and humans verify. The one flow heuristic worth adopting on day one is finish before you start, so open specs and pull requests get closed out before new ones open. Spec sizing and WIP limits per driver belong to the team flow companion. People hear big up-front design in all of this. The honest answer to that objection turns on batch size and feedback latency, which this piece works through.

A framework that lives only in a prose document depends on humans remembering to follow it. Your working agreements now have to live where agents can read them, which the operating system companion covers. Getting there is itself product work. Put the adoption onto the Product Backlog where it competes for capacity with everything else, and run an experiment or two per Sprint. Inspect the results like any other bet. The experiments that tend to pay off are writing the Definition of Done where agents can read it, taking one item spec-first from end to end, capping active specs per human, and bringing review-latency data to the next Retrospective.

Treat this as one working session on your team’s own board. Change the two rows where your evidence is strongest, and leave the rest until a Retrospective says which hurts most. Teams that customize all nine at once get a process nobody understands and no way to tell which change helped.

Is Scrum still the right framework if agents write most of the code?

Scrum’s subject has always been the complexity of deciding what to build and learning whether it worked, so agents taking over generation shrinks the part Scrum had least to say about and enlarges the part it exists for. There is a caveat. Scrum as most teams practice it, with story-level backlogs and task-level planning, will feel wrong immediately. Raising the altitude of the backlog and the planning conversation resolves that.

Do we still need Sprints if we can ship continuously?

Continuous delivery and Sprints have coexisted for over a decade. The Sprint is a cadence for goal-setting and inspection, and it keeps a team from drifting from one buildable thing to the next. Release daily if you can, and still hold a Sprint Goal that says what all that releasing was supposed to achieve.

Who owns the specification, the Product Owner or the Developers?

The Product Owner owns what problem is worth solving and how success will be recognized. The Developers own how the specification expresses that so agents can execute it reliably. In practice the two write it together during refinement, the same collaboration that used to happen around acceptance criteria, with higher stakes because the spec drives generation directly. When a Product Owner writes specs alone, the team has recreated requirements handoff with better tooling and should expect the failure modes that came with it.

How do we run a Sprint Review when the Increment is mostly generated?

Present the sum of the Increments, as the Guide says, because empiricism depends on it. Then change what you open with. Lead with data on what real users did with the parts that already reached them. Treat that evidence as the spine of the conversation rather than an appendix to the demo. The parts still sitting behind a release constraint get shown too, but they get shown as a queue problem with a named owner, since the Sprint Review was never the gate on releasing value.

The 2020 Scrum Guide made it explicit that the framework is purposefully incomplete and leaves the rest of the design to you; the AI age is the moment that gap stopped being safe to leave unfilled.