Do we need stack ranking in a kanban system?
Stack ranking work items in a Kanban system: when explicit priority order earns its keep, and when WIP limits do the job instead.
I want to talk about a kanban system design issue today.
Do we need a way to portray full stack ranking of cards throughout a kanban system or is it enough to see stack ranking per lane ?
To elaborate - sometimes it feels necessary to convey the priority of cards and have a way for that priority to travel with the card throughout the system. A way to achieve this is to allocate a running priority such as 10, 20, 30, etc. to cards. Those of us with background in the “Basic” programming language will understand the numbering scheme - it allows for inserting other cards between priority slots later on.
The Case for Skipping Full Ranking
Since not many electronic kanban systems support this, I was forced to think again about whether this is actually necessary and reached a conclusion it is a bit redundant if a few key assumptions are made.
Assuming all cards are of the same “class of service”, it is typically reasonable to adopt a “FIFO after pulling into WIP” policy - which means that after a card is pulled into work, we should make all effort to finish it even if it originally had a slightly lower priority than other card options. If we pulled it we had a good reason and it is less relevant anymore - lets just get it over with. If that is the case, after pulling the card all we care about is FIFO - so stack ranking within a lane as well as lane position should be enough - just pull topmost card from the rightmost lane possible to obey the FIFO (or look at start date).
Multiple Classes of Service
The plot thickens when there are more classes of service. The policies for Fixed Date and Expedite deal themselves with priorities and pull order so I won’t elaborate on them here as they’ve been covered elsewhere in Kanban literature in depth.
A class of service that is not often discussed is a “stretch” card from a release backlog. Essentially a card that is a “wishlist” but not something that was committed as part of the release, so we prefer not to pull it before committed scope for the release. The policy we probably want to have is to always pull “scope” cards before “stretch” cards when possible. Even if a “stretch” card made it into WIP we might want to bypass it if a “scope” card is catching up. (You might wander why a “stretch” card would be pulled in the first place - the typical answer is resource capabilities - “scope” cards were skipped because of lack of knowledge until a “stretch” card was reached - this is an indication of lack of capabilities versatility and should be monitored and improved on by the way). So basically all we need to support this policy is a visualization of the fact that the card is “stretch” scope. It is possible to use a “low priority” indicator for this. Maybe it is better to have it as a different card type to make it easier to filter it out when tracking release progress using a Cumulative Flow Diagram Burnup Chart. You might want to display “stretch” cards as scope completed, or ignore them and just track completion rate of the “scope” cards. I would think that is preferable.
So bottom line seems like full board-wide stack ranking is not required in most cases. Classes of Service or a few priority pools can suffice for most reasonable pull policies.
What is your experience? Do you track priorities in a different way?
Improving flow means fewer bottlenecks, faster feedback, and less wasted capacity. Explore flow advisory or let’s talk.
Yuval's practical guide to Kanban for knowledge work — distilled from 17+ years applying Kanban inside real product and technology organizations.
Yuval Yeret helps product and tech leaders move from agile theater to evidence-informed delivery. Work with Yuval →