Item limits in lanes, automatic escalation when an item sits stagnant, re-prioritization, management approval or efforts to move things back into a queue, encouraging engineers and developers to manage realistic expectations and manage their queues as well as communication with people waiting on these tasks. Cross-team meetings and displaying the lanes in meetings and getting updates. Item colors change based on time. Those last bits may or may not work depending on the culture and discipline of organizations and the overall company.

A couple jobs ago, all tickets had a "cost of delay" field that was usually required.

At first it felt absurd & silly, but over time, the spirit of it grew on me a lot & has stuck with me. Let the backlog grow! But have tools to see what actually matters in the backlog, to assess where to go next. And the Cost of Delay should really indicate what really must be moved on.

(I've seen more complex attempts, with a Weighted Shortest Job First (instead of Cost of Delay) that sometimes helps. But conceptually it feels more abstract and more overhead than just asking, how bad is it to put this off?)

Also, having different ticket types can help a lot. Teams can figure out what's high value, but sometimes your business should be focusing on defects. Sometimes it should be focusing on spikes. Sometimes it should be focusing on features. If everything is just a ticket, in the same pool, it's hard to assess & align.

Who owns prioritization of the board? Someone must, and they should put the most important task at the top of the first column. They should keep doing that, constantly updating as things change. (Kanban ain't Scrum.) Then the devs are instructed to always grab the top card. If cards pile up below that... meh, doesn't matter. Because that board owner is making sure it doesn't matter because they already prioritized it all. If some old card is causing problems by not getting done... well, the board owner needs to prioritize it higher. Cards that never get done didn't need to be done anyway.

Then, actually follow the rules of Kanban. Don't run a Kanban board with a Scrum team and think it will work. They are fundamentally different approaches to moving work forward.

Basically, it is not about your board, it is about your leadership and culture.

BTW, I never put the backlog on the dev's Kanban board. I am the one who needs to worry about all that noise, so I only expose them to the small subset of work that matters. I do give them access to the backlog so they are not in the dark, but don't mix that with their day-to-day board.

What problem does it cause for you that it becomes a to-do list graveyard ?

Stop creating to do lists?

Seriously either do the work and not record it at your peril or put in ways of working that the make the board the only way work is initiated moved and closed