If a smaller backlog won't tell us how much we've helped, choosing what to fix next needs more thought than picking the next ticket on the list and closing it quickly. And when there are dozens of them and enough time to fix only a few, this becomes mission-critical.
One option would be to start with the easy ones. I understand that temptation well. You see things moving, you see the number of open tickets dropping and you have something to show for that effort.
Is it enough?
Probably not.
Do you know who you've helped if at all? Do you know what tasks were blocking them? And what tasks are blocking them still?
Can someone book an appointment? Cancel one they no longer need? Read the instructions before their visit?
If you know this, you could group the issues affecting these tasks. This makes it much easier to prioritise groups of tasks and within those groups.
Suppose booking has four accessibility issues. Fixing the easiest three means you've fixed 75%. But the last remaining one still leave a keyboard user unable to confirm their appointment. That's still a major blocker and you haven't really solved much to help them.
It doesn't mean the three fixes are worthless, but we need to understand what else must change before someone benefits from them.
This is when the prioritisation conversation has a much a clearer purpose. We can talk about what it would take to make booking usable, rather than compare isolated tickets with similar priority labels.
You'll still have to make trade-offs. Fixing a shared component will help across several tasks. Something more serious, but specific, will need more investigation before you can estimate it. And there's nothing stopping you from doing those small fixes alongside that work.
We don't have to finish the entire backlog before making a difference for people using our products. In fact, you'll never finish a backlog. There will always be something extra in there.
It's more important that the next fixes we release add up to something someone can do from start to finish.