Local and System WIP Limits

Local and System WIP Limits refers to the distinction, and the deliberate coordination, between work-in-progress limits applied to individual stages of a workflow (local limits) and work-in-progress limits applied to the entire end-to-end process (system limits). This distinction exists because optimizing the flow of a single stage in isolation does not guarantee, and can even undermine, the smooth flow of the whole system, so Agile flow control practices treat these two levels of limit as related but separate concerns that must be managed together.

Defining the Two Levels

Local WIP Limits

A local WIP limit constrains the number of items permitted within a single column, stage, or activity of a workflow, such as "In Development" or "In Testing." Local limits are set by teams close to the specific stage, using their direct knowledge of the capacity and typical duration of work at that point.

System WIP Limits

A system WIP limit constrains the total number of items permitted to be active anywhere across the entire workflow, from initial commitment through final delivery. A system limit does not care which stage an item occupies; it only cares how many items, in total, are currently underway across the whole value stream.

Why Local Optimization Is Insufficient

The Risk of Local Efficiency, Global Slowdown

A stage can appear highly efficient by its own local measures — for instance, keeping its column full and its people constantly busy — while still contributing to a slower overall system, because items may sit queued between stages even when no single stage looks overloaded. Local WIP limits alone cannot detect this cross-stage queuing effect.

Constraint Shifting

When a local limit is tightened at one stage without regard to the system, the constraint frequently just shifts to the next stage rather than disappearing, producing a new bottleneck instead of resolving the underlying flow problem. System-level thinking is required to see this shift.

Queue Accumulation Between Stages

Local limits typically govern items actively being worked on within a stage, but they do not always account for items waiting in a queue immediately before or after that stage. A system WIP limit, applied across the whole workflow, captures this queued work as part of the total in-progress count, giving a more complete picture of accumulation.

Coordinating Local and System Limits

System Limit as the Governing Ceiling

In coordinated flow control, the system WIP limit acts as the overall ceiling, and the sum of local limits across all stages is designed to stay consistent with it. This ensures that even if every stage is individually at its local limit, the total amount of work underway remains within a level the system can sustain end-to-end.

Local Limits Tuned to Relative Capacity

Because different stages of a workflow often have different processing capacities, local limits are not simply divided evenly; they are tuned so that stages known to be slower or more resource-constrained receive tighter local limits, reducing the likelihood that work piles up faster than it can be processed.

Adjusting One in Response to the Other

When flow metrics reveal that a particular stage is consistently the constraint, teams often first adjust the local limit at that stage, and only revisit the system limit if tightening local limits proves insufficient to restore smooth flow across the whole value stream.

Diagnostic Value of the Distinction

Isolating Bottlenecks

Comparing local WIP levels against local limits, stage by stage, helps pinpoint precisely where accumulation is occurring, which is diagnostic information that a single system-wide number cannot provide on its own.

Detecting System-Level Overload

Comparing total active work against the system limit reveals whether the organization has taken on more work than the entire process can absorb, a condition that can exist even when no individual stage has exceeded its local limit, because small excesses at many stages can add up to system-level overload.

Visual Representation

In this diagram, three stages carry different local limits — two, four, and three items respectively — while the dashed boundary represents the overall system limit of nine, matching the sum of the local limits. This alignment is expressed as:

where each ${\text{Local Limit}}_i$ corresponds to the constraint set for stage $i$. Managing both levels together, rather than either one alone, is what allows Agile teams to control flow reliably across the full value stream.