Most squads don't have a speed problem. They have a congestion problem. Work piles up across the board, context switching multiplies, and cycle times balloon without anyone understanding why. WIP limits are the mechanism that prevents this: a cap on how much work can be actively in progress at any stage of your delivery pipeline at one time. When set correctly, they force flow and surface bottlenecks before they become sprint-ending blockers. This page covers the definition, how to measure adherence, what good looks like, and how to improve your squad's WIP discipline.
Key takeaways
- WIP limits are explicit caps on the number of work items allowed in any active workflow stage at a given time. They matter because unconstrained work-in-progress is one of the most reliable predictors of slow cycle times, missed sprint commitments, and squad burnout. Fewer active items means faster completion of each one.
- There is no universal formula for WIP limits, but a widely used starting point is to set the limit for each stage at roughly 1 to 1.5 times the number of players who work in that stage. So a squad of four developers working in a "In Review" column might set a WIP limit of four to six open items. Adjust based on observed cycle time data.
- The most common mistake teams make is treating WIP limits as aspirational rather than enforced constraints. Setting a limit of five in a tool but routinely running eight active items defeats the purpose entirely. The limit only works when the squad treats a breach as a signal to stop starting and start finishing.
- DevStats surfaces throughput and issue cycle time data automatically by connecting to your Git provider and issue tracker, giving you the signal you need to validate whether your WIP limits are working. You can benchmark your squad's flow metrics against 1,000+ engineering teams. Start a free trial to see your numbers in under two minutes.
WIP limits definition
WIP limits (work-in-progress limits) are constraints placed on the number of tasks, stories, or tickets allowed to be actively in progress at any single stage of a team's workflow at the same time. They are a core practice in Kanban and are increasingly applied in Scrum and hybrid delivery models.
Technically, a WIP limit is a per-column or per-stage ceiling: if a "In Development" column has a WIP limit of four, no new item can enter that stage until one exits. The relationship between WIP, throughput, and cycle time is described by Little's Law: Cycle Time = WIP / Throughput. Reducing WIP directly reduces average cycle time when throughput stays constant. Teams that enforce WIP limits consistently tend to ship more predictably, which translates directly into stakeholder trust and more accurate delivery commitments. You can see how this plays out in your own data through DevStats's throughput tracking, which surfaces how much work your squad is completing over time.
Why WIP limits matter for engineering teams
Squads without WIP limits tend to accumulate work across every stage simultaneously. A player picks up a new ticket while three others sit in review. Another starts a feature while a bug fix waits for QA. The result is a workflow that looks busy but moves slowly, with long tail items aging invisibly until they blow up a sprint. Tracking issue cycle time in DevStats can make this pattern visible before it becomes a recurring problem your squad can't explain.
From an engineering leader's perspective, WIP bloat directly threatens your on-time delivery rate, your squad's ability to respond to incidents, and the accuracy of your sprint forecasts. When too many items are in flight, context switching costs rise and the cognitive load on each player increases, contributing to the kind of sustained pressure that drives attrition. WIP limits connect to the SPACE framework's efficiency and flow dimensions: they are a process constraint that protects individual focus while improving system-level output.
Measuring WIP adherence is the first step. The engineering manager then decides whether the right response is to tighten limits, restructure the workflow, or address an upstream planning problem. The data tells you where to look; the leader decides what to do.
How to measure WIP limits adherence
Measuring WIP adherence means tracking how often your squad's active item count exceeds the defined limit for each workflow stage, and for how long. Your issue tracker (Jira, Linear, GitHub Issues) is the primary data source. Pull a snapshot of item counts per stage at regular intervals, or use cumulative flow diagrams to see how WIP has trended over time. Pairing this with PR cycle time data gives you a fuller picture of where flow is breaking down across both code review and issue delivery.
No standardized DORA benchmarks exist for WIP limits specifically, since the right limit varies by squad size, workflow design, and work type. The table below describes what adherence patterns signal qualitatively. Benchmarks vary by team size, codebase complexity, and release model.
| Performance level | WIP limits benchmark | What it signals |
|---|---|---|
| Elite | WIP rarely or never exceeds defined limits; limits actively enforced | Strong flow discipline; squad finishes work before starting new items |
| High | WIP exceeds limits occasionally (less than 20% of the time) | Good discipline with minor exceptions; cycle times are predictable |
| Medium | WIP regularly exceeds limits (20–50% of the time) | Limits exist but are treated as suggestions; flow is inconsistent |
| Low | WIP limits are absent or routinely ignored | Congestion is systemic; cycle times are long and unpredictable |
You can see how your squad's flow metrics compare against peer teams using DevStats's benchmarks feature, which positions your throughput and cycle time data in context.
WIP limits in practice: a real example
A VP of Engineering at a 45-person SaaS company noticed that sprint completion rates had dropped from around 80% to under 60% over two quarters. Looking at the issue tracker data, she could see that the "In Development" stage routinely held eight to twelve active items against a stated limit of five. Players were context switching between multiple tickets, and code review was backing up because no one was free to review while also building. She decided to enforce the existing WIP limit strictly for one sprint, making it a blocker rule rather than a guideline, and pairing it with a daily five-minute standup focused solely on clearing blocked items.
After three sprints, the average issue cycle time dropped by roughly 30%, and sprint completion rates recovered to above 75%. She attributed the improvement not to the tool change but to the behavioral shift: players stopped starting new work and started finishing existing work first. She then used the throughput data to recalibrate the WIP limit to four, which better matched the squad's actual capacity after accounting for code review load.
How to improve WIP limits adherence
- Set limits based on capacity, not preference. Start with a WIP limit equal to the number of players in a stage, then adjust based on observed cycle time. If cycle time drops when you tighten the limit, you found the right number. Use your sprint data to validate whether tighter limits improve completion rates over time.
- Make breaches visible in real time. Configure your issue tracker to flag or visually highlight when a column exceeds its limit. A breach that no one sees gets ignored. The goal is to make the constraint impossible to miss during the workday.
- Treat a breach as a signal to swarm, not to add more work. When WIP exceeds the limit, the squad's response should be to pull someone off a new task to unblock the stuck item, not to keep starting. This requires explicit agreement in your team norms, not just a tool setting.
- Monitor code review as a leading indicator. A backed-up review stage is often the first place WIP limits break down. Watch your code review metrics for rising queue depths: that is usually where the congestion starts before it spreads upstream.
- Review limits quarterly. Squad size, work type, and delivery cadence change. A WIP limit that worked for a squad of six may be wrong for a squad of ten. Revisit the numbers at the start of each quarter and adjust based on actual throughput data, not intuition.
WIP limits vs. sprint capacity
WIP limits and sprint capacity are related but measure different things: sprint capacity is the total amount of work a squad commits to completing in a sprint, while WIP limits constrain how much of that work can be actively in progress at any single workflow stage at one time.
| WIP limits | Sprint capacity | |
|---|---|---|
| Measures | Active items per workflow stage at a point in time | Total work committed to in a fixed time period |
| Starts when | An item enters an active workflow stage | Sprint planning begins |
| Ends when | An item exits that stage | Sprint closes |
| Best for | Managing flow and reducing cycle time | Managing scope and delivery predictability |
Use WIP limits to control flow within a sprint and planning accuracy metrics to evaluate whether your sprint commitments are realistic in the first place.