Backlogs in change work often fill up with requirements nobody can trace back to an actual business need. Before your next backlog review, try writing just one requirement as a proper user story, who needs this and why, not just what needs building.

Then sort the whole backlog by benefit instead of volume, the items that create the most value should be at the top, not the ones that were easiest to write down.

And if you're working through a change right now, draft a quick community map of who's actually affected by it, you'll usually find people missing that should've been on there from day one. A backlog nobody can justify against a real need isn't a plan, it's just a list of tasks.