Work in progress (WIP) measures the number of items your team is actively working on simultaneously. Research consistently shows that excessive WIP is one of the primary causes of slow delivery, and that limiting WIP is among the most effective strategies for improving engineering team performance.
What Is Work in Progress?
Work in progress counts all work items that have been started but not yet completed. In software development, this includes stories in development, pull requests awaiting review, features in testing, and any other items that are neither in the backlog nor fully deployed to production. WIP represents your team's partially completed inventory.
Little's Law, a fundamental principle of queuing theory, states that lead time equals work in progress divided by throughput. This means that if your throughput remains constant, reducing WIP directly reduces lead time. Conversely, increasing WIP without increasing throughput simply makes everything take longer.
Excessive WIP creates multiple problems beyond slow lead times. It increases context switching as engineers juggle multiple items, reduces code review responsiveness because everyone is busy with their own work, and makes it harder to identify and respond to blockers because attention is spread across too many items simultaneously.
How to Measure Work in Progress
Count the number of work items in active states on your board at any point in time. Active states typically include in development, in review, in testing, and any other state between ready for development and done. Take snapshots at regular intervals-daily or at the start of each standup-to track WIP trends over time.
Measure WIP at both the team level and the individual level. Team-level WIP reveals overall process health, while individual WIP highlights engineers who may be overloaded or context-switching excessively. An engineer working on more than two items simultaneously is likely not making effective progress on any of them.
- Count all items in active states between backlog and done
- Take daily snapshots to track WIP trends over time
- Measure WIP per person as well as per team to identify overloaded individuals
- Track WIP by column or stage to identify where items accumulate
- Include all types of work: features, bugs, technical debt, and operational tasks
WIP Benchmarks and Recommended Limits
A common starting point for WIP limits is one to two items per developer. This allows for some natural multitasking (such as starting a new item while waiting for code review on another) without the productivity loss of excessive context switching. Teams that enforce this limit typically see significant improvements in lead time within weeks.
At the team level, your total WIP should generally not exceed the number of developers on the team. A team of six should have no more than six to eight items in progress at any time. If you consistently have more items in progress than team members, you have a WIP problem that is likely increasing lead times and reducing quality.
WIP limits should be applied per column on your board, not just in aggregate. If your review column has a WIP limit of two, the team must review and merge existing pull requests before submitting new ones. This prevents bottlenecks from forming at specific stages and ensures work flows smoothly through the entire process.
Strategies for Implementing WIP Limits
Start with generous WIP limits and tighten them gradually. If your team currently has fifteen items in progress, setting a limit of six overnight will cause frustration and resistance. Start with a limit of twelve, let the team adjust, then reduce to ten, then eight. Each reduction surfaces new bottlenecks that need to be addressed before reducing further.
Make WIP visible. Display your board prominently, colour-code items that exceed WIP limits, and discuss WIP in daily standups. When the team can see that starting new work will breach the WIP limit, the conversation naturally shifts to what can be finished first or what blockers need to be resolved.
- Start with generous WIP limits and reduce them gradually over several weeks
- Apply WIP limits per column to prevent bottlenecks at specific stages
- Discuss WIP in daily standups and prioritise finishing over starting
- Colour-code or flag items that breach WIP limits to make violations visible
- Adjust WIP limits based on team size changes and retrospective feedback
Overcoming Resistance to WIP Limits
Engineers often resist WIP limits because they feel unproductive when they cannot start new work. Address this by reframing productivity: finishing one item is more valuable than half-finishing three items. Show the data on how WIP affects lead time and help the team see that completing work faster benefits everyone, including themselves.
Stakeholders may resist WIP limits because they worry about utilisation. The fear is that limiting WIP means engineers will sit idle. In practice, reducing WIP rarely creates idle time-there is always blocked work to unblock, code to review, tests to write, or technical debt to address. Limiting WIP redirects effort towards completing work rather than starting it.
When WIP limits create discomfort, that is a feature, not a bug. The discomfort reveals bottlenecks and process problems that were previously hidden by the team simply starting new work whenever they were blocked. Each moment of friction is an opportunity to identify and address a systemic issue that was slowing delivery.
Key Takeaways
- Work in progress is the number of items started but not yet completed-excessive WIP is a primary cause of slow delivery
- Little's Law proves that reducing WIP directly reduces lead time when throughput is constant
- Set WIP limits of one to two items per developer and no more total items than team members
- Apply WIP limits per board column to prevent bottlenecks at specific process stages
- Start with generous limits and tighten gradually to surface and address bottlenecks incrementally
Frequently Asked Questions
- What should engineers do when they hit the WIP limit?
- When the WIP limit is reached, engineers should focus on helping complete existing work rather than starting new items. This might mean reviewing pull requests, pairing with a colleague who is blocked, writing tests for in-progress features, or addressing technical debt. The goal is to move existing work to done rather than adding more items to the queue.
- How do WIP limits work with urgent production issues?
- Urgent issues should be able to bypass WIP limits, but with explicit acknowledgement that something else must be deprioritised. When an urgent item enters the flow, the team should consciously pause or de-scope another item to maintain the WIP limit. This ensures urgency is handled without silently inflating WIP.
- Do WIP limits apply to all types of work?
- Yes. Features, bugs, technical debt, and operational tasks all contribute to WIP and all compete for the same team capacity. Tracking all work types in your WIP count gives an accurate picture of team load. If operational work frequently pushes you over WIP limits, that is a signal to invest in reliability improvements.
Explore Agile Process Guides
Our Engineering Manager's Field Guide covers WIP management, Kanban practices, and process optimisation strategies for engineering teams of all sizes.
Learn More