How Effective Is the Kanban System?

A Kanban system is effective when three things hold together: work starts only because downstream demand asks for it, every stage has a hard cap on how much can sit in it, and the team watches how long items take to get through. With those in place, inventory and queues shrink and delivery becomes predictable. Without the caps, Kanban turns into a colourful status display that changes nothing.

That is the short answer, and it holds for a car plant and for a software team alike. The longer answer explains why the caps matter so much, how to size them, which numbers prove the system is working, and where Kanban is the wrong tool. This page covers the method from its origin in Toyota's machine shop to the boards used by service desks today, and closes with where Kanban appears in the IASSC Lean Six Sigma bodies of knowledge, because it is one of the Lean controls those exams expect you to understand.

What is a Kanban system, and where did the cards come from?

The Japanese word kanban means signboard. In production, a kanban is a signal that authorises work: make this part, or move this container, in this quantity. The signal was originally a card that travelled with a box of parts, and Wikipedia's account of the kanban scheduling system credits Taiichi Ohno, an industrial engineer at Toyota, with developing it to improve manufacturing efficiency. It is also known in the automotive industry as the Toyota nameplate system.

The idea came from an unlikely place. In the late 1940s Toyota studied supermarkets, where shoppers take only what they need because they trust the shelf will be restocked, and the store restocks only what it expects to sell. Toyota treated each production process as a shopper and the process before it as a store. In 1953 it applied that logic in its main plant machine shop: consumption downstream became the trigger for production upstream.

What a kanban card carries

A classic card names the part, the quantity in one container, where the container is stored, which process makes or supplies it and where it goes next. It carries no forecast and no due date. Its only message is that a container has been used and must be replaced. Because the card is attached to the container, anyone on the floor can count the cards in circulation and know exactly how much stock the loop is allowed to hold.

Production and transport signals

Two kinds of card do most of the work. A production kanban authorises a workstation to make a fixed amount of product. A transport kanban, sometimes called a withdrawal or conveyance kanban, authorises moving a full container to the downstream station. The two together form a loop: the downstream station withdraws a container, which releases a production signal upstream, which replaces exactly what was taken.

From cards to barcodes

Many plants now run electronic kanban, where barcodes and electronic messages replace the paper card. Scanning a container as it is emptied sends the replenishment signal to the store or straight to the supplier, and the same data feeds the planning system. The medium changed; the rule did not. An e-kanban still releases only what consumption has used up, and it still caps how much stock the loop may hold.

How does pull replace push when a Kanban loop runs?

Most planning systems push. A forecast or a schedule decides what each stage should make, and work is released into the process whether or not the next stage is ready for it. When the forecast is wrong, the error turns into piles of half-finished work between stations. Kanban pulls instead: nothing is made or moved until a downstream step has consumed something and sent a signal back.

Question	Push scheduling	Kanban pull
What releases work?	A forecast or a master schedule	A signal that something downstream was used
What limits stock between steps?	Nothing, unless someone intervenes	The number of cards or containers in the loop
What happens when demand drops?	Production continues until the plan is revised	Signals stop arriving, so production stops
Where do problems show up?	Hidden inside inventory	As an empty slot or a waiting card, straight away

Pull is not the same as having no plan. A plant still plans capacity, staffing and the number of cards in each loop. What pull removes is the habit of releasing work because a schedule says so rather than because a customer, or the next process, needs it.

The three-bin loop

The simplest pull system needs no production at all. For bought-in parts, one bin sits on the line, one in the factory store and one at the supplier, each with a card. When the line bin empties, it goes back to the store with its card, and the store hands over its full bin. The store then sends the empty bin and card to the supplier, who returns a full one. The line never runs dry, and the only spare stock in the whole loop is one bin, which covers delays in supply, use and transport.

Toyota's six rules, in working terms

Ohno insisted that kanban only works under strict rules, and Toyota's six are worth reading as operating instructions rather than as theory:

1. Each process sends a request upstream when it consumes supplies. The card goes back as soon as a container is opened or emptied, not at the end of a shift.
2. Each process makes what the requests ask for, in their quantity and sequence. A station does not build ahead because it has spare time.
3. Nothing is made or moved without a request. This is the rule people break first, usually to keep a machine busy.
4. The request stays attached to the item. A container without a card is stock nobody authorised.
5. Defective items are never sent on. Pull leaves almost no buffer, so a bad part stops the next step immediately; quality has to be fixed at the source.
6. Fewer pending requests make the process more sensitive and reveal inefficiencies. Cards are removed deliberately to expose the next problem.

The last rule is the one that turns kanban from a stock-control technique into an improvement engine. Taking one card out of a loop lowers the water level, and whatever rock appears first, a slow changeover or an unreliable machine, becomes the next thing to fix.

Why do WIP limits decide whether Kanban works?

Work in progress, or WIP, is everything started but not finished. A limit on it is the heart of Kanban; the board, the cards and the columns only exist to make the limit visible. The reason becomes clear from a result in queueing theory.

Little's law in plain words

Little's law, which John Little proved in 1961, states that the average number of items in a stable system equals the average arrival rate multiplied by the average time each item spends inside. Rearranged for a production line or a team, average lead time equals average WIP divided by average throughput. Manufacturing uses it routinely to predict lead time from the production rate and the amount of work in process.

A worked example shows why that matters. Suppose a team finishes about four requests a week and has twelve in progress at any moment. On average, a request spends three weeks inside the system. If the team keeps finishing four a week but lets only eight into progress, the same arithmetic gives two weeks. Nobody worked harder. The requests simply stopped waiting behind each other. The figures here are illustrative, but the relationship is exact for a stable system, and it is why teams that cap WIP see lead times fall first and throughput often rise afterwards, as less time is lost to switching between tasks.

How many cards does a loop need?

The same logic sizes a production loop. The stock a loop must hold is the demand rate multiplied by the time it takes to replenish a container, and dividing that by the container size gives the number of cards. Take a line that uses 40 parts an hour, where a used container takes three hours to come back full and each container holds 20 parts: it needs 40 × 3 ÷ 20 = 6 containers in circulation, plus whatever safety margin the plant decides to add for variation. Those numbers are an example, not a benchmark. The point is that the card count is calculated, then lowered one card at a time as the replenishment time improves.

Setting a first limit in an office

Knowledge work has no containers, so teams start from observation. Count how many items are actually in each column today, set the limit slightly below that figure, and watch what happens for a few weeks. If work regularly stalls because a column is full, the limit is exposing a bottleneck, which is the point. Raise a limit only when the evidence shows it is starving the next step, not because a stakeholder wants something started.

The behaviour a limit creates is the real benefit. When a column is full, the people upstream cannot start anything new, so they look downstream and help finish what is blocking the flow. That habit, finishing before starting, is what separates a Kanban system from a to-do list drawn in columns.

Which flow metrics prove a Kanban system is effective?

Effectiveness is a measurable claim, and Kanban comes with its own measures. The Kanban article on Wikipedia notes that problem areas are highlighted by measuring the lead time and cycle time of the whole process and of each step. Four measures cover most needs.

Metric	Clock starts	Clock stops	What a bad trend tells you
Lead time	When the customer asks	When the customer receives it	Requests wait too long before anyone starts them
Cycle time	When work actually starts	When the item is finished	Items stall mid-flow: blockers, hand-offs or oversized items
Throughput	Start of a period, such as a week	End of that period: count items finished	Capacity falls, or WIP is too high to finish anything
Work item age	When work started	Still running (measured today)	A specific item is stuck and needs attention now

Read the spread, not only the average

An average cycle time of six days hides a lot. If most items finish in four days and a few take thirty, customers remember the thirty. Plotting every finished item on a scatter chart shows the spread, and a Kanban team usually states its forecast as a percentile: most items in this class finish within a given number of days. The Kanban Method for knowledge work calls that forecast a service level expectation and lists it among the minimum elements of a Kanban board.

The cumulative flow diagram

A cumulative flow diagram stacks the count of items in each column over time. The vertical gap between two bands shows how much work sits in those states; the horizontal gap roughly shows how long items spend there. In a healthy system the bands rise in parallel. A band that keeps widening means work is piling up in that state, and a flat top line means nothing is being finished. One chart answers the question every manager asks, whether things are getting better, without a status meeting.

How does the Kanban Method work for software and office teams?

Kanban left the factory in the 2000s. David J. Anderson described its evolution in his 2010 book, from a project at Microsoft in 2004 to one at Corbis in 2006 and 2007 where the Kanban Method took shape. In 2020 John Coleman and Daniel Vacanti published The Kanban Guide, which sets out the minimum needed to run a Kanban system in three practices: defining and visualising a workflow, actively managing the items in it, and improving it.

The Kanban Method adds more detail. Its two primary practices are to visualise the work and to limit WIP, and four further general practices follow: make policies explicit, manage flow, implement feedback loops, and improve collaboratively. None of this asks a team to change its job titles or its process on the first day. The method starts from what the team already does and changes it in small, evolutionary steps.

What a working board contains

• A definition of the work item. A ticket, a feature, a claim, a request: one unit of value that moves across the board.
• A clear start and finish. Everything between the two points counts as WIP, including items waiting in a "ready" sub-column.
• Columns for real states. The steps work genuinely passes through, not an idealised process from a slide.
• A limit on each active column, written at the top where everyone can see it.
• Written pull policies. What must be true before an item may move right, often called done rules.
• Swimlanes where they help, such as a lane for urgent incidents that may exceed a limit under an agreed policy.

An example from a service desk

Picture an internal IT team with columns for triage, in progress, waiting on user, testing and closed. Before limits, thirty tickets sat in progress and each engineer juggled six. The team set a limit of two per engineer and a separate lane for outages. Within weeks, the waiting-on-user column became the widest band on their cumulative flow diagram, which showed the delay was not engineering at all but slow replies. The fix was a policy change, automatic reminders and a close-after rule, not more staff. This is the kind of finding Kanban is built to surface.

When does Kanban beat Scrum, and when does it lose?

Scrum organises work into time-boxed iterations called sprints; according to the Wikipedia summary of Scrum, each sprint lasts no longer than a month and commonly two weeks, with defined roles and events. Kanban prescribes no roles and no iterations. The two are often combined rather than chosen between, but the fit differs by situation.

Your situation	Lean towards	Why
Requests arrive unpredictably and must be answered in days	Kanban	A sprint commitment cannot absorb constant interruptions
A new product needs a regular inspect-and-adapt rhythm with stakeholders	Scrum	Fixed reviews force feedback at a steady cadence
Work items vary from one hour to three weeks	Kanban	Flow metrics handle mixed sizes better than sprint forecasts
The team lacks shared goals and focus	Scrum	A Sprint Goal gives a clear, common target
The team already runs Scrum but items stall inside sprints	Both	WIP limits and flow metrics can sit inside the sprint

Where Kanban wins

Operations, maintenance, support desks, content production and any team that serves a continuous stream of requests usually do better with Kanban. There is no artificial wait for the next sprint, urgent work has an explicit lane, and forecasting comes from measured cycle times rather than estimates.

Where Kanban loses

Kanban gives a team less structure. A group with no discipline around limits, no habit of reviewing its metrics and no agreed priorities can drift, because nothing forces a planning conversation. Early product development, where the question is what to build rather than how to deliver it, often benefits from Scrum's fixed review of a working increment. Many teams end up in a blend, sometimes called Scrumban, that keeps sprint events and adds WIP limits and a flow board.

Where does Kanban sit inside Lean and the IASSC belts?

Kanban is one tool within Lean, not a synonym for it. Lean looks at a whole value stream and the waste in it; kanban is the pull mechanism that keeps the stream from overproducing, which Lean treats as one of the seven wastes. In the Toyota Production System, pull through kanban sits beside just-in-time delivery, levelled production and built-in quality.

That placement carries into Lean Six Sigma. IASSC lists kanban as a Lean control in the Control phase, next to control methods for 5S and poka-yoke, which is where a project team uses it to hold an improvement in place once the root cause is fixed. A reduced WIP level that is not protected by a pull signal tends to creep back up within months. The Yellow Belt covers the Define, Measure and Control phases, as IASSC's Yellow Belt certification page explains, so kanban questions reach candidates at the first belt. The Green Belt keeps the same Lean controls and adds statistical process control, as our ICGB syllabus outline shows.

What you face on exam day	Yellow Belt (ICYB)	Green Belt (ICGB)
Full name	IASSC Certified Lean Six Sigma Yellow Belt	IASSC Certified Lean Six Sigma Green Belt
Questions	60	100
Duration (minutes)	120	180
Exam fee (USD)	250	350
Passing score	70	70
Phases in the body of knowledge	Define, Measure, Control	Define, Measure, Analyze, Improve, Control

How kanban tends to be asked

Exam questions rarely ask for a definition alone. Expect a short situation instead: a process that keeps overproducing after an improvement, and a choice between a control chart, a kanban loop, a 5S audit and a mistake-proofing device. The answer depends on the failure. Overproduction and excess WIP point to pull; a defect that escapes points to poka-yoke; drift in a measured characteristic points to a control chart. Being able to say why each tool fits one failure and not another is worth more than memorising lists.

If you are preparing for the first belt, a timed ICYB mock exam is a practical way to check whether you can make those tool choices quickly across 60 questions and two hours.

Which mistakes quietly break a Kanban system?

Kanban rarely fails in a dramatic way. It decays, one reasonable exception at a time, until the board describes the work without controlling it.

• Limits that are never enforced. A limit that the manager overrides every week is a suggestion. Agree in writing when a limit may be exceeded, and review each exception.
• Limits set so high they never bite. If no column has ever been full, the limits are decoration. Lower them until they cause a useful argument.
• Hidden work. Favours, side projects and urgent requests that never reach the board make every metric wrong. If it takes time, it gets a card.
• Pushing work into "ready" columns. Parking a queue of started items just before a full column still counts as WIP; it only moves the pile.
• Measuring only throughput. A team can finish more items while its oldest ones rot. Watch work item age and the spread of cycle times too.
• Never removing cards. In production, the card count set on day one becomes permanent inventory. Toyota's sixth rule exists because the improvement comes from taking cards out.
• Copying another team's board. Columns must describe your own workflow. A borrowed board hides the states where your work actually waits.
• Sending defects downstream to keep the flow moving. Pull depends on quality at the source. Passing on a bad item only moves the stoppage one step later.

Each of these is cheap to fix once seen, and the tools that reveal them are the same ones described above: an honest board, enforced limits and a few flow charts reviewed every week. That, in the end, is how effective a Kanban system is: as effective as the discipline that keeps its limits real.

Frequently Asked Questions

What is a kanban card system?

A kanban card system controls production and stock with signals attached to containers. When a downstream process uses a container, its card goes back upstream and authorises making or moving exactly that quantity again. The number of cards in the loop therefore caps how much stock the loop can hold at any time.

What must be true for a kanban system to work properly?

Work may only be made or moved against a signal, each signal stays with its item, and upstream steps produce in the quantity and order requested. Defects must not be passed on, and the number of cards or the WIP limit is lowered carefully over time to expose the next problem.

Does kanban prevent stockouts?

A correctly sized loop protects against stockouts because replenishment starts as soon as stock is used, and a spare container covers delays. It cannot absorb demand far above what the card count was sized for. If demand rises, the loop must be recalculated or more cards added.

Is kanban covered in the IASSC Lean Six Sigma exams?

Yes. IASSC lists kanban among the Lean controls in the Control phase, together with control methods for 5S and poka-yoke. It appears in both the Yellow Belt and Green Belt bodies of knowledge, usually in questions about holding an improvement in place after a project.

What is the difference between lead time and cycle time in Kanban?

Lead time runs from the moment a customer asks for something until it is delivered, so it includes waiting before work starts. Cycle time runs only from the start of work until the item is finished. A big gap between the two means requests queue too long before anyone picks them up.

Select ratingPoorOkayGoodGreatAwesome

Rating: 5 / 5 (86 votes)