What Are Work in Progress Limit?
A constraint on the maximum number of tasks a team or individual can work on simultaneously. WIP limits reduce context switching, improve cycle time, and surface bottlenecks in the development process.
2-minute setup • No credit card required
What it means
Work in progress (WIP) limits are a core Lean and Kanban concept applied to software engineering. The principle: finishing work is more valuable than starting work. Without WIP limits, teams tend to start many tasks, make partial progress on each, and finish few — like a restaurant that takes 50 orders simultaneously but serves them all late. WIP limits cap the number of items in each workflow stage (e.g., max 3 items 'In Review,' max 5 items 'In Progress'). When a column hits its limit, the team must finish or unblock existing work before starting something new. This creates a pull-based system where work flows through the pipeline at a sustainable rate. Research from Lean manufacturing and software delivery consistently shows that lower WIP leads to faster cycle times (Little's Law: cycle time = WIP / throughput), fewer defects (less context switching means more focus), and better predictability (steady flow instead of feast-and-famine delivery).
Why Work in Progress Limit matter
WIP limits address the most common dysfunction in engineering teams: too much work in progress. When every developer has 3-4 tasks 'in progress,' nothing finishes quickly because attention is fragmented. This creates the illusion of productivity (everyone is busy) while actual delivery suffers (nothing ships). For engineering managers, WIP limits are a forcing function that surfaces bottlenecks: if the 'In Review' column is always at its limit, you have a review bottleneck. If 'In Progress' is always at limit but 'In Review' is empty, developers are working on too-large tasks. WIP limits make problems visible instead of hiding them under the appearance of busyness.
How to measure
Track the number of items in each workflow stage at any point in time. Most project management tools (Jira, Linear, Shortcut) can display WIP per column. Set initial WIP limits conservatively: for a team of 6, start with a WIP limit of 6-8 for 'In Progress' (roughly 1-1.5 per developer). For 'In Review,' set it at 3-4 (reviews should move quickly). Monitor cycle time alongside WIP: as you lower WIP limits, cycle time should decrease. If lowering WIP limits doesn't reduce cycle time, there's a bottleneck elsewhere in the system (often deployment or testing).
Real-world example
A 5-person team has 14 Jira tickets 'In Progress' simultaneously — almost 3 per developer. Average cycle time is 9 days. They set a WIP limit of 6 for 'In Progress' and 3 for 'In Review.' Initially, developers feel slowed down: they can't start new work until existing work moves forward. But within 2 sprints, cycle time drops to 4 days. The team discovers their real bottleneck was code review (PRs sat for 2+ days because everyone was focused on their own coding). With the WIP limit forcing them to review before starting new work, the entire pipeline speeds up.
Related terms
Common questions
What is a good WIP limit for engineering teams?
A common starting point: WIP limit equals team size (one task per person). Adjust from there based on what you observe. If work still moves slowly, lower the limit. If developers are frequently idle waiting for work, raise it slightly. For most teams of 4-8 people, a WIP limit of team-size to 1.5x team-size for 'In Progress' works well.
Do WIP limits slow down the team?
They feel slower initially because developers can't start new work as freely. But measured output (items completed per week) typically increases within 2-4 weeks. This is counter-intuitive: doing less at once produces more finished work. The explanation is Little's Law — reducing WIP reduces cycle time, which increases throughput if arrival rate stays constant.
How do WIP limits work with Scrum sprints?
WIP limits complement Scrum by preventing the team from starting all sprint items on day one and finishing them all in a rush at the end. Apply WIP limits within the sprint: only pull new items from the sprint backlog when existing items are completed or in review. This creates smoother flow throughout the sprint instead of the common 'hockey stick' pattern.
Should WIP limits apply to individuals or teams?
Start with team-level WIP limits on your Kanban/Scrum board columns. Individual WIP limits (e.g., each developer should have max 2 items in progress) can be useful but harder to enforce. Team-level limits are easier to implement and create collective responsibility: if the team's WIP limit is hit, everyone has a reason to help unblock existing work.
Track Work in Progress Limit Automatically
Gitmore turns your git activity into automated reports with real metrics — delivered to Slack and email.
Get Started FreeNo credit card • No sales call • Reports in 2 minutes