Kanban board and WIP limits
The kanban board spreads a team's tasks across columns according to their state of progress, and the WIP limit is the maximum number of tasks each column admits at the same time. Work in progress, which the tools call WIP, is work started and not finished. Once the column has reached its cap, nothing enters it before a task has left: the team knows, by counting the cards, whether it can start one more. David J. Anderson formalised this transposition of the industrial kanban signal to knowledge work, along with the written policies that make each column crossing decidable.
Goal
The WIP limit caps the number of tasks started at the same time in a given state of the workflow. It is shown at the head of the column, and the board makes it checkable by any reader: the column is full or it is not. A free slot below the limit authorises one more start: this is the pull rule the technique produces.
The problem it addresses is the build-up of started work. A team with no cap answers a new request by opening one more case, which anyone can do without asking anyone. Started work then piles up in the intermediate states, the lead time stretches and an obstacle on one case gets worked around by advancing another instead of being cleared. The cap removes that way out: when the column is full, the only action available is to get out what is already there.
The deliverable is a board whose every column carries a number, with a sheet of written policies posted beside it.
The rule comes from the shop floor's kanban pull system, where the empty bin returned by the consuming station authorises the replenishment. The free slot below the cap plays the part of the empty bin here. The task board carries the same columns with no number at their head. Portfolio Kanban applies the same cap to the initiatives a portfolio holds open at the same time.
Usage
When to use it
- Repeatable flow with identifiable states: each state gets its own cap, set against what it can absorb.
- A team that starts more than it finishes: the cap allows no further start and makes the queue visible.
- A bottleneck suspected without proof: the column that stays full names it within a few weeks.
- Incoming demand of uneven urgency: classes of service settle priority through a written policy instead of a ruling made in a meeting.
- A delivery commitment to hold towards a client or a regulator: the lead time is steered through work in progress, which is a lever the team holds.
- An organisation that refuses a reorganisation: the cap is laid over the existing roles, titles and process, moving none of them.
When not to use it
- Single-state work, with no queue between two steps: nothing to cap, keep a task board.
- Items whose sizes have nothing in common: counting cards measures no workload, set the cap on estimated effort.
Description
Where the limit sits
The cap applies to a column of the flow or to a swimlane inside a column when several types of work share the same state. Each column gets its own number, since the states have neither the same headcount nor the same queue: Anderson sets his examples state by state, an analysis at three, a development at five. A single number laid over the whole board leaves open the question the technique settles: in which column must starting stop?
Three kinds of column consume work in progress and therefore get a number; Anderson treats them together in the chapter "Setting Work-in-Process, Queue, and Buffer Limits". An activity column holds the work a person is carrying out right now. A queue holds what is ready for the next step and waits to be pulled into it. A buffer holds what protects a rare or costly step against running dry, ahead of a committee that sits once a month for instance.
No source gives a universal starting value. Common practice starts from the headcount working in the column, plus one to absorb a wait, then corrects against measurement. The right value is found by watching the board for a few weeks.
The cap assumes the team controls its own assignments. Where a decision from outside reshuffles every day who works on which case, it will be overridden at the first request: the assignment rule is dealt with before the board.
What the limit forbids
The limit knows nothing of the requester's seniority, of the urgency claimed or of the availability of whoever would like to start: the method's official guide states that items wait for capacity to free up, through other items leaving. A board with no number offers no such property, for want of a value to compare the card count against.
Someone who has become free cannot start one more task in a full column, so what remains is to move along what is already there: pick up a review, help finish a case or clear the obstacle holding a card back. The cap makes collective work on the card blocking the flow rational: without it, that time looks wasted, since it could be spent starting something else.
David J. Anderson's school of management is explicit: a blocked item stays in the column where it is blocked and counts towards that column's work in progress, which hampers pulling into it and pushes towards resolving the blockage fast. The same source asks that the escalation policy be agreed with the parties concerned, written down and posted: a delay after which the reminder goes out, a named recipient, a second delay after which the blockage moves up a level.
Setting the limit: Little's law
Little's law, proved by John D. C. Little in 1961 for queues and half a century older than the Kanban method, states that the mean work in progress of a system equals its mean throughput multiplied by the mean time an item spends in it:
Work in progress = Throughput × Lead time, hence Lead time = Work in progress ÷ Throughput. Throughput is the number of items finished per unit of time; lead time is the time elapsed between an item being started and its exit from the system.
At stable throughput, lowering the mean work in progress shortens the lead time in the same proportion. A team under deadline pressure therefore lowers its caps instead of raising them to start more. The relation holds on average and under a steady state, where arrivals and departures balance over the observation window; applied to a single card or to a week of massive intake, it predicts nothing.
The lowering has a floor. Below a certain number, people find themselves with no admissible work; throughput falls in turn and lengthens the very lead time the move set out to reduce. The setting is therefore changed one notch at a time, watching the throughput and lead time pair over several weeks.
The cumulative flow diagram makes the relation readable over time. Plotted on it, day by day, is the cumulative number of items that have entered each column; the vertical gap between two curves gives the column's work in progress on a date, the horizontal gap gives the lead time of an item that left that day and the slope gives the throughput. A band that widens signals a state absorbing less than it receives, often weeks before anyone complains about it.
The policies that make the rule decidable
The number on display is not enough, because what is allowed to enter a column and to leave it still has to be settled. The official guide asks for policies that are few, simple, well defined, visible, always applied and easy to change. Five of them carry the technique: each column's limit, each column's entry and exit criteria, the replenishment rule at the head of the flow, the handling of blocked cards with its escalation and the classes of service.
Classes of service handle urgency without breaking the cap. Anderson describes this in the chapter "Establishing Service Level Agreements via Classes of Service": work is split into types, among them standard, fixed delivery date and expedite, each carrying a handling rule agreed in advance. A card in the expedite class may go above the cap, provided the policy has foreseen it and sets its price. The going price is a single expedite at a time across the whole system, the slot freed next staying empty until that expedite leaves. An exception argued in a meeting produces the opposite effect, since it teaches everyone that the rule gives way to insistence.
What makes the technique fail
The cap raised to end the discomfort
A column stays full and the team moves the limit from three to five so as to get back to work. The saturation was the measure of a capacity imbalance between two states; removing it erases the information without touching its cause, and work in progress returns to the level it had before the board went up. A rise in the cap is justified by a change of headcount or of scope, never by the discomfort it causes.
The blocked card set aside
A "waiting" column or an "on hold" swimlane outside the cap takes in the obstructed cases, and the board flows again at once. The cases sit there for weeks, since nothing depends on their leaving any more. A blockage is handled in the column where it arises, the card keeping its slot and the escalation running from its blocking date.
Cards split to keep the count
A team capped at four breaks its cases into sub-cards and holds eight. The number then stops measuring anything at all, and the cumulative flow diagram describes a population whose mean size is changing. Splitting a card is a legitimate flow decision, provided it changes the card size durably and openly and does not serve to absorb a peak of load.
The cap displayed without being held
The tool flags the breach with a highlight and nobody backs down, because the card too many comes from a director. A few breaches of that kind are enough to reduce the board to a display. The answer is written before the first request of the kind: who is entitled to refuse a card and under which class of service a pressing request may pass.
AI considerations
The history of card transitions, which every board tool keeps, is a source a model can work on. It draws from it the daily distribution of work in progress per column and names the columns whose cap was never reached, where the number on display steers nothing, as well as those that stayed full more than half the time. The lead time computed per class of service and per case type gives the material for a quantified delivery commitment. It builds the cumulative flow diagram, signals a band widening as soon as it exceeds the usual variation and picks out the cards blocked beyond the escalation delay, whose reminder it drafts with its recipient.
A simulation replaying the history with the cap lowered one notch gives an estimate of the lead time and the idle time that would result, which replaces a debate of opinion with a range.
Three things cannot be delegated. The cap is a commitment made between people who will have to hold it in front of an unhappy requester; a number set by a tool without the team's agreement falls at the first pressure. A model that assigns cards to people restores the push flow that pulling removes, since the card then arrives without a slot having been freed. Lastly, the cards on a board carry client names, amounts and sometimes health data; they are anonymised before any transfer to an external service, and the case reference is enough for most analyses.
Examples
The claims department of a French-speaking Swiss insurer keeps one board shared by its handlers. The technique produces there the policy sheet posted beside the board: one cap and two criteria per column.
| Column | Limit | Entry criterion | Exit criterion |
|---|---|---|---|
| To handle | 6 | Claim registered, policy and cover checked | A named handler takes the card, a slot being free in Investigation |
| Investigation | 4 | Minimum documents present: signed claim form, incident report, receipts | Cause established and amount estimated, written on the card |
| External appraisal | 2 | Estimated amount above CHF 50'000 or cause disputed | Appraisal report received and filed with the case |
| Decision and payment | 3 | Case complete, with or without appraisal | Decision notified to the insured and payment order sent |
| Closed | none | Payment executed or refusal notified | not applicable |
The classes of service take up the second half of the sheet.
| Class | Entry criterion | Handling rule |
|---|---|---|
| Standard | Any case not falling under the other two classes | Pulled in order of entry into the queue |
| Fixed date | An enforceable contractual or statutory response deadline | Pulled with priority ten working days before the due date |
| Expedite | Emergency rehousing, harm to health, building uninhabitable | One card at a time across the whole board, admitted above the cap; the next slot freed stays empty until it leaves |
A handler finishes a card in Decision and payment. External appraisal shows 2 of 2, one of them a card blocked for nine working days on an appraiser's report; the escalation policy provides for a reminder at five days and a referral to the head of claims at ten. No card in Investigation can therefore move down, and the handler now free spends the afternoon preparing the referral rather than opening a new case.
Over the quarter, the team closed 4 cases a week with a mean work in progress of 8 cards between Investigation and Decision, that is a mean lead time of 8 ÷ 4 = 2 weeks or 10 working days. The Investigation cap goes from 4 to 2 and the mean work in progress falls to 6 cards: at unchanged throughput, the mean lead time comes down to 6 ÷ 4 = 1.5 weeks. The mean serves the steering: it says which way the change of cap moved the lead time. The commitment announced to the insured is taken on a percentile of the observed distribution, 15 working days held for 85% of cases for instance, since a mean promised says nothing about how many cases exceed it. Throughput is watched for six weeks before the next notch, a drop signalling that the cap has come down below what the team can feed.
Visualisations
The main figure shows the board with the slots drawn under each column header, the cap written at the head in the form occupied over limit. One column there is at its cap, with one of its cards marked blocked. The reader must take two facts from it at a glance: a full column bars entry from the upstream column and a blocked card does not give its slot back.
The cumulative flow diagram is drawn as stacked areas, one per column, on a date axis. The two gaps, vertical and horizontal, are read off the same chart, which is the reason to use it rather than two separate curves.
The policy sheet is rendered as a table, one row per column of the flow, since its content is text and compares row by row.
Cost
| Phase | Level | Justification |
|---|---|---|
| Preparation | Medium | Describing the real states of the flow, then agreeing the entry and exit criteria of each column, takes two or three workshops: this is where the disagreements over what "finished" means come out. |
| Execution | Low | Checking is done by counting the cards in a column, with no meeting and no extra tool. What costs is the discipline of refusal. |
| Documentation | Low | The policies fit on one sheet posted beside the board. The recurring cost is limited to dating a changed cap and posting it again. |
Tooling
The physical board is chosen for the constraint it imposes. Slots marked out in tape under each header make the cap material: a fifth note in a column that holds four is visible from the other end of the room. A co-located team starts there, entering things into a tool afterwards if need be.
Work management tools, among them Jira, Azure Boards and Trello, carry a limit per column and flag a breach with a highlight. They warn without forbidding: a hard block on the card stays rare, so holding the rule remains a social matter. The useful setting is to cap the flow column and not the whole board, which some tools propose by default.
Kanban-specialised tools, among them Businessmap (formerly Kanbanize) and Kanban Tool, add what the previous ones make laborious: cumulative flow diagram, lead time histogram, caps per swimlane and tracking of blocking durations. They earn their place as soon as the team sets its caps on measurements rather than on an impression.
A spreadsheet covers the measurement need when the tool offers none: a daily reading of the card count per column is enough to build the cumulative flow diagram and to compute the lead time through Little's law. A few minutes a day for two months give what is needed to decide on a cap.
Sources
- David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, Blue Hole Press, 2010, ch. "Setting Work-in-Process, Queue, and Buffer Limits": the cap laid state by state, as well as the separate treatment of activity columns, queues and buffers.
- David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, Blue Hole Press, 2010, ch. "Establishing Service Level Agreements via Classes of Service": the types of service, among them standard, fixed delivery date and expedite, and the handling agreed in advance that attaches to each.
- Kanban University, The Official Guide to The Kanban Method: the free slot below the cap as the pull signal, the wait until capacity is freed and the criteria explicit policies have to meet.
- David J. Anderson School of Management, Kanban Evergreen: Should We Include Waiting or Blocked Items in WIP Limits?: a blocked item stays in its column and keeps counting towards that column's work in progress; the escalation policy is agreed with the parties concerned, written down and posted.
- John D. C. Little, "A Proof for the Queuing Formula: L = λW", Operations Research 9(3), 1961, pp. 383-387: the proof of the relation between mean work in progress, mean throughput and mean time in system, independent of kanban and older than it.