Agentic engineering does not kill Scrum. It kills the parts of Scrum a small team was already faking, sprint capacity as a fixed number, story points as a unit of truth, and it makes the one artifact most teams treated as a checkbox, Definition of Done, into something an agent-heavy team genuinely cannot skip anymore.

That's the opposite of what most "is Scrum dead" takes argue. Those pieces, and there are a lot of them, mostly predate AI coding agents entirely or ignore them. They're about consultant fatigue with ceremony, not about what changes when an agent can implement, test, and open a pull request for a feature in the time it used to take to write the ticket.

Where agentic engineering moved the constraint

For fifteen years, the standard software team's bottleneck was writing code. Product decided what to build, and engineers were the scarce resource that turned decisions into working software. Scrum's whole apparatus, sprints, story points, velocity, exists to manage that scarcity: estimate the work, size the team's capacity, plan two weeks at a time.

Anthropic's own 2026 Agentic Coding Trends Report states this plainly: "software development is shifting from writing code to orchestrating agents that write code." That's not a marketing line, it's a direct description of where the actual constraint moved. Writing code is no longer the scarce step for a team using coding agents well. Deciding what's worth building, specifying it precisely enough for an agent to act on, and verifying the result are.

That reordering breaks the specific mechanics Scrum uses to manage the old constraint, not the underlying goal-build-inspect-adapt loop itself. It's the same shift already reshaping how the senior engineer role itself is changing, from writing code to directing and reviewing the agents that write it, just applied to the team's process instead of one person's day-to-day work.

What actually breaks

Three things stop making sense once an agent, not a person, does a growing share of implementation:

Sprint as a fixed execution container. A two-week box exists to synchronize human capacity with product cadence. If one developer on a small team can run two or three agents in parallel, against separate branches or worktrees, on a genuinely well-specified task, the same person's real output can swing by a large multiple depending entirely on spec quality and available context, not on the calendar. A fixed two-week box stops being the natural unit of planning.

Story points and velocity as capacity units. Story points were always a proxy for how long a human would take. They were never a great proxy, most teams already knew this, but they held up well enough to plan around. They stop holding up at all once the same ticket can take an agent minutes or an afternoon depending on how much context and how tight a spec it was given, a variable that has nothing to do with the ticket's inherent complexity.

Individual task assignment as the unit of work. "Assign this ticket to Alex" assumes a person does the work personally. On a team where the person's real job is writing the spec, picking the right context, and reviewing what an agent produced, the meaningful unit of work is closer to an outcome one person is accountable for orchestrating, not a task one person executes by hand.

None of this is specific to enterprise transformation theory. It's specific to a two-to-eight-person team where one or two people can now genuinely direct several agents each, which is exactly the scale where the old sprint-capacity math breaks fastest.

What survives, and why Definition of Done gets harder to skip

Here's the part most "Scrum is dead" content misses entirely: Definition of Done doesn't get less important with agents in the loop. It gets load-bearing in a way it usually wasn't before.

GitHub built an open-source toolkit, Spec Kit, specifically around this shift, and its own framing is worth quoting directly: the team behind it describes moving "from 'code is the source of truth' to 'intent is the source of truth.'" Spec Kit structures work into four phases, specify the outcome and success criteria, plan the technical constraints, break the plan into reviewable tasks, then let an agent implement against that spec. The specification isn't a ticket description a human skims before writing the real logic themselves. It's the actual interface between what a person wants and what an agent builds.

That only works if "done" is checkable by something other than a person's judgment call. A vague Definition of Done, "looks good," "seems to work", was always a weak spot in traditional Scrum, but a human implementer usually caught the gaps a checklist missed, out of familiarity with the codebase if nothing else. An agent doesn't have that familiarity by default. If Definition of Done isn't specific enough to check mechanically, tests pass, the relevant security check runs clean, no known regression, an agent-heavy team has no reliable signal that anything actually got built correctly.

So the practical shift is this: Definition of Done stops being a shared understanding among people who've worked together for years and starts being a machine-verifiable contract, written down precisely enough that both a person and an agent can check it the same way.

What a small team actually does differently

For a team this size, the changes are concrete, not organizational theory:

• Keep the Product Goal. If anything, it matters more. An agent without a clear goal produces a large volume of plausible-looking, wrong software very quickly, faster than a person would, and with less obvious signal that it's off track.
• Drop story points and velocity. They were measuring human throughput. Human throughput isn't the constraint anymore, and tracking a number that no longer maps to anything real just adds overhead.
• Rewrite Definition of Done as something an agent (and a CI pipeline) can check, not something only a person can judge. Specific, automated gates: tests pass, security checks pass, no regression against a named baseline. This is the single most valuable change a small team can make.
• Stop assigning individual tickets and start assigning outcomes. One person orchestrating three agents toward a specific, verified result is a more accurate unit of work than "assigned to Alex" ever was, and it's the same shift in what actually separates scope from skill at any career stage, just compressed into a single sprint instead of a multi-year promotion track.
• Keep retrospectives, change the question. Instead of asking why a ticket took eight days, ask why an agent needed several iterations to get a change right, and what context or spec gap caused it. That's a genuinely more useful diagnostic than the old version, not a weaker one.

Dropping story points and velocity still leaves a real question: what do you point to instead when someone asks whether the team is actually moving? The better replacements are outcome-based, not effort-based. DORA's research has tracked delivery performance for years using metrics like change lead time (how long from a ready spec to a verified deploy, not from ticket creation to ticket close), deployment frequency, and change fail rate, and they hold up better here than story points ever did, because they measure what actually shipped and how often it broke, not how much effort a human guessed a task would take. The same logic applies to the sprint box itself: replace the fixed two-week container with a rolling flow, ship and verify as each spec clears its Definition-of-Done gate, and keep a short, regular checkpoint, weekly is enough for most teams this size, to review what actually landed and reprioritize, instead of batching every decision into a boundary that no longer matches how fast the work moves.

This isn't a wholesale replacement methodology, and it doesn't need a new name. It's the same Goal → Build → Inspect → Adapt loop Scrum was always built around, with the mechanics that assumed a human wrote every line stripped out, and the one mechanic that assumed a human would catch ambiguity by instinct made explicit instead.

The real answer to "does agentic engineering kill Scrum" is that it kills the parts your team probably already resented, and it turns the part your team probably already half-skipped into the one thing you genuinely can't skip anymore. That's not a worse trade. For a small team, it might be the first version of Scrum that actually matches how the work gets done.