Cut your backlog.
Your backlog is too long. You know it, your team knows it. There are things in there from two years ago, collecting dust, feeling neglected. Issues that may or may not have been fixed, long forgotten festering in the unprioritized dungeon of your backlog. Delete them.
"As a database, I would like to support Acme Standard ZXY 2.17-3" No value, no stakeholder. What does ZXY 2.17-3 do? What does that even mean? Delete it.
Product Managers often use the Backlog as a notepad. A place to jot down tasks before they slip from consciousness into a vaguely nagging feeling of necessity as you grab a soda. Stop. Realize that every item in your backlog has to be sorted, and you are a human bubblesort - so inefficient your primary purpose is to show computer science students how not to sort lists. The fewer stories you have, the more meaningful they can be.
Task management systems like Getting Things Done encourage getting everything out into one place to deal with later. Your backlog is not one of these things. Having a large backlog slows your velocity, confuses your team, and obfuscate your progress.
Six months ago I inherited a backlog after taking over a three year old project. As a new member on the team, I didn't want to rock the boat. I read every issue, added structure that wasn't there and tried to suss out themes from clues the old product manager had left behind. After two months, things were clean. There was a strong goal each sprint, and the team was making progress. But things would somehow... get lost. Bugs I knew I had made were consumed by the black mass at the bottom of the list. I would find three bugs created by different team members within a day of each other, because finding the other bug was harder than making a new one.
If you too are having these issues, resolve to delete half your backlog. But how? What's important and what's not?
If it doesn't have a Who, What, and Why - delete it. Stories without stakeholders, work or necessity are not worth keeping. This cleared out 30% of my inherited backlog. Often technical debt will be tracked in the backlog without any justification as to why it's important. When creating a technical debt story, be sure to justify the exact reason this work is necessary. *Will it improve performance? Solve a bug? Make further development easier? Not sure? Delete it.
If the team can't remember if it was fixed or not, delete it. If it's not worth recalling, it's not worth existing. This was 10% of our backlog. A former team member put 30 items in the backlog, and we're not entirely sure what they are, or if they're important. We realized that if we didn't know what this bug was, and couldn't verify it, we can either forget about it, or it will pop up later where we can fully spec it out.
If it's a feature request that hasn't been updated in months, delete it. It belongs on a roadmap or planning page, not your backlog. Another 10% of our backlog was "Someday" items. Often times it would be fully specced out, well written, but not going to get done within the next year. Instead of keeping it on our backlog, I transferred it to our planning pages.
Don't be afraid to consolidate stories. Stories should be smaller at the top, and bigger at the bottom. We forget the 'bigger at the bottom.' My team has spiked out a epic, only to decide to pick it up at least three months from now. Surely we can't throw away the effort spent to convert an idea into 20 stories? You can, and you should. Your product is changing under your feet every sprint. By the time you come back to that epic, these tasks will be out of date and useless, and you will have been carrying them as dead weight the whole time.
I heard from my old product team recently. That old backlog of mine? Deleted. Entirely. I didn't shed a tear.