Most long-running products have a backlog nobody has read in full. It contains requests from customers who have left, bugs in features that no longer exist, and ideas whose context is entirely lost.
It is maintained on the theory that something valuable might be in there. In practice its size is what prevents anyone from finding it.
Volume destroys prioritisation
Prioritising twenty items is a discussion. Prioritising eight hundred is impossible, so what actually happens is that recent and loud items get worked on and the rest function as an archive.
The backlog has stopped being a plan and become a place where requests go to be acknowledged.
Old items are actively misleading
A three-year-old ticket describes a product that has changed, a user need that may have moved, and reasoning that is no longer recoverable. Acting on it without re-investigating is frequently worse than not acting at all.
Age is genuine evidence: an item nobody has prioritised in two years is being decided against, repeatedly, without anyone saying so.
Closing is a decision, and that is fine
The reluctance to close items comes from treating closure as a promise broken. It is more honest than an indefinite queue that implies something will happen.
Close with a reason. If the need returns, it will be raised again with current context, which is better information than the original ticket.
Keep the top short and the rest coarse
Detail the next few weeks properly. Keep everything beyond that as broad themes rather than specified items, because specifying work you may never do is effort spent on a guess.
Expire anything untouched past a threshold automatically, and let the genuinely important things be re-raised.
A short backlog that reflects real intent is a planning tool. A long one is a filing cabinet that costs meeting time every fortnight.