Some years ago, I learned about a key part of Kanban board design. The usage of sub-columns and WiP limits is important to get right to help your process and ensure transparency. This is really simple to do on physical boards, but if your electronic system doesn’t have this basic capability, it can really only support very low maturity Kanban implementations.
Why would I use this? Often there may be different skills / capabilities within the team and showing where they are in the overall process will signal those downstream when there is something available for them to work on.
In the above you can see an example of what I’m talking about taken from the SwiftKanban product (I zoomed in on one section). You can see Develop is split between “In Progress” and “Done”. This tells us when things are under development, but also tell the testers downstream when items are ready for them to pick up. This allow you to put a WiP limit on top of both these sub-states to ensure developers don’t pick up additional work if there’s already enough queued up for the testers.
If you don’t have something like this, then you’ll likely be pulling more WiP into the system, or you can’t transparently see where items actually are. For example, consider if I instead had separate columns for “Development In Progress” and “Development Done”:
In this case, both columns have a WiP limit of 5. Another example is where we reduce both to ensure no more than 5 overall:
In the first example we just made both items have a WiP of 5, which increased the overall WiP in the system. This can be detrimental as lead times will tend to increase and developers will focus on starting more work rather than helping testers complete work.
In the second example we reduced the WiP. In both of these examples, we’ll run into problems with the “Done” column filling up. Let’s say a developer pulls work into “Development In Progress” and keeps moving items into Done when they’re ready. At some point, using the second example, we’d fill up the WiP of 2. The we end up with items in the “Development – In Progress” column that have actually completed the development. This is impacting transparency and brings some confusion to those doing the work who may have to figure out where things are when the “Development Done” column frees up again. Plus you don’t really get that sense or feeling of flow.
Furthermore, even if you have sub-columns, if you put the WiP limit on those, rather than controlling from above you will run into the same sorts of problems as those described in the last two examples.
Having this sub-column split also lends itself to other modifications. For example, you may have a situation where testers / downstream people are a “non-immediately available resource” and you want to make sure that when they are available, there’s plenty of work for them to do so that they’re not sitting idle. Furthermore, you still want to remove burden from developers so that they don’t task switch. You can increase the WiP limit overall for Development to allow for a larger buffer before the testing bottleneck, but keep the “In Progress” low to ensure developers are not overburdened. For example:
More detail:
These kinds of modifications are really easily done on a physical board, just move things around how you want them designed. There are a number of tool vendors out there that do these basic Kanban functions – if yours can’t then you might want to look for something else as you’re limiting the flexibility and maturity level of your team. Here are the same examples in Kanbanize:
And LeanKit:
There are many design improvement that you can do to your kanban system to better enable flow and ensure that it’s predictable. These are some of the little tips that I give in my Kanban Management Professional courses. For further information and registration, please refer to: