Kanban methodology: principles, practices and the kanban system

What is the kanban methodology?

Kanban is Japanese for signboard or card. The kanban methodology uses visual signals, usually cards on a board, to show each piece of work and its stage. A limit on how much work each stage can hold stops the team from starting more than it can finish.

The result is a pull system: new work starts only when there is capacity for it. Problems such as bottlenecks, blocked items and long waits show up on the board, where the team can deal with them. The kanban method page explains the board itself in detail.

The kanban system at Toyota

The kanban system began at Toyota as part of just in time production. Taiichi Ohno developed it in the late 1940s and 1950s, inspired by the way American supermarkets restocked shelves only as customers took goods.

On the factory floor, a kanban card travels with a container of parts. When a step uses the parts, the card goes back upstream as the signal to make or move more. The number of cards caps the inventory in the loop. The pull system page shows how these loops are sized.

The Kanban Method for knowledge work

In the 2000s, David J. Anderson and others adapted these ideas for software and office teams. His 2010 book Kanban: Successful Evolutionary Change for Your Technology Business set out what is now called the Kanban Method.

Here the cards are tasks, the board shows the team's workflow, and WIP limits replace the fixed number of factory cards. Later work, including Daniel Vacanti's writing on flow and The Kanban Guide, put more weight on flow metrics such as cycle time and throughput.

Kanban principles

The Kanban Method describes a small set of change management principles.

The six kanban practices

Kanban vs agile and Scrum

Kanban is usually counted as one of several agile approaches, and The Kanban Guide defines it as a strategy for optimizing the flow of value that teams can apply to any existing process. Some practitioners see the Kanban Method as a change method in its own right rather than an agile framework. Either way, the practical comparison is kanban vs Scrum.

Scrum works in fixed sprints, usually two weeks, with set roles and a planned batch of work per sprint. Kanban has no sprints: work flows continuously, the board limits work in progress, and changes can enter the queue at any time.

Many teams combine them, keeping Scrum's events and adding a kanban board with WIP limits. Kanban often suits work that arrives unpredictably, such as support, operations and maintenance.

Kanban metrics

Cycle time is how long an item takes from start to finish. Throughput is how many items finish in a period, such as a day or a week. WIP is how many items are in progress. Little's Law ties them together: average cycle time equals average WIP divided by average throughput, as long as both use the same time unit and the system is roughly stable.

A cumulative flow diagram (CFD) plots how many items sit in each stage, day by day. The vertical gap between bands is WIP, which you read directly. The slope of the Done band is throughput, and the horizontal gap between bands is an approximate average time in process. Exact cycle times come from each item's start and finish dates. The Little's Law calculator and the flow metrics tools guide cover how to measure them.

Little's Law: a worked example

Here is an illustrative example, with made-up numbers, to show how the law helps a team decide where to act. A support team has 24 tickets in progress on an average day and closes 8 tickets a day. Average cycle time is 24 / 8 = 3 days.

Customers are told to expect an answer in two days. Little's Law says that with 8 tickets a day going out, the only way to an average of 2 days is to hold about 16 tickets in the whole system, queue included. Since roughly 8 new tickets arrive each day, that means closing more of them: about 12 a day while the backlog drains, then 8 a day to keep it there.

A WIP limit on its own does not do that. If the team caps work in progress at 16 and changes nothing else, 8 tickets simply move into a visible queue, and the customer still waits 3 days on average. What the limit does do is cut the time each ticket spends half done, and with it the switching between tickets. That is where the extra throughput usually comes from.

So the useful plan has two parts: a WIP limit to stop starting and start finishing, and a check after a few weeks on whether throughput has risen. If it has not, the team needs more capacity or less work per ticket. Sorting the queue also helps the customers who matter most: urgent tickets can go first even while the average is unchanged.

If the numbers do not behave as the law predicts, the system is probably not stable: work may be arriving faster than it leaves, or a few large tickets may be blocking the rest.

How to set WIP limits

There is no correct starting number. A common rule is to begin close to the current WIP in each column, then lower it a step at a time. Watch what happens after each change: if people sit idle, the limit is too low; if items still pile up and wait, it is too high.

Two other starting points work for many teams. One is a limit per person, such as one or two items each, which keeps everyone's own queue short. The other is a limit on the whole board rather than on each column, which is simpler for a small team.

Write the limit at the top of the column and treat a full column as a signal to help, not a rule to break. When a column is full, people swarm on the items already there, or on the blocker downstream that keeps them from moving.

Classes of service

Not every item carries the same cost of delay. Classes of service give the team agreed rules for different kinds of work, so they do not argue over priority at every stand-up.

Anderson's book describes four common classes. Expedite items, such as a production outage, jump the queue and may break the WIP limit, so allow at most one at a time. Fixed-date items, such as a regulatory deadline, start early enough to finish on time. Standard items flow first in, first out. Intangible items, such as clean-up work, have no urgent deadline but cost more the longer they wait.

Show the class on each card with a color or a separate lane. Track how often each class is used. If expedite items show up every day, the problem is upstream planning, not the board.

When kanban is a poor fit

Kanban suits work that flows in a steady stream of small, similar items. It fits less well when the work is one large piece with a fixed scope and deadline, such as building a single facility, where a project schedule shows dependencies better than a board.

It also struggles when the team cannot control what it starts. If every request must begin the moment it arrives, a WIP limit has nothing to act on. Fix the intake agreement first, then add the board.

Last, kanban does not create focus on its own. A team that wants a fixed goal every two weeks, with a review at the end, may find Scrum's sprints give it more rhythm. Many such teams keep a kanban board inside the sprint.

How to start a kanban board

Map the stages your work already goes through, and make a column for each. Start simple: To do, Doing and Done is enough on day one.

Put every current item on the board. Then set a WIP limit on the busiest column, a little below what is in it today, and agree that nobody starts new work while the column is full.

Meet at the board for a few minutes each day, starting from the right-hand column. After a few weeks, look at cycle times and the places work waits, and change one thing. The kanban board page covers the board itself, and board tools are compared in the kanban software guide.

Frequently asked questions