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
- Making Agile Teams work in real life - The quest for Stable Feature Teams?
- So what IS Scrumban?
- Don Reinertsen's Cost of Delay Intuition Exercise - a facilitator's guide
- Kanban FAQ: Should I FINISH what I'm working on or help the team READY new work items?
- Kanban Method - Finding the Minimally Viable Change
- Explore Product Owner / Team responsibilities Exercise
- Starting with Managers Kanban (also called Product Stream Representative Kanban)
- How does the performance objectives process change in a Lean/Agile world?
- Do Craig Larman's Laws of Organizational Behavior really mean we always need to start with a structural change? What do they say about starting with Kanban?
Tag clouditerations reading_materials agile testing Training קנבן bugs RND hr QA lean SLA Israel velocity Continuous Improvement SPC Commitment Workshop relationships Slack scrum LimitedWIP metrics conference sprint greenpepper Agilesparks project_management LSSC12 MMF Teams Lean Startup engineering_practices test_case_management agile kanban agile_testing Transition classes of service issue_tracking LKCE11 flow Cycle_Time resources LSSC11 Organization
This work by Yuval Yeret is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.