Kanban boards, done columns and work in progress limits

For those who use Kanban in their software development projects, a common way of visualising work is to first define the stages through which it passes - a relatively simple process might have ANALYSIS, DEVELOPMENT, TEST - and then split those stages into sub columns to indicate whether a task is being actively worked on, or is queued for the next stage. Some people use Ready and Doing, like this:

Others prefer Doing and Done, like this:

I prefer Doing and Done, but always had difficulty explaining why - until recently. Last month I had the pleasure of working with Al Shalloway, CEO of NetObjectives and a recognised leader in lean/agile thinking, to deliver a series of simulations designed to teach Kanban through playing a game. He and I talked through this problem, and we came up with the following explanation.

What most people are concerned with is what work they have in their to-do list, and what they are currently doing. This is what leads many to use the Ready/Doing split. The problem with this is that if we are looking at flow, we also want them to think about the next stage of the process. For example, if in the above process Test already has a lot on, we don't want Development to do more work and make things even worse for Test - we'd rather they found something else to do, like improving the build process or refactoring some code. So the developer has to monitor their own Ready and Doing columns - but the columns into which they can move tasks (and therefore affect flow) are their own Doing column and Test's Ready column. This leads to a rather odd-looking board if you want to show WIP limits by responsibility:

By switching it around to Doing and Done, the board is much simpler:

Admittedly the developer has to look backwards to see what work they have coming up, but given that the whole point is to focus on flow, I believe this makes sense.

There is a downside. Because Development now has control over Test's work queue, the implication is that Development has the ability to say when something is ready for Test to work on. Really it ought to be Test who get to say that a task is in a valid state for them to work on before they accept it. We can mitigate this by being explicit about what we mean by Done. In our team, we have a clearly defined policy, or ‘Definition of Done’ for each Done column, which has to be met before a task can be moved into that column. This looks something like this:

The other concept Al and I discussed was the level at which we should set the WIP limits. At first I thought they should be set at the Doing/Done level, like this (WIP limits noted in brackets):

But thanks to Al I now understand why setting them at the level above that makes more sense; it is because the purpose of WIP limits is to prevent a task from being started if there is nowhere for it to go, rather than to prevent it from being finished once it has been started. If tasks existed like this:

and an analyst finished T2, they would have to either exceed the WIP limit for Analysis-Done or hold the task in Analysis-Doing even though it is finished, which is a misrepresentation of the truth. Assuming they chose to exceed the WIP limit, there would then be nothing to prevent them picking up yet another task, which if they finished it before Development picked up T1 or T2 would make Analysis-Done even more over its limit, and before you know it:

DISASTER! Your Analysis-Done column is way over its WIP limit, and Development is now overloaded and is a bottleneck - through no fault of their own, but because Analysis worked on the wrong things!

So just to summarise, the following is how I recommend you structure your board – acknowledging that your process may include different stages to the example of ANALYSIS, DEVELOPMENT, TEST:

Questions or comments based on your own experience are most welcome!

Also see our recent article Picking the right Kanban software - Visual Studio vs JIRA vs Trello vs LeanKit.