In one role or another I often help teams to try Kanban out or just to help them to create their task board or Kanban board. There is an interesting pattern I observe.

First thing is happening when a team discusses what columns should appear on the board. It is very common, and advised, to start working with Kanban with exactly the same process you already have in place. You could expect people would know it by heart. It should be really quick: “we do this, this and that, so it goes to the board.”

Well, it appears that “process we follow” is pretty ambiguous most of the time. There are discussions whether something is a separate stage of the process or rather a part of the bigger task etc. People find they don’t really know where to put specific tasks as they’re floating depending on a number of factors. It appears the process isn’t really defined or not everyone is on the same page or people understand their tasks differently.

Note: it all happens without any change in the process. No wonder why many process transitions are failed. What do you expect when people don’t really get how they’re working at the moment, let alone how they’re supposed to work?

Then there is another observation. In the long run Kanban boards tend to become more and more complex. As teams work with their boards they add something to the structure more often than they remove anything. That’s perfectly understandable. When people learn better their process and the board which should reflect the process they have more ideas how to improve it. So they do, adding things and making the board more complex over time.

Usually later version of the board has more columns/sub-columns/lanes/you-name-it than the earlier one. Sticky note bears more information too. Well, if you compare the first version of our Kanban board with the last one you’ll exactly see exactly the pattern.

OK, but where does it bring us?

Considering these two things: we usually don’t really know the process we try to map with the board and the board becomes more complex over time we should avoid over-engineering the board. Start simple and keep it simple. Don’t try to map every possible issue with the initial design of the board.

I would even say that the idea to start with a single “ongoing” column representing the whole process of doing the work is pretty good. You will split it anyway but at least you will know exactly why you’re doing that and which stages you want to make explicitly visible and separated from others.

When crafting your board, if you have doubts whether you should add a column or lane or something or not as a rule of thumb you shouldn’t do that. You’ll do it later… if you really need it.

One of stages of one-afternoon Kanban setup we did was creating our own Kanban Board. We just discussed what we wanted on the board adding columns which appeared reasonable for everyone.

This is what we came up with.

To describe stages:

• Backlog is a big bag where I willingly throw in anything anyone wants our project to have. Now we have the best product around. It will virtually have every feature in the world. I would also be a best Product Owner around. The guy agrees on every feature idea you could possible come up with. Unfortunately he can’t say when the product will have all these features.

• Todo is a short list of current top priority tasks which aren’t yet started. It usually changes every time I come back from a meeting with one of our customers or partners. I keep the rule that whatever is on the top of this column is also the most important at the moment.

• Dev, which comes from development, is a group of two columns: one is ambiguously named Dev, which comes from “in development” and another one states CC from “code complete.” The former groups tasks which are under active development. They make their way to the latter after developer’s tests. This couple is grouped since code complete is just a technical stage to tell us specific functionality is ready.

• Test is what it sounds it is. Testing. Checking whether we could deploy version if we wanted to. Finding bugs and fixing them. On and on.

• RTS comes from ready to ship. For the moment we set up the Kanban Board we weren’t planning to have regular deployments in production environment so we just wanted to have versions which would be possible to ship if we needed that. Whenever something reaches RTS column the work is considered to be done.

Then, we wrote down all tasks which weren’t yet completed, including these being under development and these which were in plans only. Every task was written on a single post-it note and was posted under relevant column.

We ended up with a post-it in Todo, two in Dev, one in CC and six in Test. The overwhelming rest was in Backlog. And yes, long Test column made our problem with finishing tasks painfully visible.

When we were done playing with sticky notes it was time to set limits for each column.

• Backlog doesn’t have any limits. That’s natural. Hey, I don’t want our product to lack any feature. Give me all of them. And I mean all.

• Todo column was limited to 3. I think this is good maximum queue length – it makes clear short-term perspective. As it appeared later quite often it was hard to decide which sticky notes would make their way to Todo column and which would not. And it wasn’t rare when something was going back to Backlog before guys here were able to start working on this.

• Dev was limited to 4. This included sum of both Dev-Dev column and Dev-CC. Basically we came up with the number assuming it’s still acceptable that each developer has one task completed (CC) and another one started (Dev).

• Test was a biggest problem. We finally set the limit at 4. We knew 6, which we had in Test at that moment, was too much. On the other hand we didn’t have any clue what should it be. I was far from setting there a number which is too low and supporting fiction. So we used some guesstimation and use 4 as our lucky number. And it created an instant incentive to work hard on cutting this queue a bit.

Finally our first version of Kanban Board looked like that:

This is by the way much simpler board than Henrik Kniberg proposes as a kick-start example. Personally I encourage you to start as simple as possible. You’d adjust things later on. Henrik’s proposition is too complex for the team which isn’t familiar with Kanban. It pushes too much detail to the board which makes it hard to read.

Read the whole story from its boring beginning up to this point, where things hopefully become interesting enough to keep you irresistibly waiting for the next chapter. Check also version 2.0 and version 3.0 of our Kanban Board.