If you had read my previous post about Kanban, you are re-thinking about WIP limits.
Why do we introduced limits? To avoid too many things in parallel. But the real goal we want to achieve is to complete stories as fast as possible and studies show the best approach is to have a regular pace.
Well the focal point of this article is to focus on complete stories before kickstart new ones. Introducing the idea of priorities in the Kanban instead of limiting columns.
We know the task should move from left to right, so it seems the most important thing is to move one story from the first column to the second and so on, until it reaches the last one. So we are used to read the board from left to right.
But what is the most important status (column) in Kanban? As the client will answer: is the last one, because it means the work is done, tested and delivered.
And just before the last column? The immediate one on its left, you can imagine the rest.
So at that point instead of placing limits you just have to use a priority approach based on column (or task status), from right to left.
When a dev has nothing to do, he should just look at the most important column before the done, usually is the “test”. So he has just to check if he can pickup some task from the test column, if yes pick one of them and start do tests. If no he moves his attention to the immediate left column, “in progress”, maybe he can help other devs, maybe pair program or splitting a long story. So the point is before start a new task a developer should pass through the entire board backward from right to left and only if he doesn’t find anything he can start a new one. It takes discipline. But nothing more.
That has some pros:
- Increments internal communication
On the other side that requires discipline, it’s really easy to “forget” the priority. Developers doesn’t really like testing or analyzing 🙂