Two years ago your team's backlog had about two hundred items in it, and everybody said you'd get to them. But now, with AI writing a good share of the code, the team closes more tickets than ever, and the backlog has six hundred. And if you ask which of those six hundred still matter, chances are nobody can tell you.

Most of us look at a growing software backlog as work that's waiting its turn, but I think for the most part it's something else. A backlog item nobody plans to start isn't work waiting. It's a decision nobody made. And a pile of those does three kinds of damage, the first of which is the easiest to miss because you can't see it.

The Pile Hides What Matters

I ran into this with my own tracker this month. I build DevNitro with AI agents, and each agent run ends by leaving its issues in an "in review" column so a person can check them. That person is me, and sometimes I'd review an issue and forget to close the loop, and sometimes I'd forget to review it at all, so the column turned into a pile.

So on September 15 I gave one agent a job. I told it to read every issue in review, open the code to check that the work was really there, close the ones that were done, and tell me about the ones that weren't. That took about fifteen minutes of my time, and then the agent worked for about an hour.

When it finished, it had closed 86 issues, because every one of them was already done. But it also found two critical items that were marked for review and had never actually been finished, plus a few smaller ones. Those two were what really mattered in that column, and I couldn't see them because they were sitting in the same pile as 86 that didn't need anything from anybody. So I had it spin off agents to go finish them.

A big backlog works the same way. The handful of items your business really needs are sitting in the same list as hundreds that nobody is going to start, and from the outside they all look alike.

Every Ticket Is a Yes Nobody Said

Now, when someone in sales or support asks for a feature and it goes into the backlog, they probably walk away thinking it's coming. Nobody actually told them yes, but nobody told them no either, so the ticket feels like a yes to them.

To be fair, putting it in the backlog is kind of the polite thing to do, because it lets everybody skip a hard conversation. But that's also why the backlog keeps growing. And now that an AI tool will write a full ticket from a single sentence, tickets cost almost nothing to make, so the pile grows faster than it ever has.

So a year later, when that same person asks where their feature is, "it's in the backlog" sounds a lot like a promise somebody broke.

The Number Measures Ideas, Not Work

Then the size of that pile gets reported up. A leader sees six hundred items and reads it as six hundred items of work the team owes, so of course the team looks slow.

However, that number goes up every time anyone has an idea, not every time the business decides to do something. So it tells you a lot about how many ideas people have had, but almost nothing about what your team actually has to do next.

Two Lists, Not One

All that to simply say this: keep your ideas out of the backlog.

I personally keep a parking lot. When I have an idea, I put it in the parking lot, and it only comes out of the parking lot and into the backlog when it's been decided that the work should actually be done. That way your backlog is your plan, and it's the only list you report as work.

Does that mean the parking lot is where ideas go to die? Not at all. Ideas are good, and you want somewhere to put them, but you want them waiting somewhere that doesn't look like work. So when someone asks about their idea, you can tell them it's in the parking lot, and that doesn't sound like a promise the way "it's in the backlog" does.

This post won't get into cleaning out a backlog that's already too big, because that's a topic of its own. Fortunately, you don't have to fix the whole pile to get started. Just make sure new ideas go to the parking lot, and count only the backlog as work.

If you lead the team, ask to see the backlog, not the parking lot. A list of work somebody decided to do is something you can actually plan around, and the two items that matter are a lot easier to find in it.

What's sitting in your backlog right now that everybody knows is never going to get started? I'd like to hear about it in the comments.

Where This Fits in Intelligent Engineering

Intelligent Engineering is the operating model for engineering organizations in the AI era. It is what comes after vibe coding.

In Intelligent Engineering, work runs from the backlog, so every developer and every AI session starts from what the team has decided to do next. That only works when the backlog really is a plan. So a backlog that holds only work somebody decided to do is one you can hand to people and agents alike, and get back software your team can trust, support, and scale.

Chad Carter is the creator of DevNitro, the Intelligent Engineering platform. He's spent 29 years building software, served as CTO at multiple companies, and was a Microsoft MVP from 2009-2019.