Work-in-Progress (WIP) Limits

The fastest way to finish more work is to start less. WIP limits enforce that discipline with math, not motivation.

Overview

A WIP limit is an explicit constraint on the number of work items allowed in a given stage of a workflow. It is the most direct lever teams have for improving flow. Little’s Law tells us that WIP = Throughput x Cycle Time; if you hold throughput steady and reduce WIP, cycle time drops. That’s not a suggestion; it’s math.

In practice, setting WIP limits forces teams to finish work before starting new work. When a column hits its limit, the team swarms on the stuck item or idles rather than pulling in something new. This feels uncomfortable at first but quickly surfaces bottlenecks that were previously invisible under a pile of “in progress” items. A 5-person team might set a total WIP limit of 8 items, ensuring capacity for collaboration and review without starving the pipeline. The target for individual developers is 1-2 items at a time.

We reach for WIP limits in nearly every engagement because they produce visible results fast. Teams that set limits consistently report shorter cycle times, fewer context switches, and better cognitive load management. The key is to start conservative (lower than comfortable), observe what breaks, and adjust. If nothing feels constrained, your limits are too high. CFDs make the effect visible: bulging bands shrink as limits take hold, and flow patterns stabilize.

Resources

• Flow — the theoretical foundation connecting WIP to cycle time via Little’s Law
• Flow Metrics Guide — practical guide to implementing flow metrics including WIP tracking
• Small Slices of Value — smaller items complement WIP limits by reducing time-in-system
• Cognitive Load — excess WIP is also a cognitive problem
• Daniel Vacanti, “Actionable Agile Metrics for Predictability” (ActionableAgile, 2015)