The Place Where Good Ideas Go to Die
Most product backlogs are graveyards. They start small and useful, then grow over time as feature requests, customer complaints, internal ideas, and engineering wishes pile up. Within a year, the backlog has hundreds of items. Most will never be built. Many were duplicates of existing items. Some describe problems that no longer exist. The team stops looking at the backlog because looking at it is depressing.
This pattern is so common that many PMs treat it as inevitable. It is not. A backlog is a tool. Like any tool, it works when maintained and fails when neglected. The PMs who maintain their backlogs ruthlessly have a real advantage: they can actually find what they need, prioritise quickly, and avoid rebuilding things they already built.
This article is about backlog management as a practice. What should be in the backlog. What should not. How to keep it small enough to be useful. How to handle the constant pressure to add more. And how to run the rituals that keep it healthy over time.
What a Backlog Is For
A backlog is a list of work the team might do. Not work the team will do. Not work that has been promised. A list of candidates. The distinction matters. When teams treat backlogs as commitments, the list grows uncontrollably because nobody wants to remove anything that someone might have wanted.
A healthy backlog serves three jobs:
- 1. It captures candidate work so ideas don't get lost. When someone has a feature request, it goes in the backlog rather than into the PM's memory.
- 2. It supports prioritisation. Picking what to work on next requires a list to pick from. The backlog is that list.
- 3. It communicates direction. Stakeholders looking at the backlog see what the team is considering, what is in flight, and what has been done.
What it is not: a comprehensive list of every idea anyone has ever had about the product. A guarantee that any item will eventually ship. A wishlist where things go to live forever. Treating the backlog as any of these produces the graveyard.
The Three Layers of a Healthy Backlog
We have used a three-layer structure that keeps backlogs useful at scale. The layers correspond roughly to the Now, Next, and Later from the roadmap article.
Layer One: Sprint Backlog
What the team is actively working on in the current sprint. Specific, refined, estimated, with clear acceptance criteria. This layer is small (usually five to fifteen items, depending on team size and sprint length). Items here are committed.
Layer Two: Ready Backlog
Items refined enough to be picked up in upcoming sprints. They have been discussed, they pass INVEST, and they have rough estimates. Maybe twenty to forty items. The team will draw from this layer in the next one to three sprints.
Layer Three: Discovery Backlog
Items the team is considering but hasn't yet refined. Feature requests, customer complaints, internal ideas, competitive observations. These are candidates that need more work before they can be picked up. This layer can be larger (maybe fifty to a hundred items), but it should still be culled regularly.
Layer Items Refinement Time to Pickup
Sprint 5-15 Fully refined, ready to build In progress
Ready 20-40 INVEST passes, rough estimates 1-3 sprints
Discovery 50-100 Brief description, not yet refined 2+ sprints
What is intentionally missing from this structure: a someday layer where items live indefinitely. We recommend not having one. Items that don't make it through discovery should be cut, not parked. Parking creates the graveyard.
What Should Go Into the Backlog
Not everything someone mentions belongs in the backlog. The discipline of saying no (or at least "not yet") at the intake stage is what keeps the backlog small enough to be useful. Some questions to ask before adding an item:
Is This Aligned With the Strategy?
If the item doesn't serve the product's strategy, it doesn't belong in the backlog regardless of how good the idea is. Strategy provides focus. The backlog should reflect that focus, not contradict it. Items outside the strategy should be declined politely with the explanation.
Is the Problem Real?
Many feature requests describe solutions, not problems. Add an export button is a solution. The underlying problem ( I need to share data with people who don't have accounts ) might be real or imagined. Before adding to the backlog, capture the problem behind the request. Items without a clear problem behind them are usually not worth the slot.
Is It Already Captured?
Many backlog items are duplicates of items already there. Before adding, search for similar items. If one exists, link to it as additional evidence rather than creating a duplicate. Duplicates fragment understanding and make prioritisation harder.
Could It Be Solved Without Engineering?
Some requests are better solved by documentation, customer education, sales process, or pricing change. If the item doesn't require engineering, it shouldn't be in the engineering backlog. Route it to wherever it actually belongs.
Is It Specific Enough?
Make the dashboard better is not a useful backlog item. Add filters by date and status to the dashboard so users can find recent items affecting them is. Items that are too vague should either be sharpened or rejected. Vague items dilute the backlog and frustrate refinement.
The Cull: Why It Has to Happen
Backlogs grow. New items arrive faster than items get done. Without active culling, the backlog becomes too large to be useful. The discipline of removing items, even good ones, is what keeps the list functional.
Many PMs resist culling. The item might be useful someday. Someone asked for it. Maybe a customer remembers. Removing feels like betraying the request. So nothing gets removed, and the backlog becomes a museum.
The honest framing: items that have been in the backlog for six months without being picked up are not waiting to be built. They are being forgotten about, slowly. Removing them costs nothing because nobody was going to do them anyway. Keeping them costs the slot, the search noise, and the honesty of the list.
A Quarterly Cull
Once a quarter, review the discovery backlog and cut ruthlessly. Items get cut if any of these are true:
- They have been there over six months without traction or recurring requests.
- They no longer fit the strategy.
- They describe problems that have been solved differently.
- They duplicate other items.
- The original requester no longer cares.
- The product has evolved enough that the request would be different now.
After a thorough cull, the backlog is usually thirty to fifty percent smaller. This is normal and healthy. The team is left with the items that actually have momentum, which is where attention should be.
Communicating the Cull
When cutting items, communicate to anyone who originally requested them. We considered this and decided not to pursue it because [reason]. If circumstances change, we can revisit. Most requesters appreciate the honesty more than they would appreciate the item sitting indefinitely. The communication is also a check: if a requester pushes back hard enough, the cut may have been wrong, and the pushback is the signal.
Refinement: Where Items Become Ready
Refinement is the process of taking items from rough candidates to ready-to-build. Without it, the team will always be working on items they don't fully understand.
The Refinement Funnel
Items move through stages, not in batch. A new item enters the discovery backlog as a rough capture. Over time, if it remains relevant, the PM (often with engineering and design) refines it: clarifies the user need, sharpens acceptance criteria, considers edge cases, gets rough sizing. When refined enough, it moves to the ready backlog. From there it is eligible for the next sprint.
Refinement Cadence
Most teams hold weekly or bi-weekly refinement sessions, usually thirty to sixty minutes. The session covers items the team will likely pick up in the next two or three sprints. Items in the discovery backlog beyond that horizon don't need refining yet; doing so wastes effort if priorities shift.
Just-In-Time Refinement
Resist the urge to refine the entire backlog. Items that are weeks away from being picked up don't benefit from deep refinement now; circumstances will change. Refine items as they approach the front of the queue. Earlier than that is usually waste.
Backlog Items: What They Should Look Like
A useful backlog item has enough information to support prioritisation and just-in-time refinement, without being a fully-specified ticket. Most items at the discovery layer should fit on a single screen.
A Minimal Backlog Item Template
- Title: short and specific. Filter dashboard by date , not Dashboard improvements .
- User and problem: who is affected and what is hard for them today. Two sentences usually.
- Why it matters: the impact if solved, the cost if not solved. Includes any data points (frequency, segment size, support ticket counts).
- Rough sketch of solution: not a final design, just enough that readers know what kind of work is being considered.
- Source: who requested it or what data point surfaced it. Useful when re-evaluating later.
- Tags: theme, area, segment, or other metadata that helps filter the backlog.
Items at the ready layer add: refined acceptance criteria, rough size estimate, and notes from refinement discussion. Items at the sprint layer add: full acceptance criteria, sized commitment, designs if needed, and dependencies.
Pressure From Stakeholders
Stakeholders will push to add items to the backlog. Sales needs feature X for a deal. A customer escalated about Y. The CEO has a personal interest in Z. Saying yes to all of them produces the graveyard. Saying no carelessly damages relationships. The skill is in saying yes when it matters and no when it doesn't, with reasoning that lands well.
Some Useful Responses
- Capture, don't commit. "I'll add it to the discovery backlog. We'll prioritise it against other work in the next planning round." Items in discovery are not promises; they are candidates.
- Ask for the underlying problem. "What is the specific problem the customer is trying to solve?" Often the underlying problem is already addressed by something in the backlog, or solvable without new development.
- Surface the trade-off. "If we add this to the sprint, we need to drop X or Y. Which would you cut?" Most stakeholders, faced with the trade-off, decide their item isn't worth the cost.
- Ask for evidence. "How many other customers have asked for this? What's the revenue impact?" Without evidence, the request stays in discovery. With evidence, it can move up.
- Be willing to say no. "We've decided this doesn't fit our strategy this year. We can revisit next year." A clean no, with reasoning, is more honest than a "someday" that everyone knows means never.
Working With the Team on the Backlog
The backlog is not just the PM's. Engineering, design, and the rest of the team have important roles. Treating the backlog as solely the PM's document misses important input.
Engineering Input
Engineering knows things the PM doesn't: which items will be much harder than they look, which items connect to technical debt, which items would benefit from being done together. They should be involved in refinement and in the ordering of the ready backlog.
Design Input
Designers see usability issues, design debt, and opportunities the PM may miss. Their input on item priority is often different from engineering's, in useful ways.
Engineering-Driven Items
Some backlog items come from engineering: tech debt, infrastructure improvements, refactoring. These items are legitimate and important. They should sit alongside user-facing items in the backlog, with the team making explicit choices about how to balance the two. A common split is to dedicate twenty to thirty percent of capacity to engineering-driven items, depending on the state of the codebase.
Common Mistakes
Mistake One: Treating the Backlog as a Promise
When items in the backlog feel like commitments, removal feels like betrayal. The result is items that linger forever. Reframe the backlog as a list of candidates. Items in discovery may or may not be done. Stakeholders who treat discovery items as commitments need to be reminded that they are not.
Mistake Two: No Cadence
If you don't refine and cull on a schedule, you don't do it at all. The backlog drifts. Set a recurring refinement meeting and a quarterly cull. Make them non-negotiable.
Mistake Three: Refining Too Far Out
Refining items that won't be picked up for six months is waste. Priorities will change. The work will be different by then. Refine just in time.
Mistake Four: Letting the Backlog Be the Strategy
Some teams operate by working through the backlog in priority order. The backlog becomes the strategy. This works in the short term but produces drift over time, because individual prioritisation calls aren't connected to a broader vision. Strategy should drive the backlog, not the other way around.
Mistake Five: One Big Pile
Backlogs without layers (just one big list, sorted by priority) become unmanageable above about fifty items. The discipline of layering forces decisions about what is near-term, what is mid-term, and what is candidate. Without the layers, everything blends together.
Mistake Six: Not Communicating What's in the Backlog
If stakeholders don't see the backlog, they keep submitting the same requests. Make the backlog visible (with appropriate access). Show that requests are captured. This reduces noise and builds trust.
A Final Word
Backlogs are easy to start and hard to maintain. The skills of capturing, refining, prioritising, and culling are learned over years. The PMs who maintain healthy backlogs have a structural advantage: they can find what they need, make decisions quickly, and avoid the slow erosion of focus that the graveyard backlog produces.
If you have a graveyard backlog right now, take an afternoon and do a heavy cull. Cut anything older than six months unless it has clear momentum. Layer the remainder into discovery, ready, and sprint. Set up the cadence. Communicate the changes to stakeholders. Within a quarter, the backlog will start being useful again. Within a year, the discipline will feel automatic, and the team will have more focus and less noise than they did before.
Key Takeaways
- A backlog is a list of candidates, not commitments. Items in it may or may not be built. The framing matters because it allows removal.
- Layer the backlog: sprint (active), ready (refined for upcoming sprints), and discovery (candidates). Each layer has its own size limits and refinement levels.
- Cull quarterly. Items older than six months without traction get cut. The cull keeps the backlog small enough to be useful and honest about what will actually happen.
- Refine just in time. Items more than a few sprints out don't need deep refinement; doing so wastes effort if priorities shift.
- Capture without committing when stakeholders push. Surface trade-offs. Be willing to say no with reasoning. The skill of saying no kindly is what protects the backlog's usefulness.