The Multitasking Illusion
More tasks in progress means more things getting done simultaneously, which means faster delivery. This is the intuition. It’s wrong.
When more tasks are in progress simultaneously, each task takes longer to complete because attention is divided, context-switching costs accumulate, and each individual task gets worked on less frequently. Total throughput goes down. People feel busy. Delivery slows.
WIP (work in progress) limits are a mechanism to counteract this by deliberately capping the number of tasks that can be in active states at the same time.
Little’s Law
The mathematical foundation is Little’s Law: Throughput = WIP / Cycle Time. For a stable system, these three variables are in balance. If you hold throughput constant and increase WIP, cycle time increases proportionally. Every additional task in flight means every existing task takes longer.
For teams: if you have 20 tasks in progress and average cycle time is 10 days, you’re completing 2 tasks per day. If you reduce WIP to 10 tasks and cycle time drops to 5 days, you’re still completing 2 tasks per day — but now each task is done in 5 days instead of 10. You haven’t changed throughput. You’ve halved the time to value for each individual piece of work.
Where to Set Limits
A common starting point: WIP limit = (number of team members × 1.5) per active status column. This gives enough slack that people don’t block on minor dependencies, but not so much slack that the column becomes a parking lot.
In practice, you’ll tune based on observation:
- If the WIP column rarely fills up, the limit is too high and isn’t constraining behavior.
- If work is constantly blocked at the WIP limit and people are idle, the limit may be too low or there’s a bottleneck further downstream that needs addressing first.
- If the “in review” column hits its limit while “in progress” is empty, you’ve found your bottleneck: review capacity.
WIP Limits as Bottleneck Detectors
This is the underappreciated benefit of WIP limits. When a column hits its limit and upstream work can’t enter, the team is forced to address the congestion before continuing. This makes bottlenecks visible and urgent instead of hidden and chronic.
Without WIP limits, a slow review process results in an ever-growing “in review” column while “in progress” keeps filling up. The system adapts by carrying more WIP, which slows everything down. No one is forced to confront the review bottleneck.
With a WIP limit on the “in review” column, once it fills, developers can’t move new work into review. The bottleneck becomes immediately visible and creates the right incentive to address it — add more reviewers, do review pairing, break tasks into smaller units that review faster.
Applying WIP Limits in FlowEra
FlowEra’s Kanban view supports per-column WIP limits on your status columns. When a column is at its limit, it’s visually flagged. The team decides how to respond — but at minimum, they can see the constraint.
WIP limits work best when the whole team understands why they exist. Imposed without explanation, they feel like arbitrary restrictions. Explained as a throughput optimization, they shift from rules to tools.