A Kanban board is the key visualization tool for implementing Kanban in your business. A Kanban board is used by any team that uses Kanban for visual management of their work and improving their delivery of products and services in terms of predictability, quality and time-to-market performance.
A Kanban board can be physical – which is how most teams start using Kanban – or electronic. A typical Kanban board consists of one or more (swim) lanes and multiple columns to depict the workflow process (also referred to as Value Stream) that it is used to manage. A Kanban board represents a “virtual kanban system” used to model the process and track the knowledge work being done by your team.
You can start with a physical Kanban board on a whiteboard/ soft-board or perhaps some large glass windows or partitions in your office. The bigger and more visible they are, the better!
Many teams migrate to (or start with) an electronic Kanban board for supporting distributed teams, better and automated metrics generation and easier/ better reporting.
Lanes and Columns in a Kanban Board
You can start with a basic Kanban board of 3 columns – To Do, Doing and Done – populated with cards that represent work items of different types. However, going by the Kanban maxim of “Start with what you have”, most teams start by modeling their current process which tends to be more elaborate than that.
The columns on the board fall in 3 buckets –
- To Do (popularly called the ‘Ready’) column contains all your cards that are next up. Typically, a ready column is placed at the start of the board.
- Doing (or ‘In Progress’) column(s) contains all cards that you are currently working on. You can have multiple Doing columns for each stage of your workflow, as shown above.
- Done column(s) contains all cards that you have finished working on. Depending on the workflow definition, you can have one or more Done columns to collect cards that have completed a specific part of the workflow. You will also typically have a final Done column which might be highlighted uniquely, to indicate that all work on the cards in that column has been completed.
(In SwiftKanban, we have “Completed” columns to indicate intermediate done stages, and a “Done” column that gets highlighted in green to indicate the final done column.)
Additionally, you might have a separate “collection bin or area” called the Backlog where cards are initially created and stored. Similarly, at the other end, you might have a “Archive” bin for keeping the cards that have been Done and are now ‘closed’.
A Kanban board can have one or multiple lanes – also referred to as swim lanes – which can be used to segregate different types of work, which might possibly have different workflows. Lanes can be defined to track and manage different work item types, different Classes of Service, different products or applications or business streams that your team works with, different customers or business units they support, etc. The organization of your Kanban board has many considerations. For a more detailed look at how you might design your Kanban board, you might want to download our White Paper – 10 Factors to consider for your Kanban Board design.
As explained here, WIP limits are crucial to successfully implementing Kanban. Initially, it may not be easy to decide what your WIP limits should be. In fact, you may start with no WIP limits.
But once you have sufficient data, you can define WIP limits for each stage of the workflow (each column of your Kanban board). Typically, many teams start with a WIP Limit of 1 to 1.5 times the number of people working in a specific stage.
In addition to defining the WIP limits, you need to also define how you will enforce the WIP limits. You may choose to either not exceed WIP limits or if you prefer, you allow them to be exceeded for special circumstances, but perhaps capture the reason for why you are choosing to do so.
At the simplest level, work is done by pulling cards on the Kanban board and taking them through the various stages of the workflow defined on the board.
Cards get pulled from the Backlog to the Kanban board as per available capacity to work on them. The frequency with which cards get pulled depends on your context and how often work needs to be pulled. A Scrum software development team may pull work every 2 weeks during Sprint planning. A Kanban software team or a support team may pull cards continuously as cards get completed and archived. A recruitment or marketing team may pull work every week, based on completion of job-reqs or marketing tasks/ campaigns.
Depending on your process, each card goes through multiple stages (columns) – till the full workflow is completed and the work is done.
Kanban is very flexible – you can easily map almost any process onto a Kanban board and use it to manage the work. Here’s a screenshot of what our actual SwiftKanban development board –
Cards move from left to right i.e. from the Ready column to the final Done column. Kanban encourages team members working on different stages of the workflow to pull a card and work on it when they have completed anything they were working on and have the capacity to do the next task.
For example, in a simple Code, Test, Review process, when a tester has completed the task at hand, they will look for cards that are in the ‘Done’ column under Code. If there are cards in the Code done column, they can ‘pull’ the card into the Test in-progress column and begin working on it.
Combining WIP Limits with the mantra of “Stop Starting. Start Finishing!”, Kanban helps you ensure that there is a smooth flow of work without any buildup of excess workload at any specific stage of the workflow.
Each Kanban card (or Kanban) represents a task or a work item, which requires capacity to be worked upon. The Kanban board with its WIP Limits provides you visual signals of when capacity is available to work on those cards.
Kanban Cards can be colored differently to either represent different work-item types or classes of service or other attributes. (In SwiftKanban, card colors represent different work item types.)
Kanban cards are hierarchical by nature. You have work-hierarchies in most things you do:
- Projects breakdown into phases and tasks.
- Portfolios have programs which in turn have projects.
- Epics have Stories which have tasks.
You can use Kanban cards to model these hierarchies. You can define programs level cards, which break down into project cards, which in turn can be decomposed into tasks. Similarly, you might set up a hierarchical set of cards for Themes, Epics and User Stories in a Scrum environment.
Cards are generally defined by the kind of activity your team performs. For example, a development team could have three different types of cards – for bugs, issues and change requests. A Support or Help Desk team may have cards such as Issues, Tickets, Incidents, Requests, etc.
Besides the color identifier, Kanban cards can have a variety of visual cues or attributes to provide information on the work being done through that card and its current status. Here’s an example card –
Additional topics you may be interested in:
Check out some of the great resources on the top right side of this page. You can also sign up for upcoming webinars on Kanban – or look at some great previous webinars conducted by people such as David Anderson and other thought-leaders in the Kanban community!