Agile · Letter W

WIP Limits

A Kanban discipline that caps the number of work items in progress at each stage, forcing teams to finish before starting and exposing the bottlenecks that quietly destroy flow.

By Dr. Hassan Eliwa, PhD · Founder of PMMilestone.org and PMMilestone.com · Updated 2026-06-23

Definition

WIP limits — Work-In-Progress limits — cap the number of work items allowed in any given stage of a workflow at one time. The rule is simple: if a column is at its limit, no one can pull new work into it; instead, they must help finish what's there. WIP limits originated in lean manufacturing (Toyota, again) and became central to Kanban for knowledge work after David Anderson's 2010 book. They are the single most counter-intuitive and most effective lever in lean and agile production.

Why They Work

Most teams start too much work and finish too little. Multitasking feels productive but its real effect is to inflate cycle times, hide bottlenecks, and stretch every item into a long, slow journey through the system. WIP limits force the team to finish before starting. The first time a developer can't take a new ticket because the testing column is full — and instead picks up testing — the team learns viscerally why the rule exists. Little's Law makes the maths precise: cycle time = WIP ÷ throughput. Lower WIP, lower cycle time. There is no exception.

Real-World IT / Agile Example

A 9-person dev team I worked with averaged 11-day cycle times despite a 2-week sprint cadence — items routinely spilled over because too many were in flight. We capped In Progress at 5 and In Review at 3 (team size minus one for each). Within three sprints, cycle time fell to 4.5 days and sprint completion rose from 65% to 92%. Nothing changed about the work itself; we just stopped starting too many things. The team's energy went into finishing instead of juggling.

Real-World Construction Example

Construction's WIP-limit analogue is keeping the number of open work fronts under control. On a hospital tower I audited, the contractor had 47 active work zones across 22 floors — material everywhere, trades stepping on each other, quality issues climbing. Capping open zones at 18 (and finishing before opening new ones) cleaned the site, lifted productivity 14%, and cut rework. The takt-planning literature calls this "zone WIP" but the principle is identical: limit how much you're touching at once.

How to Set WIP Limits

  • Start with team size − 1 per active column. Forces some helping-out.
  • Watch what happens. If items still pile up in a column, lower the limit. If the team is genuinely idle, raise it.
  • Set them per column AND for the whole board. A board-wide cap prevents shuffling work around to look busy.
  • Re-tune monthly. Team size, codebase, market conditions change. Limits should evolve.
  • Make breaches visible. A red flag on the board when a limit is exceeded is more powerful than any policy.

Project Controls Perspective

Controls teams report WIP, throughput, and cycle time together — the three flow metrics that, between them, describe whether a system is actually delivering or just looking busy. A team with high WIP, low throughput, and high cycle time is a system in trouble regardless of how green its dashboards look. WIP limits are the lever that turns those three metrics around faster than any other intervention I know.

Common Mistakes

  • No limit, or too high. A WIP "limit" that's never reached isn't a limit.
  • Lowering limits without lowering inflow. Work piles up upstream; the team learns to ignore the rule.
  • Treating limits as targets. The limit is a ceiling, not a quota; teams that fill to the limit by default miss the point.
  • Inconsistent enforcement. Managers who exempt "their" work from limits destroy the discipline.
  • Blocked-work amnesia. Items blocked for days count against WIP; failing to escalate blocks turns the column into a graveyard.
  • Adding stages to dodge limits. Splitting "In Progress" into three columns to fit more work is a classic cheat.

Expert Tips

  • Use Little's Law explicitly. If your goal is a 5-day cycle time and you throughput 2 items/day, your WIP cap is 10. The maths is the maths.
  • Limit per person where it helps. "No more than two stories per developer in flight" is a stricter, often clearer rule than a column-wide cap.
  • Make blocks loud. Visible block markers and an SLA for resolving them protect the WIP limit's value.
  • Pair WIP limits with daily flow review. Stand-ups focused on "what's stuck" not "what I did" reinforce the discipline.
  • Communicate to stakeholders. Stakeholders who don't understand WIP limits will lobby to bypass them; teach them Little's Law and they become allies.

Key Takeaways

  • WIP limits cap items in progress per stage; the rule is finish before starting.
  • Little's Law guarantees that lower WIP means lower cycle time, given stable throughput.
  • They are counter-intuitive and uncomfortable for two weeks — and transformative thereafter.
  • Apply equally well to software (tickets) and construction (open work zones).
  • Limits are ceilings, not targets, and require visible enforcement to survive.

Related Encyclopedia Entries

Related Research Articles, Case Studies & Tools

Pair this entry with hands-on resources and field-tested artefacts:

Frequently Asked Questions

  • What's a good starting WIP limit?
    Team size minus one per active column is a safe starter. For a 6-person team, that's 5 in development, 5 in review. Tune from there based on what the board actually shows.
  • What happens when a column hits its limit?
    Nobody pulls new work in. The team finds a way to finish or unblock existing items — reviewing each other's code, pairing on the stuck item, helping QA. That redirection of effort is the point.
  • Don't WIP limits slow the team down?
    They slow starting and speed up finishing. Throughput rises because work flows through to Done rather than ageing in In Progress. Cycle time drops. The feeling of being slower is an illusion produced by the loss of multitasking dopamine.
  • How do WIP limits interact with sprints?
    Cleanly. Sprint planning chooses the items; WIP limits control how many are in flight at once. Many teams keep a sprint cadence for planning and a Kanban flow with WIP limits for execution. The two complement each other.
  • What about urgent / expedite items?
    Reserve one expedite slot above the normal limit, with explicit policy: only one at a time, and only for genuine emergencies. Without a rule, every item becomes urgent and the limit dies.
  • How do I handle a blocked item?
    It still counts against WIP. The team must escalate or work around the block, not start something new. A long-blocked item is a controls signal — escalate it, don't hide it.
  • Do WIP limits apply to non-software work?
    Yes. Construction zones, design reviews, marketing campaigns, recruitment pipelines — anywhere work flows through stages, WIP limits help. The principle is universal; the tooling varies.
  • How aggressive should WIP limits be?
    Tight enough that they bite occasionally. If you never hit the limit, it's too loose. If you hit it every day and work piles upstream, it may be too tight or your inflow is too high. Tune until breaches happen weekly but flow improves.
  • Which calculators on PMMilestone.org apply to WIP Limits?
    For WIP Limits, the most relevant tools on the flagship platform are the EVM, SPI and CPI calculators on PMMilestone.org. They reproduce the formulas referenced in this entry against your own project data.
  • What is a common misconception about WIP Limits?
    That the topic is well-defined across all references. In practice, definitions vary between PMBOK, PRINCE2, AACE and ISO 21500 — this entry uses the definition most aligned with field practice on capital projects, and flags where the standards diverge.
  • Which related encyclopedia entries should I read alongside WIP Limits?
    Read Earned Value Management, Critical Path Method and the DCMA 14-point assessment next. The full A–Z is available in the PMMilestone Encyclopedia, and quick one-line definitions live in the PM Glossary on the flagship platform.
  • How does Dr. Hassan Eliwa's research treat WIP Limits?
    Dr. Hassan Eliwa's research focuses on owner-side project controls, schedule integrity and forensic delay analysis on capital construction and power programmes. WIP Limits is treated through that lens — what a planning or controls engineer is expected to do with it on a live project, not its textbook definition alone. See the full research library at PMMilestone Research Articles.
  • How is WIP Limits defined on PMMilestone Research & Insights?
    A Kanban discipline that caps the number of work items in progress at each stage, forcing teams to finish before starting and exposing the bottlenecks that quietly destroy flow. For the full treatment, see the definition, principles, applications and related entries above — every encyclopedia entry follows the same research-grade structure.

Related Entries

Further reading on PMMilestone.org

Curated companion resources hosted on the flagship platform, PMMilestone.org.

Related Encyclopedia Entries
Career Guides
Tools on PMMilestone.org
Buy me a coffee