WIP Board¶
Visual board — instantiates Backlog Visibility
Lays the queue out as stage columns with a cap on each, making waiting-by-stage and the bottleneck column visible at a glance.
Every other view treats the backlog as one pool; the WIP Board breaks it open by stage. It lays work out as cards moving left to right through named columns — the steps each item passes through — so you can see not just how much is waiting, but where in the flow it is piling up. Its defining move is spatial and columnar: the position of a card is its state, the height of a column is the queue at that stage, and a per-column limit turns each column into a threshold that visibly fills and blocks. Where a dashboard shows numbers and a report shows totals, the WIP board shows the pipeline — which handoff is the constraint — and it does so by geometry rather than by metric, legible to anyone who walks past.
Example¶
A digital newsroom moves every story through the same pipeline: Pitched → Assigned → Drafting → Editing → Fact-check → Ready → Published. Stories keep "disappearing" for days, and no one can say where. The desk builds a WIP Board with a column per stage and a cap on each — Editing limited to 4, Fact-check to 3. Within a week the geometry tells the story: the Fact-check column is jammed to its limit and stories are stacking in Editing behind it, unable to move forward because the next column is full and its own cap forbids piling on. The board makes the bottleneck a place you can point at — one overloaded fact-checker — rather than an abstract "we're slow." Each column also doubles as an ownership map: cards in Drafting belong to writers, in Fact-check to the checker, and any card with no assignee shows as an unclaimed slot. The editor moves a second checker onto the jammed column, the stack drains, and the pipeline flows — a decision the board made obvious by showing where the waiting lived, not merely that it existed.
How it works¶
- Model the flow as columns. Define the real stages an item passes through and give each its own column; the board is only as truthful as the stages match how work actually moves.
- Let position carry state. A card's column is its status and a card's owner is visible on the card, so the board is simultaneously a stage view and a who-holds-what map — no separate status field needed.
- Cap each column. Set a work-in-progress limit per column so it can visibly fill; a full column blocks upstream work and makes the constraint self-announcing.
- Watch where cards stack. The tallest column against its cap is the bottleneck; the board's whole diagnostic value is that this is visible spatially, before any metric is computed.
Tuning parameters¶
- Column granularity — how finely the flow is split into stages. Fine columns pinpoint the exact bottleneck but crowd the board; coarse columns are readable but blur where work stalls.
- WIP limit height — the cap on each column. Tight limits expose constraints fast and force flow but can idle people; loose limits keep everyone busy but let hidden queues build inside a column.
- Card-to-owner mapping — whether ownership is shown by column, by avatar, or by swimlane. Clearer ownership aids pickup but a busy board can bury it.
- Blocked marking — how a stuck card is flagged in place (a marker, a colour). Prominent marking surfaces blockage but too many markers become wallpaper.
- Board scope — one team's pipeline vs. an end-to-end cross-team flow. Wider scope reveals cross-team handoff stalls but grows unwieldy and blurs ownership at the seams.
When it helps, and when it misleads¶
Its strength is making the constraint visible as a location. Because a capped column physically fills and blocks, the board surfaces the bottleneck stage the way Theory of Constraints insists you must find it — the single step whose limited throughput governs the whole flow — without anyone computing a rate.[1] It also makes stage-level ownership and blockage impossible to overlook, because they are drawn where the work sits.
Its failure mode is that a board only shows the flow it was drawn to model: if the real work detours through stages the columns omit, or waits in a side pool the board doesn't render, the board looks orderly while work hides off-board. WIP limits can also be quietly violated — cards crammed past the cap, or a "parking lot" column invented to dodge it — which restores the very invisibility the limit was meant to prevent. And a board rich with cards can still hide age: a card's column tells you its stage, not how long it has festered there. The guarding discipline is to keep the columns faithful to how work truly moves, to honour the limits rather than route around them, and to pair the board with an age view so a card stalled in place for weeks is not mistaken for one merely in progress.
How it implements the components¶
The WIP Board fills the stage-and-limit slice of the archetype — flow geometry — and leaves the numbers and cadence to its siblings:
ownership_map— each card shows its owner and each column its responsible stage, so the board doubles as a live who-holds-what-where map that exposes orphaned cards and overloaded stages.visibility_thresholds— the per-column WIP limit is a threshold made physical: the column fills to its cap and blocks, announcing the constraint without a computed metric.
It does not implement priority_distribution or cross_queue_rollup — the class-mix and multi-queue single-pane display are Queue Dashboard; the board renders one pipeline by stage, not many queues by number. Nor does it implement backlog_metrics: the counted measures of the board's columns are defined by Queue Health Metrics, while the board shows position and fill rather than computing rates.
Related¶
- Instantiates: Backlog Visibility — it makes waiting-by-stage and the bottleneck column legible through layout rather than metric.
- Sibling mechanisms: Aging Report · Backlog Report · Burn-Down or Drain Chart · Exception Queue Audit · Queue Dashboard · Queue Health Metrics · Ticket Aging View · Service-Level Monitor
Editorial Notes¶
Form Classification¶
Form family: Interface, Display & Cue
Rationale: WIP Board operates as a user-facing prompt, display, template, or perceptual cue that shapes attention and action at the point of use because it lays the queue out as stage columns with a cap on each, making waiting-by-stage and the bottleneck column visible at a glance.
Independent corroboration: The frozen evidence defines WIP Board as 'Lays the queue out as stage columns with a cap on each, making waiting-by-stage and the bottleneck column visible at a glance', so its operative form is Interface, Display & Cue.
Nearest alternative: Monitoring, Sensing & Alerting — WIP Board includes features of ongoing observation, sensing, or alerting that detects and surfaces state without itself executing the response, but its defining operation is a user-facing prompt, display, template, or perceptual cue that shapes attention and action at the point of use.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Operations Research
Origin pattern: Single lineage
Present-day reach: Universal
Rationale: Displaying work by process state while limiting each stage is visual flow control from Kanban and queue management. The official Kanban guide defines workflows, state-specific WIP limits, pull capacity, and visible bottlenecks; management supplies local policy but the operative mechanism is constrained flow.
Related originating lineages:
- Computer Science & Software Engineering — computer_science contributes computer science and software-engineering practice to this mechanism's defining operation—Lays the queue out as stage columns with a cap on each, making waiting-by-stage and the bottleneck column visible at a glance—without displacing the selected primary historical lineage.
- Engineering & Design — Engineering design, reliability, and systems-safety practice has a distinct contributing or parallel lineage for the mechanism's defining operation: lays the queue out as stage columns with a cap on each, making waiting-by-stage and the bottleneck column visible at a glance.
- Human-Computer Interaction — Human-computer interaction and interface design has a distinct contributing or parallel lineage for the mechanism's defining operation: lays the queue out as stage columns with a cap on each, making waiting-by-stage and the bottleneck column visible at a glance.
- Organizational & Management Science — Organizational design, management, and operational governance has a distinct contributing or parallel lineage for the mechanism's defining operation: lays the queue out as stage columns with a cap on each, making waiting-by-stage and the bottleneck column visible at a glance.
- Systems Thinking & Cybernetics — Systems science's feedback, boundaries, stocks, flows, and regulation tradition supplies an independent formative lineage for the mechanism's wip board logic.
Review resolution: The blind reviewers disagree on primary lineage (organizational_management versus operations_research). Authoritative or primary research supports operations_research as the best historical origin: Displaying work by process state while limiting each stage is visual flow control from Kanban and queue management. The official Kanban guide defines workflows, state-specific WIP limits, pull capacity, and visible bottlenecks; management supplies local policy but the operative mechanism is constrained flow. The cited Kanban University, The Official Guide to the Kanban Method directly supports the mechanism's defining operation. All independently supported contributing domains are retained without an arbitrary cap. origin_mode=single_lineage records lineage, while domain_reach=universal records later applicability separately from provenance.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
The WIP board is the one sibling that can also serve a different archetype — Work-in-Progress Limiting — because its column caps do double duty: here they make the bottleneck visible, there they constrain active work. Read as backlog visibility, the limit is a diagnostic that exposes where work waits; read as WIP limiting, the same limit is the control that throttles intake. The board is the shared artifact; which archetype it serves depends on whether the cap is there to reveal or to restrain.
References¶
[1] Goldratt, E. M. What Is This Thing Called Theory of Constraints and How Should It Be Implemented?. North River Press (1990). Defines Theory of Constraints around identifying the system bottleneck whose limited capacity governs overall throughput. registry ↩