Kanban WIP Limit¶
Visual board tool — instantiates Work-in-Progress Limiting
Caps the number of items allowed in each column of a work board, so no stage can start more than it can finish and congestion shows on sight.
A Kanban WIP Limit is a maximum count written on a column, lane, or stage of a work board: Editing (2), Testing (3). A card may enter a column only while that column sits below its cap, so the limit governs not just what can start but what can move — a full column pulls attention backward toward finishing rather than forward toward starting. What makes it this mechanism and not a plain cap is that the limit is attached to workflow stages and rendered visibly: the board itself shows, at a glance, which stage is jammed and where new work must not go. It splits one global constraint into per-stage caps so local congestion becomes specific enough to act on, and it turns the limit from a private policy into a shared artifact everyone can watch being honored or broken.
Example¶
A six-person content team runs everything through a wall board: Backlog → Drafting (3) → Editing (2) → Design (2) → Published. On Tuesday a writer finishes a draft and reaches for the next brief — but Drafting is already at three and Editing is full at two, with one piece stuck waiting on a subject-matter review. Under the old no-limit board she would simply have started a fourth draft, and the team's "in progress" pile would have swollen to eleven half-written articles that shipped weeks late. The WIP limit forbids the start. Instead the visible jam in Editing pulls two people over to clear the stuck review, the column drops to one, and only then does a slot reopen upstream. Nothing about the team got faster; the board just stopped letting them start what they couldn't finish, and completed work began leaving the board at a steady rate.
How it works¶
- Caps live on columns, not on the person or the system as a whole. Each stage carries its own number, so the constraint is local and specific.
- Entry is gated by the cap; exit frees it. A card moves into a stage only while that stage is under its limit, and finishing or pulling a card onward is what makes room.
- The breach is visible. A column at or over its cap is shown as full — a count, a color, a hard row — so honoring or breaking the limit is a public act, not a private judgment.
- Congestion is read off the board. A persistently full downstream column tells the team where not to push next — a cue to stop feeding the jam — rather than a plan to re-engineer the stage.
Tuning parameters¶
- Column granularity — how finely the workflow is split into capped stages. Finer stages localize congestion precisely but multiply the numbers to maintain and can fragment flow.
- Limit value per column — the actual cap on each stage. Lower forces finishing sooner and exposes blockers faster, but idles capacity if set below what the stage can truly carry.
- Lane vs. column vs. per-person caps — whether the limit binds a stage, a swimlane (a class of work), or an individual. Per-person caps curb individual overload; per-column caps protect flow.
- Buffer and "done" sub-columns — whether to insert a ready/done buffer between stages. Buffers smooth hand-offs but re-admit hidden WIP if left uncapped.
- Enforcement hardness — a hard stop that blocks the move versus a soft warning the team may override. Hard caps bite but invite gaming; soft caps inform but erode.
When it helps, and when it misleads¶
Its strength is that it makes flow and its absence visible and shared: everyone can see the jam, see the limit, and see whether it is being honored — which is what converts a good intention into a constraint that actually changes behavior. Kanban's roots are in Toyota's supermarket-style pull system, where a downstream shelf emptying, not an upstream forecast, authorized the next replenishment.[n1]
Its failure modes are mostly social and mostly about the number. Limits set by feel rather than by observed throughput drift into either theater (a cap nobody honors) or throttling (a cap set below real capacity); keeping them honest is a separate job. Teams game the board — splitting a card in two to slip under a cap, or parking work in an uncapped buffer — so the visible count stops meaning what it claims. And the classic misuse is to raise every limit whenever the board jams, quietly rewriting the constraint to ratify the current overload instead of confronting it. The discipline that guards against this is to treat the numbers as provisional and set them from measured flow, and to make blocked work trigger finishing rather than a fresh start.
How it implements the components¶
Kanban WIP Limit fills the stage-level, visible-cap slice of the archetype — the components a board can physically carry:
wip_limit— the per-column maximum count is the cap itself, in its most literal form.stage_capacity— its signature move: it distributes the limit across workflow stages, so congestion is local and specific rather than a single global number.active_work_boundary— the columns draw the line between backlog, active, blocked, and done, giving "in progress" an exact, visible extent.limit_breach_signal— a full or over-cap column is shown on the board, making a breach a public event the moment it happens.
It does not decide the number (capacity_basis → Concurrency Limit and Throughput-Based Limit Review), authorize the next pull when a slot opens (admission_control_rule, pull_replenishment_signal → Pull Replenishment Signal), or say what happens when a card blocks (completion_bias_rule, blocked_work_policy → Blocked Work Swarming).
Related¶
- Instantiates: Work-in-Progress Limiting — the board is the archetype's most recognizable face, making active-work scarcity visible and per-stage.
- Consumes: Pull Replenishment Signal — a freed column slot is what authorizes the next card to be pulled in.
- Sibling mechanisms: Concurrency Limit · Blocked Work Swarming · Active Case Cap · Project Portfolio Limit · Team Workload Cap · Sprint Capacity Rule · Pull Replenishment Signal · Work Slot Token · Throughput-Based Limit Review
Editorial Notes¶
Form Classification¶
Form family: Rule, Policy & Commitment
Rationale: The mechanism imposes a standing cap on items allowed in each workflow stage so no stage starts more than it can finish.
Nearest alternative: Control, Automation & Runtime — A board can enforce the cap live, but the operative form is the persistent work-in-progress constraint.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Lean production and later agile management formalized visible stage-specific work-in-progress limits.
Related originating lineages:
- Computer Science & Software Engineering — Software-development kanban materially shaped board-based limits outside manufacturing.
- Operations Research — Queueing theory supplied the throughput and congestion rationale for limiting WIP.
Review resolution: Both independent reviews place the primary lineage in organizational_management. The queued differences (alternate_origin_disagreement) concern secondary metadata rather than primary provenance. The final retains computer_science, operations_research only where a reviewer supplied a formative-lineage rationale; downstream application by itself is not treated as origin. origin_mode=cross_disciplinary_synthesis records the relationship among origin traditions, while domain_reach=multi_domain records application breadth separately. encyclopedia_synthesis=false reflects whether either reviewer identified a corpus-specific synthesis, and confidence=high preserves the more cautious evidence assessment.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
Per-column caps surface where work is piling up, but Kanban WIP Limiting only limits — it declines to feed a jammed stage. Diagnosing why that stage is the constraint and relieving it is a separate discipline; the board's job is to stop the queue growing while that work happens elsewhere.
[n1] Kanban (Japanese for "signboard") originated in the Toyota Production System, where Taiichi Ohno adapted the way a supermarket restocks a shelf only when customers empty it — a downstream pull authorizing upstream replenishment — into a production-control signal. The board mechanism inherits that logic: capacity opening, not demand arriving, is what lets the next item start. ↩