Your Backlog Is Rotting

~610 Words | ~3min Read

How deep is your backlog? Most teams typically keep two or three sprints of ready work in their backlog. Enough to avoid starvation, not so much it goes stale. But they almost always have a few ideas in the eventually pile. That was a sensible balance when implementation was the constraint. But what happens when AI compresses your twelve-month backlog into weeks?

Backlog items rot. Just like food. We captured them based on a market reality at the time. Meanwhile, reality moves on. The longer those backlog items sit, the less valid they become. Most teams could tolerate this. Implementation was slow enough that ideas on the top of the backlog stayed fresh. And the others kept getting pushed to the back of the fridge. And we’d reexamine them just before starting implementation. But AI has compressed much of the labor in implementation. Features that used to take months now take days. The bottleneck has shifted from coding velocity to the capacity of absorb change. In plain language, your team can now ship faster than your organization can decide what is worth shipping.

Now, the business never paid you, the developer, for the code. They paid for the new behaviors, “verbs”, your code gave them. Code was instrumental, not fundamental, to their goal. Now that AI can generate the instrument faster than you can review it, the value has moved upstream. The valuable work is knowing which behaviors are worth building, and how to build them.

So your backlog is not a pantry. It is a fridge full of leftovers, and some of them are years old. AI-accelerated teams are like hungry teenage boys with a spare stomach! They will clear the shelves fast, and they need different kinds of food to stay healthy. You might try to several things to mitigate this. You could simply chew through the backlog top to bottom. You could let them jump on some of those oldest items. But if you do, you may ship work that made sense three years ago but does not match the market today. Obviously, we want to do a sniff-test first.

But oddly we can find some decent advice from the 60s, specifically from Peter Drucker. He warned that what one postpones, one actually abandons. He was talking to executives in the 60s when he said this. But the fact remains. Work that made sense then, may not make the same sense now. Apply that principle to your backlog. Anything older than your current planning horizon is slowly aging. So… is it still worth eating today?

This is not a new problem. It’s an old one dressed up in new technology. The same disciplines that help teams manage flow still apply. The constraint simply moved. We still need to manage work interruptions, and bugs etc. But now the chief question is different. Can your discovery and validation stages keep up with your implementation stage?

Here are the lessons that still apply: Focus on throughput, not batch size. Create visibility first. Observe before you tweak. And remember that your backlog comes with some dated assumptions. Sniff-test first!

We need system-level changes, not just work changes. Quarterly planning cycles assume requirements age gracefully. That assumption isn’t as true anymore. Consider asynchronous discovery, smaller experiments, and strike teams with smaller budgets. These may replace the old feast-and-famine rhythm.

The goal is not a deeper backlog. It is a faster pipeline of worthwhile, high-quality experiments. We don’t need to ask whether your team can ‘implement’ fast. With AI, Code flows swiftly. But is it code that matters? Was it worth buying? And can you keep coming up with experiments to feed the backlog?