WIP Limits

Most teams start more work than they can finish. New requests arrive, urgent issues interrupt, and it feels productive to pick up something new while waiting for a review or an answer. The result is a board full of half-done work, constant context switching and long delays before anything reaches customers. WIP limits, short for work in progress limits, are the simple countermeasure. They set a maximum number of items allowed in progress at once, so the team must finish something before it starts something else.

WIP limits are a core practice of the Kanban method, developed for knowledge work by David J. Anderson in the mid-2000s from ideas in lean manufacturing. They are now used in Scrum teams, operations teams, platform teams and portfolio management, where limits apply to large initiatives rather than tasks. They can apply to any workflow in which people juggle more work than they can finish at once. For engineering managers, delivery leads and agile coaches, WIP limits are one of the most effective and least expensive ways to speed up delivery, captured in the Kanban saying "stop starting, start finishing."

Definition of WIP Limits

WIP limits are policies that set the maximum number of work items allowed in a given workflow state, for a team or for an individual at any time, so that new work is only pulled in when existing work is completed or moved forward.

They are a defining practice of Kanban, are justified by Little's Law and are one of the most direct levers for reducing cycle time.

Types of WIP Limits

Column limits cap the number of items in a single workflow stage, such as In Review or Testing. They are the most common form and show exactly where work is piling up.

Team limits cap the total number of items in progress across the whole workflow, which keeps overall load under control.

Individual limits cap how many items each person has in progress, often one or two, to reduce context switching.

Portfolio limits cap the number of large initiatives or epics underway at once, applying the same logic to strategic work, often through a portfolio Kanban.

How WIP Limits Create Pull

Without limits, work is pushed into the system whenever it arrives. With limits, a stage pulls new work only when it has capacity.

When a stage reaches its limit, people upstream stop starting new work and help clear the bottleneck instead.

This turns a full column from a hidden delay into a visible signal that the team needs to act. Over time, pull systems also make delivery more predictable, because work moves at the pace the team can sustain rather than the pace at which requests arrive.

Importance of WIP Limits in Delivery Management

WIP limits shorten delivery times. Fewer items in progress means each item spends less time waiting, which is the main source of delay in most workflows.

They expose bottlenecks. When a column keeps hitting its limit, the constraint is obvious, and the team can fix it rather than work around it.

They also reduce the cost of context switching. People who juggle fewer tasks finish each one faster and with fewer mistakes. Quality tends to improve as well, since people have time to finish work properly instead of rushing between tasks.

WIP Limits and Financial Management

Partly finished work represents investment that has not yet produced value. Limiting it reduces the amount of capital tied up in unfinished work.

Faster completion lowers the cost of delay for features and fixes that generate revenue or savings.

Portfolio WIP limits prevent funding from being spread across too many initiatives, each moving too slowly to pay off.

Because they require no new tools or headcount, WIP limits are among the cheapest delivery improvements available.

Common Challenges

Teams often set limits so high that they never constrain anything. A limit that is never reached has no effect.

Under pressure, people may ignore limits or create side channels for urgent work. Agreeing on how expedited work is handled helps keep limits credible.

Limits can feel uncomfortable at first, because people may be idle while waiting for a bottleneck to clear. Using that time to help clear it is the point. Leaders sometimes resist limits because they want every request started immediately. Showing the effect on cycle time with real data usually helps.