Agile · Letter W

WIP Limit (Work in Progress Limit)

A cap on how many items a team may have in progress at once — the single most effective policy for improving flow.

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

Definition

A WIP limit is a cap on how many work items a team, a workflow stage, or an individual may have in progress simultaneously. It is the Kanban method's central discipline and — in my experience — the highest-leverage change most teams can make to their operating model. Little's Law tells us that lead time = WIP ÷ throughput. Cut WIP in half and, at constant throughput, lead time halves. Almost no other single intervention has this kind of arithmetic guarantee behind it.

Where to Set Limits

  • Per column/stage — e.g. "In Progress" capped at 5; "Code Review" capped at 3.
  • Per team member — e.g. no engineer works on more than two items at once.
  • Per class of service — expedite items capped at 1, standard capped at 5.
  • Across the whole team — total WIP capped at 8 across all stages.

Most successful teams use a combination — a total cap plus per-column limits at the known bottlenecks.

Real-World IT / Agile Example

A frontend team of six engineers had an average of 22 items in progress across the board — nearly four per person. Lead time was 34 days for a median item. They introduced a hard WIP limit of 9 across the board (1.5 per engineer) and a strict "pull, don't push" policy. Six weeks later: median lead time 12 days, unchanged team size, higher morale. The mechanism was simple — engineers finished work before starting new work. Context-switching dropped, review queues shrank, throughput actually rose slightly because less time was lost re-loading context.

Real-World Construction Example

A fit-out contractor was running six trade partners in a 40-storey commercial tower. Each floor had crews from every trade simultaneously — great for schedule on paper, but every crew was waiting for another crew's incomplete work. They introduced a WIP limit: only three floors could be "active" for any given trade at once. Painters, for example, worked floors 12, 13, and 14 to completion before moving to 15. Total programme extended by two weeks against the fantasy baseline; total programme delivered eleven weeks earlier than the previous project of similar size, because rework and re-mobilisation dropped dramatically. The same insight as the frontend team: finishing beats starting.

Why It Works

  • Reduces context-switching cost — one of the biggest silent thieves of productivity.
  • Surfaces bottlenecks — when the review column is at its limit and blocked, everyone sees it.
  • Forces prioritisation — someone must decide what does not enter the system.
  • Reduces multitasking-induced errors and rework.
  • Encourages swarming — when work is blocked, the team helps unblock rather than starting something else.

Expert Tips

  • Set the limit slightly below current WIP. Start with mild pressure, not shock.
  • Enforce it visibly. Physical boards work well because you cannot cheat a full column.
  • Review the limit monthly. Adjust up if throughput suffers, down if flow is still choppy.
  • Include reviewers in the WIP. A code review sitting for three days is WIP, whether or not the engineer has moved on.
  • Do not exempt the "urgent" work. That is where WIP creep starts, and it never stops there.

Common Mistakes

  • Setting WIP limits far higher than current WIP — no effect on behaviour.
  • "Emergency" items constantly breaking the cap — the exception becomes the rule.
  • Not counting review, testing, and awaiting-deployment items as WIP.
  • Assuming WIP limits reduce team output — the opposite is almost always true.
  • Failing to combine WIP limits with a policy for what to do when blocked (swarm, not "grab something else").

Practical Lessons Learned

  • The team that fights WIP limits the hardest usually needs them the most.
  • WIP limits create a healthy discomfort — engineers finish what they started; product owners prioritise more carefully. The discomfort is the mechanism working.
  • In multi-team programmes, portfolio-level WIP limits ("we run five programmes at once, not twelve") are as powerful as team-level limits.

Key Takeaways

  • WIP limits are a hard cap on parallel work.
  • Little's Law guarantees the arithmetic: less WIP → shorter lead time.
  • Enforce them visibly, include reviews in the count, and adjust monthly.
  • Same principle applies to construction crews as to software engineers.

Related Encyclopedia Entries

Related Research Articles, Case Studies & Tools

Frequently Asked Questions

  • What's a good starting WIP limit?
    Roughly 1.5 items per team member across the board is a safe first cut for knowledge work — 6 people, WIP 9. Adjust based on observation over 4–6 weeks.
  • Does the Scrum sprint backlog count as a WIP limit?
    Sort of. The sprint backlog is a batched WIP limit — everything in the sprint is 'in progress' for that iteration. Adding column-level WIP limits inside the sprint improves flow further.
  • What if we breach the limit?
    Stop. Swarm on the blocked item. Do not pull new work. That is the whole point of the mechanism — it forces the team to unblock rather than compensate.
  • How do WIP limits interact with expedite items?
    Have a separate lane (a swim lane or a class-of-service track) for expedite, with its own cap — usually one. Never break the main cap for expedite; that is the fastest way to lose the discipline.
  • Do managers push back on WIP limits?
    Often, initially — 'we're paying you to work, not to wait.' The Little's Law argument is unanswerable arithmetically; the challenge is cultural. Showing the before/after lead-time data usually settles it within a quarter.
  • Should individual engineers have personal WIP limits?
    Yes — I recommend two items maximum for most knowledge workers, one for tasks requiring deep concentration. Human working memory does not scale, and multitasking studies uniformly show it degrades quality and speed.
  • Can I apply WIP limits to a portfolio?
    Absolutely — and it is often the highest-impact place. Organisations that run twelve major programmes in parallel typically deliver less than organisations that run six well. Portfolio WIP limits are one of the hardest cultural changes to make but among the highest-value.
  • Which calculators on PMMilestone.org apply to WIP Limit (Work in Progress Limit)?
    For WIP Limit (Work in Progress Limit), 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 Limit (Work in Progress Limit)?
    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 Limit (Work in Progress Limit)?
    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 Limit (Work in Progress Limit)?
    Dr. Hassan Eliwa's research focuses on owner-side project controls, schedule integrity and forensic delay analysis on capital construction and power programmes. WIP Limit (Work in Progress Limit) 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 Limit (Work in Progress Limit) defined on PMMilestone Research & Insights?
    A cap on how many items a team may have in progress at once — the single most effective policy for improving flow. For the full treatment, see the definition, principles, applications and related entries above — every encyclopedia entry follows the same research-grade structure.

People also ask

Follow-up questions practitioners search for next — each one points to the calculator, template or reference entry that answers it.

Related Entries

Browse more in this category

More in Agile

View all Agile 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