Kanban (看板) is pronounced  /’kan’ban/ and means ”visual board” – where kan means “visual,” and ban means “card” or “board”. Kanban is a concept developed at and used by Toyota. It is related to lean and just-in-time (JIT) production.

On the surface, there isn’t much difference between an average task board and a kanban board. Each of these boards has various columns that represent the stages that a card needs to go through before it is considered done. The real difference in a kanban board, is not the board itself. The board is just a visual indicator, the same as any task board, and the intention is still to get the cards to the “DONE”-state – that is, delivered to the customer so that they can use the features from that card.

Kanban is not an inventory control system. Rather, it is a scheduling system that tells you what to produce, when to produce it, and how much to produce.

So, what is the purpose of Kanban? In short it tries to:

1. Visualize the workflow
   Split the work into pieces, write each item on a card and put on the wall.
   Use named columns to illustrate where each item is in the workflow.
2. Limit WIP (Work In Progress) – assign explicit limits to how many items may be in progress at each workflow state.
3. Measure the lead time (average time to complete one item, sometimes referred to as “cycle time”), optimize the process to make lead time as small and predictable as possible.
4. Create flow focus on the throughput based upon the queuing theory.
5. Identify and eliminate bottlenecks – Bottlenecks become clearly visible in real-time. This leads people to collaborate to optimize the whole value chain rather than just their part.
6. Pull system features/tasks are pulled through the system instead of being pushed.

A Simple Kanban

Consider the following three columns in a simple pipeline for software development: Analysis, Development and Testing. When a customer requests a given feature for a software product, they want to pull that feature out of testing so that they can start using it.

Once that feature has been moved out of Testing and the customer is ready to pull the next feature out, there isn’t anything to pull. At this point, the Testing people would then try to pull the next feature out of Development.

And the same pull happens from Analysis to Development.

In the end, we have created a pipeline for how our development process works. The work that is done flows through that pipeline based on how often the customer wants to pull features out. As one feature exits the pipeline, another feature can be added into the pipeline.

The key to all of this is, again, pulling the features through the system.

A more complete Kanban

To create a more complete kanban board, we need more than just a three step pipeline. We need to allow for a fully functional team – developers, analysts, testers, technical writers, and others. We also need to allow the different team members to work on different parts of the system, as work is needed. The end goal is to enable the system to flow through the process and to ensure the work is “DONE” before it goes to the customers.

For a more complete and common software development process, let’s use the following columns: Backlog, Next, Analysis, Development, Acceptance, and Prod. We can put together a Kanban board that follows these steps.

Some comments to what is meant with the different columns:

• Next is the things that the product owner wants done next.
• Analysis is about figuring out the acceptance criteria, identify the first tasks, and if the feature is too big divide/break it down to smaller features.
• Development is simply the development of the features.
• Acceptance is when we think that we are done, and here we need to ask stakeholders to verify that the feature is acceptable.
• Prod is when the feature is done and it is in production. Nothing is left to do.

Once we start working with the Kanban board and start pulling features through the system (see above) we will soon realize that we are probably starting off too much work and that we don’t have a good way of even out the workload. Hence, in order to create a flow, we need to have a way to limit the workload. This is done by limiting the amount of items/features in process within each area (column). This is illustrated with a limit number (see the picture below).

Futhermore, in order to be more clear in our communication to the next step in the flow we can divide our areas of Analysis, Development and Acceptance into; Ongoing and Done. When an item/feature is started it’s assign to the “ongoing” state, as when it’s done and ready to go on to the next step in the process it’s assigned as “Done”. This signals to the next step that once they have an empty slot, the item/feature can be pulled.

Now, we could enrich and enhance this Kanban board even more. As you can see in the picture below we can divide and/or break down our items/features into tasks. These tasks can have indicators when they are done or blocked, and even have an indicator on who (which person) is working on this right now. All of this in order to increase the visualization, create a flow, to identify and eliminate bottlenecks etc.

And some comments on the differences between feature and task:

• Features are deliverables. They flow across the board from left to right, and their workflow state is indicated by which column they are in. The WIP (work in progress) limit in each column applies to features, – and not tasks.
• Tasks are part of a feature, the things that needs to be done to implement that feature. They don’t flow across the Kanban board, instead their state is indicated by colored markers. When a feature reaches development-done then all its tasks are thrown away. If defects are found in acceptance test then defect notes are added under acceptanceàongoing.

A more detailed and simple illustration on how a Kanban item/feature can look like is shown in the picture below. This simple example can of course be even more enhanced with even further information, indicators, and flags. However, it’s very important to focus on your own (real) business needs and without making it too complicated and complex. Keep it simple!

Inspiried by: Henrik Kniberg (http://blog.crisp.se/henrikkniberg)

In summary:

As stated previously; The Kanban board isn’t much different from an average task board. The board is just a visual indicator. The real difference in a Kanban board is the underlying understanding and principles of:

• Being a Pull System
• Visualizing the workflow
• Limiting WIP
• Creating Flow
• Continuously identifying and eliminating bottlenecks
• Measuring lead time

Furthermore, one of the basic ideas of Kanban is a way to continuously aim to improve the flow. So there is actually never a state of being “done” with ones Kanban board. There are always things that need improvement, elimination of bottlenecks, tweaks and fine tunings etc.