What I've seen work is every once in awhile start with a new board but don't delete the old one. Instead, you can copy / link details to the new board when things become relevant.
You can also occasionally search through the old board to 'steal' ideas that have already had some discussion. But you don't have to worry about the old board going stale.
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.
Your comment sparked an idea. Most ticket systems have what can become a somewhat useless “Priority” field which occasionally ends up meaning “above X or below X”. We try to select the things from every priority that seem either valuable at higher priorities or easy at lower priorities, but a lot of time can get wasted reviewing the same tickets to decide. I am thinking a second similar field of “Risk” would be a great play on this Cost of Delay concept without adding much complexity and might help with more meaningful sorting. Something may be a low priority but a high risk(maybe it isn’t important in itself, but might represent a slice of a bigger risk), or a high priority but a low risk (like something customers want, but in reality is just a nice to have and the product would be fine without it). I suspect “Risk” could be arbitrary or whatever it means to a business, as long as it is consistent.
Definitely given something to consider. Thanks for sharing.
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.
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
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.
What I've seen work is every once in awhile start with a new board but don't delete the old one. Instead, you can copy / link details to the new board when things become relevant.
You can also occasionally search through the old board to 'steal' ideas that have already had some discussion. But you don't have to worry about the old board going stale.
I do the same personally with todo lists.
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.
Your comment sparked an idea. Most ticket systems have what can become a somewhat useless “Priority” field which occasionally ends up meaning “above X or below X”. We try to select the things from every priority that seem either valuable at higher priorities or easy at lower priorities, but a lot of time can get wasted reviewing the same tickets to decide. I am thinking a second similar field of “Risk” would be a great play on this Cost of Delay concept without adding much complexity and might help with more meaningful sorting. Something may be a low priority but a high risk(maybe it isn’t important in itself, but might represent a slice of a bigger risk), or a high priority but a low risk (like something customers want, but in reality is just a nice to have and the product would be fine without it). I suspect “Risk” could be arbitrary or whatever it means to a business, as long as it is consistent.
Definitely given something to consider. Thanks for sharing.
It’s not about boards, it’s just a symptom. Likely about either understaffed projects or nobody giving a shit about getting thinngs done.
What problem does it cause for you that it becomes a to-do list graveyard ?
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.
Wait you mean Kanban boards are not Todo lists?
Proper governance - people in senior positions taking accountability for it all not turning to shit.
Just sync with stakeholders and clean it up once a quarter. If they don’t need it for a quarter it’s probably not important.
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
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.
Limit WIP.
Everyone does 1 thing only.
If things stack in one column try to clear that column instead of taking on new work.
If some tries to be an hero fire them.