Agile Zone is brought to you in partnership with:

I am a programmer and architect (the kind that writes code) with a focus on testing and open source; I maintain the PHPUnit_Selenium project. I believe programming is one of the hardest and most beautiful jobs in the world. Giorgio is a DZone MVB and is not an employee of DZone and has posted 638 posts at DZone. You can read more from them at their website. View Full User Profile

How to build a Kanban board

  • submit to reddit

When I arrived here at Allbus S.r.l. as a consultant two weeks ago, the team was busy developing a managerial web application. After having become aquainted with my new colleagues, we started looking for improvements on the informal development process that was in place, and choose a simple tool to collect TODOs and model the flow of work from its definition to completion: a Kanban board.

In the software development field, the word Kanban denotes a simple methodology, much less prescriptive than Scrum and Extreme Programming. Kanban does not tell you if you should write tests before or after the production code they exercise, or how to plan iterations. Actually, it does not tell you even to work in iterations.

In fact, Kanban is a scheduling system, which takes the stories to implement as an input and displays them in the different phases they are in. The only tool needed to implement this system is a Kanban board, which we built in less than an hour with already available materials.

How it works

Here's how a Kanban board works in 100 words.

  • You divide the board in vertical columns, one for each different phase in which a story can be. For example you can probably start with a division such as TODO, developmennt, QA testing, Done.
  • Then, you set up a number (WIP) limit for each intermediate column, and no more than this number of stories can be in that state at any time.
  • Stories advance from the first state to the last one when there is space available: they are pulled in subsequent stages from the developers who intend to work on them.


What are the advantages of using such a simple tool?

For starters, having a single inbox where TODOs go. I was overhelmed by the list of tasks that come to mind here and which I may explore with the team later. Some sort of collection bin is the primary tool of every time management system, and our first column acts as one.

Another primary goal is to minimize work in progress (WIP for friends). In incremental development, every story either provides 100% value (it is fully functional) or 0% (it's not working and it is not visible to the end user.): there are no intermediate values as they are too difficult to estimate. Therefore, we must favor completing a story over starting development on another one. Kanban places explicit limtis, chosen by the team, over the number of stories in development at the same time.

A consequence of limiting WIP is improving lead time: the time it takes for an item to go from the TODO to the Done state (these are the names we have chosen for our first and last column).

The Done column also shows work completed to the team to augment the self confidence of its components.

WIP limits on each stage are useful in finding the bottlenecks in the development process. When a stage is full, the whole board stalls as well and the focus of the entire team is put on resolving the bottleneck.

By adding and removing columns as they fit in our first-hand experience, we can empirically model the currently informal process. For example, we started with 4 columns and switch to 5 today when we noticed we were dedicating a small design discussion phase to each story prior to jump into the code.


So here's how we built our Kanban board from scratch, and how you can do it too as a team or as a freelancer.

  • We found an old plastic board, which we firmly attached to the wall. A board is more visible than any sheet or online but tracking tool when a team member enter the office.
  • We chose Post-it notes to represent stories: each story (or task) goes on a single Post-it, which can be moved along the board. Besides the story description, on the Post-it there is also the date of creation and of completion.
  • We used colored adhesive tape to divide the board in columns, knowing that this tape is easy to remove and the columns could be adjusted in the future if they do not fit the team workflow. If you have a white board, you can use markers instead.
  • We decided the WIP limits for the central stages basing on the number of developers available for them, so that no one is sitting idle, but we do not embark in ten different stories at the same time. We intend to experiment with different limits of course.
  • We got a bunch of different Post-it colors to use for different projects in the same board. The WIP limits are considered global for each column, since even when there are different projects people's time is still the same.

Note that all the team is responsible for each story (cross-functional teams are all the rage in Agile methodologies). Often someone is responsible for a subset of the columns, given its expertise on development or quality assurance or on the business domain.

If you feel some process improvement can be put in place in your team, but you do not want to introduce a full-fledged Agile methodology like Scrum and XP, nothing stops you from trying out Kanban. You can also find useful our Refcard. Happy exploration!

Published at DZone with permission of Giorgio Sironi, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Jani Hartikainen replied on Thu, 2010/09/02 - 2:22am

We've used JIRA with some plugins at Fudeco to emulate a virtual kanban board. It works surprisingly well, if you ignore the fact that JIRA is pretty confusing at times =) 

The plugin we use is some agile view thing (not sure what exactly it's called), but you can customize it to choose the colums you want to be able to put the tasks in. It does not let you define limits on how many items can be in a column at one time, but we just added a number after the column's name to remind us how many could be there.

Jaran Nilsen replied on Sat, 2010/09/04 - 3:47am

Good read. I am curious, how do you handle critical bug fixes on your board - bugs that cannot wait to go through the regular pipeline?

Giorgio Sironi replied on Sun, 2010/09/05 - 5:18am in response to: Jaran Nilsen

We are not at that stage yet since this project is under heavy development, but overriding the WIP limits if a column is at full capacity is the first option that comes to mind. But than we shouldn't call it Kanban anymore. Iteration-based processes (Scrum-like) would drop one of the other stories to make space, but in Kanban there is no timeboxing so dropping something would only mean taking it back at the starting point, a practice that doesn't feel right.

Jaran Nilsen replied on Sun, 2010/09/05 - 12:11pm in response to: Giorgio Sironi

We're currently using an expedite row on top of our board, which then includes all the phases. Once a task / story goes into this row all other activities stops (or at least enough devs are rearranged, depending on the size of your team) and the task / story gets expedited through the pipeline and a bugfix released. Then the team goes back to work on their previous task. This has proven to be a good way to handle these unforeseen events.

Luka Thomson replied on Thu, 2012/08/16 - 6:10am

The Kanban University was a big help for me to design and start using Kanban boards. It provides a roobust collection of examples and tips on how to addapt Kanban board idea to your processes, organization and enviroment. 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.