The best backlogs are short
Most teams treat the backlog as a list of everything they will eventually build. Every idea from a client meeting, every "nice to have" from a stakeholder, and every half-formed thought from a refinement session ends up there. Nothing is lost, and that feels responsible.
In reality, a backlog that keeps everything is a backlog that decides nothing.
Look at a backlog with hundreds of items. The top twenty are reasonably clear. Below that, tickets get older, descriptions get thinner, and many were written by people who have since moved to other projects. Nobody reads them, yet they still carry a quiet promise that one day they will be done.
That promise has a cost. Product Owners spend refinement sessions scrolling past work that will never happen. Developers lose sight of what actually matters right now. Stakeholders see their request "in the backlog" and assume it is planned, when in truth it is simply stored.
A long backlog also hides the most important decision a team makes: what not to do.
Good teams treat the backlog as a short list of the things they currently believe are worth building, in order. Anything further away than a few sprints is kept as a rough theme, not as a detailed ticket. When an item has sat untouched for months, they close it rather than push it down again. If it matters, it will come back, usually with better context than it had the first time.
This can feel uncomfortable. Closing a ticket can look like ignoring someone's idea, and stakeholders sometimes push back. That is exactly why it should be done openly. Saying "this is not something we plan to build" is clearer and more respectful than letting a request sink quietly to the bottom of a list nobody reads.
There is nuance, of course. Some teams need a place to collect ideas, and some products have long-term commitments that must stay visible. A separate idea list or a simple roadmap usually serves that purpose better than a backlog full of tickets. The backlog itself should stay close to the work.
A short backlog changes the conversations around it. Refinement becomes about understanding the next few items properly rather than discussing many that will never start. Priorities become visible at a glance. New team members can read the backlog and understand where the product is heading.
The same principle shows up across good software work. Clear code leaves out what is not needed. Good architecture leaves out what the system does not have to do. A good backlog is no different.
If your backlog disappeared tomorrow, which items would anyone actually ask to bring back?
A backlog is not a memory. It is a decision.
