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.
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).
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?
I'm Yuval Yeret. I'm leading the Kanban practice at AgileSparks. This blog focuses on my experiences using Lean and Agile approaches to help organizations and people become more effective.
Top Posts & Pages
- My favorite Excel-based Agile Backlog Templates
- So what IS Scrumban?
- How does the performance objectives process change in a Lean/Agile world?
- How to use Kanban to help improve your recruiting process
- Don Reinertsen's Cost of Delay Intuition Exercise - a facilitator's guide
- My thoughts on how Kanban and TOC Critical Chain relate
- Kanban Method - Finding the Minimally Viable Change
- Explore Product Owner / Team responsibilities Exercise
- How to replace the timebox-based motivation when using Kanban/ScrumBan
- Scrum Sprint Commitment Rant
Tag cloudTransition Agilesparks MMF kanban RND velocity SPC Workshop Training metrics greenpepper agile test_case_management LKCE11 QA LSSC11 hr project_management bugs flow Lean Startup Teams Israel agile_testing conference Commitment Cycle_Time Continuous Improvement resources scrum LimitedWIP Slack sprint SLA LSSC12 reading_materials agile testing issue_tracking classes of service Organization lean קנבן engineering_practices iterations relationships
This work by Yuval Yeret is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.