The Backlog Was Longer Than the Build: What Scrum Gets Wrong in the Age of AI

I’ll tell you something most engineering leaders won’t admit out loud: when I first saw what AI could do to software development, my gut reaction wasn’t excitement. It was dread.

I’ve spent over two decades building and leading .NET and Azure development teams. I know what it takes to ship production software — the late nights debugging integration failures, the sprint planning sessions that run ninety minutes over, the painful conversations with stakeholders about why the estimate was wrong. That experience is my livelihood. And suddenly a chatbot was autocompleting the code I’d spent years learning to write fluently.

The question I kept turning over was one I suspect a lot of engineering leaders are quietly asking: Is what I do still going to matter?

I decided to stop waiting for the answer and go find it myself. What followed was one of the most clarifying professional experiences of my career — and it upended some assumptions I’d held about Agile methodology for years.

The Experiment

I decided to build something real. Not a tutorial. Not a proof of concept. A production-grade application I’d actually deploy and use: the Sprint Planning Agent, an AI-powered assistant for Azure DevOps teams that handles retrospective analysis, technical debt prioritization, sprint composition, and code review.

The technology choices were deliberate. .NET 10 for the backend APIs. React and TypeScript for the frontend. The Anthropic Claude API for AI analysis. GitHub Actions for CI/CD. Azure for deployment. This was my stack — familiar territory — but I was going to build it differently. I’d use Claude Code as my development assistant throughout, learning to work with AI tooling on a real project for the first time.

And I was going to run it like a proper Scrum project.

That last decision turned out to be the most instructive one.

The First Revelation: The Backlog Was Longer Than the Build

I approached the project the way I’d approach any professional engagement. Before writing a line of code, I created a product backlog. I wrote user stories. I estimated story points. I set up a sprint in Azure DevOps — which, given that I was building an Azure DevOps tool, had a certain recursive humor to it.

The backlog work took the better part of two days.

The initial build took two days.

Let me be precise about what “initial build” means here: two days from a blank project to a working application with functioning APIs, a connected React frontend, real Azure DevOps integration pulling live data, and AI-powered analysis returning structured output. Not a mockup. Not scaffolding. A working system.

I sat with that for a while.

The entire planning and estimation apparatus I’d set up — the sprint structure, the story points, the velocity projections — had been designed to manage the uncertainty of construction. And construction had just become a two-day activity.

This is the core inversion I’ve been thinking about ever since. Traditional Agile was built around a reasonable assumption: that writing working software is the expensive, uncertain, time-consuming part of delivery. Sprints, story points, and velocity charts exist to manage that construction uncertainty. But if AI compresses construction by seventy to ninety percent, the scaffolding we built to manage it doesn’t automatically become useful somewhere else. It just becomes overhead.

The sprint planning ceremony I’d spent a day preparing for was answering the wrong question. It was asking how long will this take to build? The question I actually needed to answer was what do I need to know before I can trust this?

The Second Revelation: Working Code Is the Starting Point

Here’s what the two-day MVP looked like under the hood: it worked. Every endpoint returned data. The Azure DevOps integration pulled backlog items. The AI analysis produced structured output. The frontend rendered it cleanly.

It also had a prompt injection vulnerability I almost missed — and that was the least of its problems.

The application accepted user input and passed it to the Claude API without adequate sanitization. A malicious user could have crafted input designed to manipulate the AI’s behavior, bypass intended guardrails, or extract information the system wasn’t designed to surface. It’s one of the most common security risks in AI-integrated applications, and Claude Code hadn’t flagged it.

But the security gap was just the most urgent item on a longer list. When I reviewed the codebase with fresh eyes, I found what I’d describe charitably as functional code and honestly as a maintenance liability. Methods were doing too many things. Abstractions were convenient for generation but wouldn’t survive a change in requirements. Dependencies were tightly coupled in ways that would make future modifications painful. SOLID principles — single responsibility, open/closed, dependency inversion — had been largely ignored in favor of the path of least resistance. The code worked. It did not meet any reasonable definition of production quality.

None of this surprised me in hindsight. AI optimizes for correctness in the immediate context. It doesn’t optimize for the long-term maintainability of a codebase it won’t be responsible for maintaining. That’s a human concern — specifically, the concern of an experienced engineer who has lived through the consequences of architectural shortcuts made under pressure.

I caught it because I knew to look for it. Twenty-plus years of building production systems gives you a different kind of attention when you review code. You’re not just asking does this work? You’re asking what happens when someone else needs to change this in six months? What happens when this is under load? What happens when someone tries to break this?

That gap — between working code and trustworthy code — turned out to be where most of the real work lived.

I spent the next week doing what any senior engineer would recognize: restructuring the architecture around proper separation of concerns, building testable interfaces, applying dependency injection to decouple components, addressing the security vulnerability, and writing a unit test suite that validated actual behavior rather than just covering lines. By the time I was done, the codebase I was comfortable putting in front of other engineers looked fundamentally different from what AI had produced in two days.

The AI hadn’t done that work. I had. And here’s the uncomfortable truth underneath it: AI had no incentive to do it. The model that generated the initial codebase had no stake in its long-term maintainability. It wasn’t going to be the one debugging a regression at two in the morning six months later. It wasn’t going to explain to a junior developer why a particular abstraction made sense. It wasn’t going to own the production incident that emerged from a security gap it didn’t flag.

That accountability is irreplaceable. And it’s inseparable from the experience required to exercise it well.

My twenty-plus years of experience didn’t make me faster at building — AI made me roughly as fast at building in two days as I’d been in twenty years. What my experience gave me was the ability to recognize what AI had produced versus what production-grade code actually requires. To know which shortcuts would become technical debt. To apply the architectural principles that make systems maintainable, not just functional. To understand the difference between code that satisfies test cases and code that holds up under real conditions.

AI accelerates execution. Experience determines quality.

The Third Revelation: Scrum Ceremonies Need New Questions

Once the initial build was done and the hardening work was underway, I found myself running sprint ceremonies on a one-person team. It was illuminating in ways I didn’t anticipate.

The daily standup question — what did you build yesterday? — became nearly meaningless. AI had scaffolded most of what I was going to build before I’d finished my morning coffee. The more useful questions were: What did I validate yesterday? What did I harden? What did I find when I actually read the code AI produced?

Sprint planning, which I’d been doing as an estimation exercise, needed to become something else entirely. I wasn’t estimating construction effort — I was assessing risk. The questions that mattered were: What are the failure modes of this feature? What non-functional requirements does it need to meet? What’s the blast radius if the architecture decision I’m making here turns out to be wrong?

Retrospectives took on a dimension they’d never had before. In addition to the standard questions about team process and communication, I found myself asking: Where did AI-generated code introduce unexpected risk? Which AI suggestions did I override, and why? Are my review criteria catching real issues, or am I creating process theater?

The sprint review shifted from “demonstrate that this feature was built” to “demonstrate that this feature is production-worthy.” I found myself preparing evidence of reliability rather than just evidence of completion: test pass rates, load test results, a threat model review, documented rollback procedures.

These aren’t new ideas. Experienced Agile practitioners have argued for years that the Definition of Done should reflect production readiness rather than construction completion, that QA should be a design partner rather than a downstream gate, that sprint reviews should surface reliability evidence not just feature demos. AI doesn’t create these ideas — it makes ignoring them untenable.

When construction is fast, everything that was slow by comparison becomes visible. The bottlenecks that were always there get exposed.

The DORA Signal

One of the more concrete outcomes of this experience was a renewed appreciation for DORA metrics — Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Mean Time to Restore.

In a traditional Agile environment, velocity is the primary throughput metric. Teams optimize for story points completed per sprint. In an AI-augmented environment, velocity loses most of its signal value. If AI can produce an MVP in two days, velocity becomes a measure of how fast I can prompt a model — which tells you nothing useful about engineering capability.

Deployment Frequency replaced velocity in my thinking. Not because deploying frequently is inherently good, but because deployment frequency is a proxy for confidence. A team that deploys frequently has built the infrastructure, the test coverage, the observability, and the cultural trust required to put code in production regularly. That confidence doesn’t come from AI. It comes from the hardening work.

Change Failure Rate is the metric that exposes the gap between fast shipping and safe shipping. During this project I watched my own change failure rate drop as my hardening practices improved — fewer rollbacks, fewer production surprises, more stable deployments. That correlation told me more about the quality of my work than any velocity chart ever had.

What Doesn’t Change

I want to be careful not to overcorrect here, because some of what I’ve described could be read as an argument that Agile is obsolete. It isn’t.

What AI changes is the scaffolding, not the foundation. The foundation of Agile — empiricism, collaboration, continuous improvement, working software over comprehensive documentation — becomes more important, not less, when AI is in the loop.

Stakeholder alignment cannot be automated. AI cannot negotiate scope, surface business risk, or build the organizational trust required to make deployment decisions. The human conversations at the center of Agile remain irreducibly valuable.

Architectural thinking cannot be automated. AI is remarkably capable within a single file or feature scope. It struggles with cross-cutting concerns: system boundaries, data consistency, security posture across services, long-term maintainability. The engineers on a team own the seams of the system — the boundaries between components where the real architectural decisions live. That ownership becomes more important when AI is generating the implementations between those seams.

Psychological safety cannot be automated. Teams need to be able to say “this AI-generated code is not trustworthy yet” without pressure to ship because it was generated quickly. The cultural foundation of Agile — trust, transparency, willingness to surface problems — is a prerequisite for AI-era teams to function safely. A team that treats AI output as done rather than as a starting point will learn from production failures rather than from deliberate hardening. That’s a painful and expensive way to learn.

The Team Archetype That Emerges

The project ended with a team of one — me — having built something I’m genuinely proud to put in front of clients. But I’ve been thinking about what this experience implies for larger teams.

The team that emerges from AI-augmented development is smaller, more senior, and concentrated toward the right side of the delivery pipeline — hardening, architecture, and production readiness — rather than distributed evenly across construction and delivery.

The analogy that fits best is not a factory floor, where Agile’s assembly-line metaphor sometimes led, but a structural engineering firm. A structural engineering firm doesn’t value the speed of laying concrete. It values the judgment of the engineers who determine what is safe to build and sign their names to that determination.

AI-era software teams sign their names to production deployments. That’s a different kind of accountability than shipping sprint demos — and it requires a different kind of team.

Practical Starting Points

For engineering leaders beginning this transition, I’d offer these starting points drawn from direct experience:

Audit your Definition of Done. Ask honestly: does it reflect construction completion, or production readiness? If “done” means the feature works in the development environment, you’re describing the starting point for AI-generated code, not the finish line. Rewrite it to require hardening evidence — test coverage validation, load testing, threat model review, observability instrumentation, rollback procedure documentation.

Replace velocity with deployment frequency as your primary throughput metric. Velocity measures prompting speed in an AI-augmented environment. Deployment frequency measures team confidence. Optimize for the latter and watch what changes.

Restructure sprint planning as a risk assessment exercise. Shift the primary question from “how long will this take to build?” to “what do we need to know before we can trust this?” The output of planning isn’t an estimate — it’s a list of questions that need to be answered before deployment.

Elevate QA into the design conversation. QA engineers who understand production behavior, failure modes, and load patterns are among the most valuable members of an AI-era team. Activating them at the end of development is a waste of their most important capability.

Invest in observability before velocity. Teams cannot responsibly deploy AI-generated code without instrumentation that surfaces production behavior. Observability is not a feature — it is the foundation of deployment confidence.

The Answer to the Question

I started this project asking whether what I do still matters in a world where AI can build software. The answer I found is that it matters more — but differently.

The twenty-plus years I spent learning to build systems didn’t give me irreplaceable speed. AI can match or exceed my construction velocity. What it gave me was the judgment to know what AI misses, the pattern recognition to identify risk, the architectural intuition to make decisions that hold up at scale, and the professional accountability to sign my name to production code.

Those things are not automatable. They’re also not teachable in a bootcamp. They come from the specific kind of experience that involves being responsible for systems when they break, debugging production incidents at two in the morning, explaining to stakeholders why a decision made six months ago is causing problems today.

The anxiety I felt at the beginning of this project was real. It was also pointing at the wrong thing. The question isn’t whether AI replaces experienced engineers. The question is what experienced engineers do with ten times the leverage.

The answer, for me, is to help other teams figure out the same thing.