How do I determine the ideal Work in Progress (WIP) limits for a new Kanban team?

All answers to this question.

There isn't a single "perfect" formula, but a common starting point is the "n-1" or "1.5n" rule, where n is the number of team members in a specific stage. However, the best approach is empirical. Start with a slightly higher limit and observe your Cumulative Flow Diagram (CFD). If you see the "In Progress" band widening, your limits are too high. The goal is to create just enough tension to reveal bottlenecks. Remember, "idle workers are better than idle work." If someone is blocked because of a WIP limit, they should help a teammate finish a task rather than starting something new.

   Answered 2024-05-16 by Barbara Miller

That "idle workers" concept is a tough sell to management, isn't it? How do you explain to a senior executive that a developer sitting "idle" or helping with QA is actually more productive for the overall system than them starting a new feature that will just sit in the backlog for weeks?

   Answered 2025-05-18 by Thomas Wright

• Thomas, I use the "highway analogy." If a highway is 100% full of cars, nobody moves; that’s gridlock. To get the fastest travel time, you need empty space. I show them our Cycle Time data: when we decreased WIP, our average time to deliver a feature dropped by 40%. Data is the only way to win that argument.

     Commented 2025-05-20 by Sandra Collins

I highly recommend visualizing "Blocked" items separately on the board. Often, WIP limits are hit not because people are slow, but because we are waiting on external dependencies or approvals.

   Answered 2025-05-22 by James Peterson

• Great point, James. We started using "Blocker Stickers." It made the invisible delays visible to the stakeholders, and suddenly those "urgent" approvals started moving much faster.

     Commented 2025-05-24 by Barbara Miller