Rotting Backlog: Clean It Without Losing a Day

Why your backlog is rotting (and it's not your fault)

A backlog always starts clean. Twenty items, a team that knows why each one is there. Then it grows. At 200 items, it becomes painful. Beyond 500, it becomes a liability.

The problem isn't the volume. It's that everything sits at the same level. An authentication migration and a button color change end up side by side, fighting over the same priority slot. As a Head of Product quoted by ProdPad put it, his backlog had become “a graveyard with a search bar”: more than 400 items accumulated over two years, all tagged “ideas.”

When everything is flat, three pitfalls come back systematically:

• Prioritization by volume. The item with the most votes or the loudest advocate wins. A minor UI friction mentioned ten times jumps ahead of an architecture decision that no one outside engineering understands.
• Recency bias. Whatever was discussed most recently feels most important. The backlog becomes a queue, no longer a strategy tool.
• False equivalence. The same RICE scoring is applied to everything, as if the “Reach” of a platform migration meant the same thing as that of a tooltip. The number gives an illusion of rigor, but the inputs aren't comparable.

The good news: you don't need a three-hour meeting to fix this. Three short passes, repeated regularly, are enough.

Pass 1 — Delete: 20 minutes, no debate

Goal: remove everything that will never be done. Simple rule: if no one can name a concrete user or objective this item serves, it goes.

Concretely, you delete:

• Items created more than six months ago, never prioritized, that no one remembers.
• Ideas copy-pasted from a Slack thread, with no context or identified problem.
• The “we should maybe…” items with no owner and no deadline.
• Disguised duplicates (we'll come back to those in pass 2).

Don't try to archive neatly. Delete. If the idea was good, it will come back — and this time with a real problem behind it.

In a tool like Ever Earlier, this pass is mechanical: you filter by creation date and by absence of priority, you bulk delete. No meeting, no Excel spreadsheet to maintain.

Pass 2 — Merge: spot duplicates and group them

After deletion, there are often items left that describe the same need from three different angles. That's normal: three people ran into the same problem at three different times.

Merging happens at the level of the problem, not the solution. Two items that propose different solutions to the same problem become one.

A concrete example. Three separate items:

• “Be able to see who modified a card”
• “Change history on a task”
• “Know when a story was moved”

One single problem: traceability of changes. One single user story after merging, with a clear acceptance criterion: “As a project manager, I see the chronological list of changes to a card, with author and date, to understand what has changed since my last visit.”

In Ever Earlier, the activity log already covers this need on the tool side — but the exercise holds for your own backlog. One merged story, with priority, points, and acceptance criteria, replaces three vague items. You cut the noise by three.

Pass 3 — Prioritize: value first, size second

Now you're left with items that deserve a decision. Two questions, in this order:

1. What value? Who is impacted, how many, and how much? If you can't answer in one sentence, the item isn't ready — it goes back to discussion, not to a sprint.
2. What size? A 13-point story that's been sitting around for three sprints isn't a story, it's a project in disguise. Break it down.

This is where structured user stories save time. A story with priority, point estimate, and acceptance criteria can be judged in thirty seconds. A story without those elements triggers a ten-minute discussion at every planning session.

A useful principle, drawn from the theory of constraints: don't overload the bottleneck. If your team merges or ships 20 to 35 items per month, an active backlog of 200 items represents about 6.7 months of average waiting time. That's not a temporary backlog, it's what the system produces at that load. Reducing work in progress is more effective than adding reviews.

Refactoring doesn't go into the backlog

A classic temptation after a big cleanup: add “refactoring stories” to catch up on technical debt. Ron Jeffries explains why that's a bad idea: asking the product owner for time to fix what you yourself broke is hard to sell, and the result disappoints — you clean what you can see, in the time you have, never enough.

The right approach is simpler: with each new feature, you clean the code you pass through. You don't detour around the brambles, you clear some of them. Sometimes the feature takes a little longer. Often it doesn't, because the cleanup helps from the very first feature that goes through there.

The consequence for your backlog: don't put “refactoring” lines in it. Put features in it, and let the cleanup happen inside.

Cadence matters more than depth

A 20-minute pass every two weeks is better than a three-hour session every six months. The backlog doesn't get dirty all at once, and it doesn't get cleaned all at once either.

Three rules to keep it up:

• One pass, one goal. Deleting means deleting. You don't prioritize while you delete.
• One owner per pass. Usually the product manager or the project manager, not the whole team.
• A tool that doesn't add friction. If cleaning the backlog takes more effort than filling it, you won't do it.

In Ever Earlier, user stories with priority, points, and acceptance criteria make this pass fast: you immediately see which items are ready, which are vague, which no longer make sense. The backlog and the sprints live in the same place, so you don't duplicate anything.