The Kanban Story: Kanban Board

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.