Scrum Just Trained Your Replacement

Here’s an uncomfortable thought: if your development process is designed around breaking work into tiny, prescriptive Jira tickets with detailed acceptance criteria and step-by-step instructions — you’ve spent the last decade building the perfect training dataset for AI.

And it’s about to use it.

The assembly line

I’ve worked with offshore teams. Plenty of them. And in that world, Scrum works exactly as designed. You break work into small, well-defined tickets. You have daily stand-ups to track progress. You write detailed acceptance criteria so there’s no ambiguity. Managers feel in control. Developers get hand-holding. The machine turns.

Let’s be honest about what this is: it’s an assembly line. The methodology exists to make interchangeable units of labour productive in a system where context is expensive to transfer and trust is hard to establish remotely. It’s not about agility — it’s about control.

And that’s fine. Assembly lines produce results. But they also produce a very specific kind of work: small, well-scoped, repeatable tasks with clear inputs and expected outputs.

Sound familiar? That’s exactly the kind of work that AI is getting frighteningly good at.

AI loves your backlog

Take a typical sprint’s worth of Jira tickets. The kind you’d hand to a junior developer or an offshore team:

• “Add validation to the email field on the signup form”
• “Create a REST endpoint for fetching user preferences”
• “Write unit tests for the billing calculation module”
• “Update the Terraform module to add a new security group rule”
• “Fix the pagination bug on the search results page”

Every one of these can be done by Claude or ChatGPT today. Not perfectly, not every time — but well enough. Feed it the codebase context, the ticket description, and the acceptance criteria, and it’ll produce a pull request that passes your CI pipeline and looks like it was written by a competent mid-level developer.

Same PR reviews. Same pipelines. Same effort writing the tickets. Only difference? No stand-ups. No timezones. No cogs.

The ticket treadmill

Here’s the irony. Scrum was supposed to be about agility — the values laid out in the Agile Manifesto back in 2001: responding to change, empowering teams, delivering value iteratively. Instead, most organisations turned it into a ticket factory. The backlog became the product. Velocity became the metric. And the entire development process optimised for throughput of small, prescriptive work items.

That optimisation had a side effect: it systematically eliminated the need for developers to think about the bigger picture. The thinking got pushed up to product owners and architects. The developers became executors. The tickets got smaller. The acceptance criteria got more detailed. The daily stand-ups got more granular.

Every step in that direction made the work more automatable. Not by design — but by consequence. If you’ve spent years refining your process to ensure that anyone can pick up any ticket without context, you’ve also ensured that anything can pick up any ticket without context.

The teams that don’t need Scrum

Now consider the other kind of team. The high-performing ones. The ones where engineers understand the domain, own the architecture, make trade-offs, talk to users, and ship whole features — not individual tickets.

These teams often use some flavour of Scrum or Kanban, but loosely. The board is a coordination tool, not a management framework. The stand-up is a five-minute sync, not a status report. The tickets are reminders, not instructions.

These teams can use AI differently. Not as a replacement for developers, but as an amplifier. The engineer understands the problem, designs the approach, and uses AI to accelerate the mechanical parts — generating boilerplate, writing tests, exploring implementation options, drafting documentation.

In this model, Scrum stops being theatre. It becomes orchestration. Humans conduct. Machines deliver.

The uncomfortable split

This creates a split that most organisations aren’t ready to talk about:

Teams that work like assembly lines — small tickets, detailed specs, interchangeable developers — are directly in the firing line. AI can do that work. It’s getting better at it every month. The economics are inevitable: why pay a team of developers to execute prescriptive tickets when AI can do it faster and cheaper?

Teams that work like product teams — owning outcomes, making decisions, exercising judgement — will become more productive, not redundant. AI gives them leverage. A senior engineer with good AI tools can do the work of a small team, but only if they have the context, judgement, and domain knowledge to direct the work.

The difference isn’t technical skill. It’s whether the human adds something that AI can’t: understanding the problem, making trade-offs, exercising judgement, and taking responsibility for the outcome.

What this means for your team

If you’re a leader, look at your development process honestly:

• Are your tickets instructions or intentions? If a ticket reads like a step-by-step recipe, AI can follow that recipe. If it reads like a problem statement, you still need a human to figure out the approach.
• Do your developers understand why, or just what? If they need detailed acceptance criteria to know what “done” looks like, that knowledge lives in the process, not the person. AI can work from process.
• Would your stand-up work with AI team members? If the answer is yes — if the meeting is just status reporting on small tasks — you’ve built a process that doesn’t need humans.

None of this means Scrum is bad. It means that the way most organisations practice Scrum — as a control mechanism for prescriptive work — has an expiry date. The methodology that was designed to manage human limitations has accidentally defined the exact shape of work that machines can do.

Humans conduct, machines deliver

The future isn’t AI replacing developers. It’s AI replacing the kind of work that shouldn’t have needed a developer in the first place. The ticket treadmill. The boilerplate. The “could you just” tasks that eat 60% of a senior engineer’s week.

What’s left — the design, the trade-offs, the judgement calls, the domain understanding, the “this is a bad idea and here’s why” conversations — that’s the work that matters. That’s what you should be hiring for. And that’s what no amount of Scrum ceremony will teach an AI to do.

Give it six months. Then look at your backlog and ask yourself: which of these tickets actually needs a human? If the answer is “not many” — Scrum didn’t fail you. It just trained your replacement.