This is probably a controversial answer but it might solve your problem.
A backlog is a very useful tool. I think one of the most powerful ways to think about a product backlog is that it represents a certain amount of work that your product team has committed to do in the near future. Emphasis on committed and near future.
While I understand how you can end up with a huge backlog …
- Stakeholders insist on getting something into the backlog – instead of acknowledging that it is already full with better ideas and not even those will get finished until next year.
- People underestimate the cost of having more tickets in the backlog — ideas are cheap. implementation & management time is not.
- They call it 'icebox' and pretend it's not the product backlog — even though they treat it like a product backlog.
… I believe it does not make much sense to manage a backlog that goes far beyond the near future (or what you can commit to do on good conscience). It's not only stressful it has major management implications.
You can only do a few things at a time so the amount of things that you 'could do' will always be several magnitudes bigger than the amount of things that you are currently working on.
If you stuff all of these 'other' things which you are not working on right now into a backlog then making efficient decisions will become very hard going forward.
The more tickets you have in your backlog the more 'inventory cost' you accumulate. Tickets in the backlog need to be re-prioritized, groomed, explained (how else would you prioritize them?) on a regular basis. This leads to management overhead that otherwise could be avoided
On top of that in the meantime the market changes, positioning changes, strategic decisions change. So you'll do a lot of busywork without creating much economic value. Also it's easy to loose the wood for the trees when you are wading through a ton of tickets that someone sometime thought is a good idea.
Strategic Advantages of short Backlogs
To work around this I think it makes a lot of sense to put a work-in-process limit on your product backlog. How about fewer tickets than the next sprint? If the backlog is full, you can't add to it. Simple as that.
Or how about a more radical idea … how about we throw the backlog out of the window? Might sound crazy at first. But try it for a few weeks and see how it goes. Fill the new sprint on demand or if you use a Kanban board decide what to work on next just-in-time when space frees up.
This way you can delay the decision about what to work on next for as long as possible. This way you get free information about the market and how people use your product as a side-effect. In product management you always know more today compared to a few weeks ago. Make use of that fact.
Replace the Backlog with a Roadmap
That said it makes a lot of sense to plan ahead. Product strategy is important for setting the direction and aligning your team. I'd just recommend that you do this in your product roadmap instead of a fine-graned backlog or ticket management system.
Many teams I know use google docs, text files or other free-form tools. When you think about product strategy on a higher abstraction level than a backlog it enables you to make better trade-offs. Also the content is usually easier to change and easier to understand for other stakeholders.
The advantage of keeping your backlog very slim is that you have more time to decide what actually ends up in the next sprint(s) instead of drinking from a firehose.
All in all I believe backlogs that are growing so big that you need a management tool for them are an indicator for too much inventory.
There are a lot of systems that are specialized for tracking bugs, user feedback, inspirations, bookmarks and ideas to help you not forget. All these things don't need to end up in your backlog automatically.
You might also be interested in my blog post on product management anti-patterns:
https://www.blossom.io/blog/2013/05/01/product-management-anti-patterns.html