WIP Limits: Stop Starting, Start Finishing

THE MENTAL MODEL: Work-in-Progress (WIP) limits are a counter-intuitive practice for getting more done by starting less. Instead of pushing tasks onto the team to keep everyone busy, WIP limits create a pull system. The goal shifts from maximizing individual activity to optimizing the flow of work from start to finish. It forces a team to stop starting new things and start finishing things that are already in flight, which dramatically reduces lead times.

HOW IT WORKS: On a Kanban board, each column representing a stage of work (e.g., 'In Progress', 'Code Review', 'QA') is given a numerical limit. For example, the 'In Progress' column might have a WIP limit of 3. Once there are three tasks in that column, no one on the team is allowed to pull a new task from the 'To Do' column. Instead, if a team member becomes free, they must find a way to help move one of the existing three tasks forward, such as by pair programming or helping unblock a colleague. This focuses the entire team on finishing work, not just starting it.

WHEN TO USE IT: WIP limits are a foundational practice for any team using Kanban. They are especially powerful for teams that suffer from long cycle times, frequent context switching, and work piling up in one particular stage (like a QA bottleneck). They create a system that automatically highlights blockers and encourages team collaboration to resolve them.

WHEN NOT TO USE IT: WIP limits are less effective if work items are not of a similar size or if the workflow is highly unpredictable. The biggest footgun is a lack of discipline. If the team culture allows for constant exceptions or people ignore the limits, the practice provides no value and just becomes a source of frustration. The team must be willing to embrace the initial discomfort of seeing people 'idle' while waiting for work, understanding that this 'idle' time is best used to improve the system by unblocking others.

ONE CANONICAL EXAMPLE: A software team sets a WIP limit of 2 on their 'In Progress' column. Developers Alice and Bob each take a task. A third developer, Carol, finishes her work and is ready for a new task. She cannot pull from 'To Do' because the 'In Progress' column is full. She sees that Bob's task is blocked waiting for an API key from another department. Instead of starting a new task and increasing the team's cognitive load, Carol chases down the API key, unblocking Bob. Bob's task moves to 'Code Review', freeing up a spot. Only now does Carol pull a new task. The system forced collaboration to improve overall flow.