≡ Menu
Pawel Brodzinski on Software Project Management

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.

in: kanban

6 comments… add one

  • flowingmotion November 23, 2009, 1:55 pm

    That board would make me anxious. I think there has to be three boards. 1 for backlog out of site. 2 or WIP in sight. 3 for RTS where we take breaks!

  • Robert Dempsey November 23, 2009, 2:41 pm

    Thanks for the post Pawel. I'm looking at using Kanban (currently use Scrum) and hearing how your board it set up helps me to see alternatives.

    Question for you. In your testing area you say that you fix bugs there too. Is that correct, or if you encounter a bug does it go back to dev? Thanks.

  • Pawel Brodzinski November 23, 2009, 4:37 pm


    I don't agree on 3 boards. I work a lot switching sticky notes between backlog and todo (setting priorities) and it would be strange to have them in different places. It's not like in Scrum that priorities are set once every iteration. Sometimes it works that way but sometimes I change todo list twice a week.

    It also works for the team to see what we're going to do in middle- and long-term perspective. To give you one example – we decided not to do any administration GUI at the moment, but it sits there in the backlog so we already know we can prepare some hooks to make later development smooth.

    Another thing is RTS which I clear from time to time to clear the board a bit. It doesn't clutter the board much anyway since usually notes are stuck there one on another.

    Clearing RTS column is going to work while we start deploying our project in production environment rigidly. We may add a limit for the column then.

  • Pawel Brodzinski November 23, 2009, 4:45 pm


    Basically nothing gets back from the right to the left in any case (except of things from todo going back to backlog). When we encounter a bug fixing it is still a part of testing phase. If developers wouldn't fix bugs a blocker in test column would emerge, quickly followed by filling limits in earlier stages.

    We don't have very strict iterations of testing – it's often case when we're going through tests and developer instantly starts fixing bugs which are submitted. In this moments it would be even hard to say whether a "sticky note" is under development or under tests because it's under both.

    Keeping bug fixing as a part of testing stage just feels easier.

  • Steven Vore May 6, 2011, 9:17 am

    I’m reading through the stories here in order, so perhaps this is already covered later, but what happens when the test column is “full” – Do the devs just stop working while the testers catch up?

  • Pawel Brodzinski May 6, 2011, 12:26 pm

    @Steven – When a column is full people who would naturally pull another feature to this column should find the other task to do, possibly help other to unblock following stages.

    Another idea is to spend the time to sharpen the saw – learn something new or do some cleanup.

    You can also agree on breaking the limit in this specific case but from my perspective it isn’t recommended. If you abuse limits too often they don’t help you to improve anymore.

Leave a Comment