Definition
Work in Progress (WIP) measures how many items a team is actively working on at any point in time. In Kanban and lean systems, teams set explicit WIP limits -- caps on the number of items allowed in each workflow column (e.g., max 3 items "In Development," max 2 items "In Review"). When a column hits its limit, no new work enters until something moves out.
The mathematical basis is Little's Law: Cycle Time = WIP / Throughput. This means that reducing WIP is the fastest way to reduce how long it takes for any single item to go from start to finish. A team with 20 items in progress and a throughput of 10 per week has a 2-week average cycle time. Drop WIP to 10, and cycle time halves to 1 week -- even though the team is not working any faster. Microsoft's Xbox team applied WIP limits during their transition to Kanban and reduced average lead time from 65 days to 19 days.
Why It Matters for Product Managers
High WIP is the silent killer of delivery speed. When a team has 15 items in progress, everything takes longer because engineers context-switch between tasks, PRs sit in review queues, and nothing gets the focused attention needed to finish it. A study by Gerald Weinberg found that context switching between 3 simultaneous projects wastes 40% of productive time.
For PMs, high WIP creates an insidious illusion: everything is "in progress," so it looks like the team is productive. But check how many items actually shipped last sprint. Teams with high WIP often start many things and finish few. Lowering WIP limits forces the uncomfortable but necessary conversation: "If we can only have 6 items in progress, which 6 matter most right now?"
WIP limits also surface bottlenecks. When the "Code Review" column is always at its limit while "In Development" has slack, the constraint is clearly in review, not development. Without WIP limits, this imbalance is invisible -- work just piles up in review and cycle time quietly degrades.
How It Works in Practice
Visualize current WIP -- Put your workflow on a Kanban board (Jira, Linear, Trello, or a physical board). Count how many items are in each column right now. Most teams are surprised -- they often have 2-3x more items in progress than they realized.
Set initial limits -- Start with WIP limits of 1.5x the number of people who work in that column. If 4 developers work on the "In Development" column, set the limit to 6. This is a starting point, not a final answer.
Enforce the limits -- When a column hits its WIP limit, no new work enters. Instead, the team swarms on the bottleneck. If "In Review" is at capacity, developers stop starting new work and help review existing PRs. This feels uncomfortable at first but is exactly the point.
Measure cycle time -- Track how long items take from "In Progress" to "Done" over 4-6 weeks. If cycle time decreases as WIP drops, the limits are working. If cycle time stays flat, the bottleneck is elsewhere.
Adjust based on data -- Lower the limit if the team can handle it (shorter cycle times, no idle time). Raise it slightly if team members are frequently blocked with nothing to do. The goal is flow, not full utilization.
Common Pitfalls
Setting WIP limits but not enforcing them. A WIP limit that gets ignored whenever something "urgent" comes in is not a limit. If everything is urgent, the real problem is prioritization, not WIP.
Confusing utilization with productivity. Managers often resist WIP limits because they want every engineer "busy." But a developer who is "busy" with 5 half-finished stories is less productive than one who is focused on 2 and finishing them. Optimize for throughput (items completed), not utilization (people busy).
Applying WIP limits without visualizing the workflow. WIP limits only work when the team can see where work is accumulating. Without a visible board, limits are just arbitrary rules. The board makes the system behavior visible.
Starting with limits that are too aggressive. Dropping from 20 items in progress to 5 overnight causes frustration. Start moderate, let the team experience the benefits, then tighten. A 25-30% reduction in WIP is a good first move.
Related Concepts
Kanban is the workflow management system where WIP limits are most commonly applied, using a visual board with column-based limits.
Velocity measures throughput per sprint and is directly affected by WIP -- lower WIP typically leads to more predictable and often higher velocity.
Lean Product Development treats high WIP as one of the seven wastes, specifically "partially done work" that ties up capacity without delivering value.Explore More PM Terms
Browse our complete glossary of 100+ product management terms.