Is there a process to guide the initial WIP number decisions for kanban board columns apart from picking a rough number and seeing how it works out?

Secondly, what metric(s) do you monitor to determine if WIP limits are set too high or too low? e.g. if the number of people on a team changes, the WIP numbers may need to adjust to reflect the change in the team. Or... could a team set their WIP too high just to avoid breaking the limit... So, are there metrics that can be monitored to determine if a team's WIP is correct?

  • Here's the rule: WIP = 1/person, always. If you want it higher, then you need to provide a good justification.
    – Ray
    Commented Jun 24, 2016 at 18:44

4 Answers 4



To the very best of my knowledge, there is no canonical formula for determining Work in Progress (WIP) limits. However, there are some empirical best-practices.

What WIP Limits Are Intended to Do

The goals of WIP limits are generally to:

  • Improve throughput.
  • Reduce cycle times.
  • Optimize team capacity.
  • Limit the efficiency drag from multi-tasking.
  • Increase slack to make a process more adaptable.

Optimizing WIP Limits

How one optimizes WIP limits will vary a lot based on a number of factors and a lot of in situ process analysis. However, a good rule of thumb is to limit WIP to the team's mono-tasking capacity. In other words, your baseline WIP limit should be the number of tasks that can be in progress simultaneously without idling.

For example, if you have six team members whose responsibilities don't overlap, your WIP limit should not exceed 6 across all columns on the Kanban, since that is the maximum number of tasks that can be worked on simultaneously without task-switching or multi-tasking. In addition, specific columns may further restrict WIP limits for that columb as a subset of the limit for the Kanban as a whole.

However, as a practical matter, cross-functional teams, teams that practice pair programming, and frameworks that encourage "swarming" the team over stories should lower their WIP limits accordingly. For example, a WIP of N-1 (where N is the number of team members) would allow for more flexibility in coordinating stories within an iteration, while a WIP of N/2 might be optimal for a team that is optimized for pair programming.

Regardless of the actual numerical limit, the important thing is to avoid the "100% utilization fallacy" and ensure the process has sufficient slack to ensure a consistent level of throughput over time. That means that you generally want to apply some fudge factor to lower your WIP limits, but the specifics will vary from project to project.

Perhaps counter-intuitively, reducing the WIP limits below the team's maximum capacity will generally improve your throughput. This is most often because at 100% capacity, any roadblocks or unexpected issues can create bottlenecks that impact the entire pull-queue cycle. Ensuring that there is sufficient slack in the process enables the team to overcome minor process issues as they arise without needed to "stop the line" altogether. This ability to adapt without stopping the line every time is part of what makes a process agile.

Per-Column WIP Limits

Kanban is a pull-queue system. Each column is essentially a separate queue into which work is pulled from the previous column when the WIP limit allows.

  • For example, if two of your columns are "Coding" and "Regression Testing," one would pull finished stories from the Coding column when the Regression Testing column was below its capacity.

  • As a further example, if your Kanban WIP limit is 6, but you have only one person dedicated to Regression Testing, then your WIP limit for the Regression Testing column should most likely be 1; not one test, necessarily, but rather a single story.

There are always exceptions. If regression testing is semi-automated, and six jobs can be run in parallel without multi-tasking by the human agents responsible for the column, you might set the WIP limit for that column to six. The optimal WIP limit for each queue is most definitely an inspect-and-adapt issue that needs to be consistently reviewed by the team and adjusted as necessary over time.

Ultimately, the methodology for optimizing WIP limits for columns is the same as optimizing for the board as a whole: your WIP limit for a column must not exceed its mono-tasking capacity, and should be low enough to provide sufficient slack in the process to prevent line-stoppage for minor problems.


The short answer is no, there's no hard-and-fast rule. In fact, the only article I've read that offered any suggested initial number said to start with 2 stories per team member as a WIP limit. That's probably fair.

As for metrics, your best bet is probably using cumulative flow diagrams. This is a really good article on them:


and that can show you if you need to tighten up any areas of the development process.

Past that, I've always liked the idea of working right-to-left on the board for stand-ups. Make sure that if anyone is capable of moving tasks along in, say, test, they aren't bringing in new stories on the left side. That practice can reduce the amount that you have to enforce the WIP limit. In an ideal scenario, you focus on keeping the workflow moving smoothly and the WIP limit is never reached.


Remember that one of the Kanban principles is "start where you are". So, a good way to determine the initial WIP limits is to just count how many tickets currently are in the column, or how many you typically would expect with your current process. Then react to what happens.

Then remember that the two main functions of WIP limits are to create flow, and to create kaizen events. That is, if you never break your WIP limits, or if they never force you to discuss how to work differently to make them work, the limits are probably too high. If they constantly force you to shuffle your work around - thereby reducing flow - without leading to any process improvement, they might be too low (or you might need to get better at improving your process).


Optimal WIP are limits highly dependent on the size of your team. Lower WIP limits indicate smaller lead-times, but if you set the WIP limits too low your overal project duration will extend. If you set the WIP limits too high you'll create bottlenecks.

I created a small simulation tool where you can play with wip limit, team size, swim lanes etc. The tool is open source and free.

Have look at https://github.com/devchild/wip-vs-leadtime

  • Unclear how to use your tool; Seems it needs to be downloaded and the configured by a techie (as opposed to a PjM). Commented Jun 23, 2016 at 8:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.