Kanban

Origin

Taiichi Ohno and Toyota (card system); David J. Anderson (Kanban Method for knowledge work), 1950s at Toyota (sources differ); 2010 for the Kanban Method

Level

201 · Tool

Fits

Startup, Small and mid-size, Scale-up

Time to apply

About 2 hours to map the workflow and set first limits, then a few weeks of weekly reviews to tune them

What you need

a list of the work items your team handles, with who is doing what today · the real steps a piece of work passes through, from request to done · a board, physical or digital, and a weekly slot to look at it

Kanban is a method for managing the flow of work: you show the work on a board and limit how much of it is in progress at once. The word is Japanese for a sign or signboard. It has two lines of descent. One is the card system Toyota used between its production processes. The other is the Kanban Method that David J. Anderson built for knowledge work and described in a 2010 book. They share one rule: start new work only when there is room for it.

Where the Toyota card came from

A kanban at Toyota is a signal. The Lean Enterprise Institute defines it as a device that authorizes and instructs the movement or production of items in a pull system. A downstream process uses parts, the card travels back, and only then does the upstream process make more.

The sources disagree on when this began. Toyota’s own history says its supermarket method was introduced in 1954, based on a report on a Lockheed aircraft plant in an industry publication. The prior process is the supermarket and the next process is its customer. The method then grew into the kanban system by adding a production instruction sheet, with no date given. A retelling of Taiichi Ohno’s story has him running pull production from supermarkets by 1948, passing information on a scrap of paper that later got the name kanban. Ohno’s own book, published in English in 1988, is the primary account. We treat the exact year as unsettled.

The earliest English-language write-up of the Toyota system was a 1977 paper by Sugimori, Kusunoki, Cho and Uchikawa. Kusunoki later explained that the kanban count formula carried a policy variable, and that Ohno pushed workplace leaders to keep cutting the number of cards.

How Anderson moved it to knowledge work

Anderson says his first pull system ran in 2004 at a Microsoft maintenance group, and that Donald Reinertsen urged him toward kanban in 2005. He then called the system a virtual kanban system. In 2006 he and a colleague built another at Corbis, and the book Kanban: Successful Evolutionary Change for Your Technology Business followed in 2010. That history is Anderson’s own, and he disputes other accounts, so read it as one party’s record.

Kanban University’s guide calls the Kanban Method a management method applied to an existing way of working, not a methodology or process framework. Its change principles include starting with what you do now and pursuing evolutionary change. Its practices are to visualize, limit work in progress, manage flow, make policies explicit, implement feedback loops and improve collaboratively.

A second definition comes from the Kanban Guide, with versions dated July 2020, December 2020 and May 2025, written by John Coleman, Daniel Vacanti and contributors. It says Kanban is a strategy for optimizing the flow of value through a process. It names three practices: define and visualize a workflow, actively manage items in it, and improve it. Together they make a Kanban system.

What a board and a limit do

A board is the workflow drawn as columns. A limit is a cap on how many items may sit in a column or in the whole flow. The Kanban Guide says members must explicitly control the number of work items in a workflow, and that this creates a pull system: members start an item only on a clear signal that there is capacity.

The limit is the part that changes behaviour. Without it, the board records the pile. With it, a full column forces someone to help finish an item, find what is blocked or say no to new work. The Toyota card, the board limit and CONWIP, a pull system proposed in 1990 as an alternative to card-per-step kanban, all work by capping what is in progress.

Little’s Law: why a limit shortens waiting

Little’s Law says the average number of items in a system equals the average arrival rate times the average time each item spends in it. John D. C. Little proved it in 1961. In 2011 he wrote that it holds under remarkably general conditions, and that a version for finite periods does not require a stationary arrival process.

For a work board, the three quantities are average WIP, average throughput and average cycle time. The Kanban Guide defines WIP as items started but not finished, throughput as items finished per unit of time, and cycle time as the time from start to finish. So average cycle time is average WIP divided by average throughput.

Take a team that finishes 3 items a week with 12 in progress. Average cycle time is 4 weeks. Cap WIP at 6, hold throughput at 3, and the average falls to 2 weeks. The arithmetic is exact, though the assumption that throughput holds up is a bet.

Vacanti’s book on flow metrics builds its approach to predictability on this law. The Kanban Guide adds a forecasting tool: a service level expectation, such as 85% of items finished in eight days or fewer.

How Kanban differs from Scrum

Kniberg and Skarin’s 2009 comparison of the two lists the main differences.

Question	Scrum	Kanban
Roles	Defined roles	None prescribed
Rhythm	Fixed-length timeboxed iterations	Continuous flow
Limit on work	Per iteration	Per workflow state
Mid-cycle changes	Resisted within an iteration; board reset between iterations	Board is continuous
Estimation	Estimation and velocity	Not required

Their point is that neither is good or bad in itself. Many teams use Kanban’s limits inside a Scrum rhythm.

Does it work? What the evidence says

The evidence is thinner than the enthusiasm. A 2018 structured synthesis by dos Santos and colleagues covered 20 primary studies and found over 16 reported benefits, four of them well supported: work visibility, control of tasks, flow of work and time to market. Organizational culture was the main challenge. The authors also found no negative results, which they flag as a gap. A 2018 mapping study of software Kanban research from 2006 to 2016 found that most of it was descriptive, with little rigorous study.

At the team level, a year-long study at the University of Helsinki’s Software Factory found developers rated Kanban easy to understand and motivating, with less overlapping work and better communication.

Most numbers come from vendors and practitioners. Treat them as reports, then check your own flow data.

Before setting limits, draw the workflow as it runs today. BPMN process mapping gives a standard notation for it, and a RACI matrix names who owns each step. A Growth Lab plan can start from that map.

How to apply Kanban, step by step

1. Map the workflow you actually use. Write down the steps a piece of work passes through today, such as Requested, In progress, In review, Done. Do not invent an ideal process. The Kanban Method starts with what you do now. Result: columns on a board that match reality.
2. Put every item on the board. Turn each open piece of work into one card in the column where it stands today. Include the small requests that normally arrive by chat. Result: one view of everything in progress.
3. Count what is in progress and set a first limit. Count the cards in the working columns. Set the limit at or just below that count, for example 6 if 8 are open. The Kanban Guide does not prescribe a number, so treat the first one as a guess. Result: a written limit per column.
4. Pull instead of push. Start a new item only when a card leaves a limited column. When the column is full, help finish something rather than begin something. Result: a rule that stops new work piling on top of old work.
5. Write the policies on the board. Record what done means for each column, how urgent items are handled and what happens when a card is blocked. Result: rules everyone can read, not habits held in people's heads.
6. Measure flow and review weekly. Track the four numbers from the Kanban Guide: WIP, throughput, cycle time and the age of each open item. Each week, look at the oldest items and the full columns. Result: one change to a limit or policy per week, based on data.

Examples

Hospital supplies with two-bin kanban

A documented case. A Naval Postgraduate School poster reports on Naval Medical Center San Diego, which rolled out a two-bin kanban system for supplies in fiscal 2014. When the first bin of an item runs out, staff start on the second and the empty bin triggers a reorder. Across three departments, the poster reports statistically significant improvements in order cost and order efficiency between fiscal 2013 and 2015. It is a before-and-after comparison at one site, not a controlled trial.

A payments operations team with a review queue

Illustrative. A fintech support team handles customer verification cases through Received, Documents checked, Compliance review and Decided. Compliance review fills up to 14 cases while the one reviewer does 3 a week, so a case waits almost 5 weeks there. The team sets a limit of 4 on that column, stops pulling new cases into it when it is full and escalates when it is blocked. Waiting time falls toward 1.3 weeks by the arithmetic of Little's Law, and customers hear sooner.

Microsoft's sustaining engineering team

A documented case from the author of the method. Anderson designed a pull system for a Microsoft maintenance team in 2004. Kanban University's case study reports average lead time for change requests falling from about 5.5 months to 12 days and on-time delivery reaching 98%. The numbers come from the method's own publisher, so read them as a reported result, not an independent audit.

When to use it

Use it when work arrives continuously and unpredictably, such as support requests, bug fixes, operations queues, content production or compliance reviews, and the symptoms are long waits and many items open at once. It layers onto your existing process and needs no reorganisation.

When not to use it

Skip it when the work is one large project with a fixed deadline and a known sequence, where a plan and a critical path serve better. It also adds little where nobody can finish an item without waiting for someone else every time, because limits will then just show the blockage without removing it. Do not use it to monitor individuals.

Common mistakes

• Treating the board as the method. A board with no limits only shows the pile. The limit on work in progress is what changes behaviour.
• Setting limits so high nothing is ever blocked. A limit that never bites does not force finishing before starting.
• Changing the limit whenever it hurts. A full column is the signal to find the blockage, not to raise the number.
• Adding columns for every handoff and role. Each column is a place for work to wait, so keep the workflow as simple as the real process allows.
• Ignoring ageing items. Cards that sit for weeks hide behind a healthy average, so look at the oldest ones every week.

FAQ

What is a Kanban board?

A Kanban board is the visual form of a workflow. Each column is a step, each card is a work item, and cards move from left to right as work progresses. The Kanban Guide treats the board as a visualization of the workflow, and the useful boards also show a limit on work in progress for each working column.

What does kanban mean in lean manufacturing?

In lean manufacturing a kanban is a signalling device. The Lean Enterprise Institute defines it as a card or signal that authorizes and instructs the movement or production of items in a pull system. A downstream process uses parts, the card goes back upstream, and only then is more made.

What is the Kanban Method?

The Kanban Method is David J. Anderson's approach to improving how knowledge work is managed, described in his 2010 book. Kanban University says it is applied to an existing way of working and is not a process framework. Its practices include visualizing work, limiting work in progress, managing flow and making policies explicit.

How do you set a WIP limit?

Start from the number of items in progress today, set the limit at or just below it, and tighten it as the team learns. No standard formula exists, and the Kanban Guide leaves the number to the team. Judge a limit by what it does to cycle time and to how often work is blocked.

What is the difference between Kanban and Scrum?

Scrum works in fixed-length iterations with defined roles and estimation. Kanban applies to the existing workflow, has no prescribed roles or iterations, and limits work in progress per workflow state. Henrik Kniberg and Mattias Skarin's 2009 comparison treats them as two tools whose fit depends on the situation, and many teams combine them.

Sources

1. Daniel Vacanti, John Coleman and contributors, The Kanban Guide, May 2025 version (kanbanguides.org)
2. Kanban Guides, version history of The Kanban Guide: July 2020, December 2020, May 2025
3. Daniel Vacanti, John Coleman and contributors, The Kanban Guide, July 2020 version (PDF)
4. Kanban University, The Official Guide to the Kanban Method
5. Kanban University, Get the Official Guide to the Kanban Method, February 2021
6. David J. Anderson, Kanban history, djaa.com
7. Kanban University, case study: Microsoft XIT Sustaining Engineering
8. Toyota Motor Corporation, 75 Years of Toyota: Modernization of Facilities (supermarket method and kanban)
9. Toyota Motor Corporation, Toyota Production System: Just-in-Time and Jidoka
10. Christoph Roser, Twenty-five years after Ohno, All About Lean
11. Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production, Productivity Press, 1988
12. Kaneyoshi Kusunoki, Thinking about buffers and production systems, The Birth of Lean, Chapter IV, Lean Enterprise Institute
13. Lean Enterprise Institute, Lean at heart: kanban
14. John D. C. Little, A proof for the queuing formula L = λW, Operations Research 9(3), 1961 (RePEc record)
15. John D. C. Little, Little's Law as viewed on its 50th anniversary, Operations Research 59(3), 2011, reprint by the Project Production Institute
16. Mark Spearman, David Woodruff, Wallace Hopp, CONWIP: a pull alternative to kanban, International Journal of Production Research 28(5), 1990, reprint by the Project Production Institute
17. Daniel Vacanti, Actionable Agile Metrics for Predictability
18. Henrik Kniberg, Mattias Skarin, Kanban and Scrum: making the most of both, InfoQ, 2009
19. Paulo Sérgio Medeiro dos Santos and others, On the benefits and challenges of using kanban in software engineering: a structured synthesis study, Journal of Software Engineering Research and Development 6, 2018
20. Muhammad Ovais Ahmad, Denis Dennehy, Kieran Conboy, Markku Oivo, Kanban in software engineering: a systematic mapping study, Journal of Systems and Software 137, 2018 (Lero record)
21. University of Helsinki, The Kanban production control system streamlines software production (study of Ikonen and others, ICECCS 2011)
22. Naval Postgraduate School, Two-bin kanban: supply ordering impact at Naval Medical Center San Diego (research poster)

Last updated Oct 9, 2026