Virtual Horizontal Swim Lanes on a Kanban Board
How to use card types and filtering to build multi-level Kanban boards without physical swim lanes — a practical pattern for Features and Stories.
After a serious break from Kanban Mechanics posts, here is one for you Kanban System Designers/Practitioners out there…
I’ve recently become a fan of the “Virtual Horizontal Swimming Lanes” style of Electronic Kanban Boards. These Boards don’t use physical horizontal lanes but instead use dynamic and easy filtering to show virtual lanes. Specifically I helped several teams come up with this style to represent a 2-level board - for Features and Stories (actually 3-levels if you count breaking each Story into Team-Stories or Tasks using a sub-taskboard). Since I get some questions about this, I thought it will be helpful to record a short screencast about it. So here it is.
These teams use LeanKitKanban by the way, which does a very nice job, especially with the refreshed UI and filtering capabilities.
I’ve worked with simpler designs in AgileZen and more and more tools provide dynamic data-based horizontal swimming lanes these days (Atlassian GreenHopper RapidBoards seems to have a good one that some teams like but I haven’t worked with it too much myself). In order for the tool to support this you will need a way to filter/split into lanes based on data attributes of the cards, ideally with the ability to setup a couple of identifiers for the virtual lanes that will be attached to the items moving thru the lane and then detached from it.
Kanban Board Hierarchies using Virtual Horizontal Swimming Lanes
Getting a clean release burnup
Also, once you start using such a board, getting to a workable “Release Burnup” which shows you trendlines of your progress compared to where you need to be can be tricky, as it always is with multi level boards. A key trick is hiding the parent expanded Feature when its child Stories are in play as well as hiding the completed Stories from the CFD when they are collapsed back into the parent Feature. This way we avoid showing a piece of work multiple times in the CFD.
This CFD is calculated based on card size since that is the way to deal with different levels of size on the board as well as the fact that Features in the backlog might not yet even be Minimally Marketable and so can be quite large. Not this is the way to track a “Release”/“Project” comprised of multiple Features. To track a single Feature you simply use the filter above to see how it is doing, or create a CFD focused just on the cards in this virtual lane and then see the burnup towards completion of this specific feature.
To generate this CFD in your tool you will need a strong CFD capabilities that allow you to expand/collapse lanes as well as ignore lanes and calculate CFD based on size.
Grab the board template
If you are interested in the template for this board here it is. Maybe the LeanKitKanban guys will add it to their template library at some point…
Want more on this setup?
If you want to learn more about this leave me a note, I might be convinced to elaborate some more…
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 →
- 01 A Kanban for Marketing Board Example 1 min
- 02 Actively Managing Portfolio Flow 2 min