A product owner I’m coaching recently pushed through the hard part of a backlog overhaul. They organized a sprawling pile of stories into features, put the features in a rough order, and got the whole thing back to where they could reason about it.
Then they hit the question that stalls almost every backlog cleanup: “There are still stories that should probably just be deleted because they’re old, stale, or no longer relevant. But it’s difficult to throw away groomed stories. We keep finding ourselves saying, ‘But what if we need that later?'”
This is a common problem. Adding to a backlog is nearly frictionless in every tool. Deleting from one feels like throwing away work, especially when somebody spent time refining the story.
Here’s the principle I shared with this PO:
Everything on your backlog should be reasonably likely to make it to the top within the amount of time implied by its position in the backlog.
In other words, backlog items shouldn’t just sit there. They should be consistently, steadily moving up the backlog and getting refined as they go. Items aren’t on the backlog “just in case” or “so we don’t forget.”
Why so strict? Because, as I’ve written before, items on a backlog function as implicit commitments to do the work at some point. Your stakeholders read them that way. So does your own subconscious. And we should avoid making commitments we don’t intend to keep. It’s bad for our psychology and bad for our relationships.
There’s nothing wrong with capturing ideas, possibilities, and options. *They just shouldn’t go on the backlog.*
Your Behavior Already Shows Which Items Are Stale
You don’t need a long series of meetings to figure out which items to remove. You’ve been voting with your behavior. (To be clear, not just you, but you and the organizational system around you. Your collective behavior reveals which items are actually unimportant.)
Look for stories that have been on the list longer than two months and are sitting more than two sprints down the backlog. Those stories haven’t been moving up. Whatever anyone says about how important they are, your actual behavior indicates they’re not going to get completed any time soon. The same goes for features that have been on the list longer than four or six months and are sitting more than three months out.
That’s your stale list. No debate required.
(Feel free to adjust these heuristics either direction based on your context. Some teams naturally have shorter or longer backlogs at each level of detail.)
Keep the Idea, Drop the Commitment
So what about “what if we need that later?”
Moving a story off the backlog doesn’t erase the idea. It ends the implicit commitment. Create a separate list, call it something like “Ideas as of August 2026” or “Someday/Maybe” or even “Don’t You (Forget About Me),” and move the stale items there. You haven’t lost anything. You’ve just stopped treating those items like work you’ve committed to do.
If your whole backlog is full of items that fail the reasonably-likely-to-reach-the-top test, do this wholesale. Rename the current backlog to the ideas list, then build a new backlog from the top down with only the work you actually intend to do.
One more thing about those refined stories. If deleting them hurts because of all the refinement effort they contain, that’s useful information: the refinement happened too early. Refining a story is only valuable when the story is actually going to get built soon. Our PO Board model shows how to structure a backlog so items get just enough detail, just in time, and you never again face a pile of fully refined stories that will never ship.
Want help setting up a backlog your team and stakeholders can actually trust? Visit our contact page and schedule a free discovery call.
Last updated