WIP limit per column helps us to reveal work process bottlenecks. But it doesn't prevent person work bottlenecks.

Let's suppose there're two developers in a team and the WIP limit for the DEVELOPMENT column is equal to 4. This means that the following is possible:

  • one developer's working on 3 items; the other one's working on 1 item
  • one developer's working on 4 items (because the other one's working on an item from another column, e.g. doing a code review in the CODE_REVIEW column)

So the question is: must we also set WIP limit per person in Kanban (in addition to WIP limit per column)?

  • Nice question. Out of the box suggestion- You may apply data filter options for visibility like team wise or for a specific resource. – Krunal Jan 3 at 10:34


In agile frameworks such as Kanban, you shouldn't have to care about how the work is allocated within a process state such as "development." That's up to the team. Just focus on right-sizing the WIP limits to ensure they are based on available team capacity and optimize for flow rather than individualized tasking.

Limit Work to Optimize Flow

From a Kanban perspective, it doesn't really matter how many resources are allocated to each work item or column. The goal of the framework is to optimize flow and reduce cycle times, not to maximize resource utilization. Therefore, WIP limits are a maximum, not a minimum!

Kanban is a Pull Queue

Realistically, a developer can only actively work on one task at a time. Therefore, Kanban's pull-queue approach means that a developer would only pull a task from some previous state into "development" when:

  1. They were ready to actively work on it.
  2. There is a free WIP slot available in the development state.

If WIP slots are full because there's already too much work already in development, or because the subsequent state (e.g. QA) isn't ready to pull additional work, then the work should sit in "development" until the process begins to flow again. This is the expected functioning of Kanban, and forces the team to think about flow and cycle time systemically. This in turn forces the organization to "stop the line" to fix bottlenecks, or accept the drag induced by growing queue or cycle times, rather than trying to hide problems within the system or process.

Calculate WIP Based on Capacity

There's nothing in Kanban that says you can't have WIP limits for people, but it's an anti-pattern. Kanban grew out of the Toyota Production System, so it was originally optimized for assembly lines. A line is generally linear, but it doesn't necessarily have just one person per station, so WIP limits are intended to reflect capacity for a station (or process state) rather than the number of people assigned to that sub-process.

In agile development, assigning tasks to people rather than teams or roles is also an anti-pattern. The benefits of empowering teams to self-organize and optimize their work are largely lost when you start parceling out tasks at the individual level, so don't do that. You shouldn't care whether work is being done through pair programming, solo work, or mob programming; do whatever optimizes flow at an acceptable level of quality for your project and team.

Right-Size Your State-Based WIP Limits

In short, a two-person team should probably have a maximum WIP limit of one or two items per process state, not four! If items are sitting in a state/column without:

  1. being actively worked on, or
  2. blocking additional work items from entering the column or process

then you're doing Kanban wrong. In Kanban, work is either flowing or blocked (although it is sometimes allowed to queue between sub-processes). Designing your processes to allow wasteful amounts of idle work to queue runs into Little's Law, and will therefore negatively impact your cumulative flow and takt time.

The number of people on the team will obviously have an impact on the number of non-blocking tasks the team can work on simultaneously, but it's a function of the work to be performed (including necessary slack) rather than a 1:1 ratio of people to slots.

WIP Recommendations

I generally recommend a WIP limit of Team Size - 1 for the Kanban board as a whole, and a columnar limit of Task Performers - 1 for each process state as a reasonable starting point. This not only prevents excess queueing and task-switching overhead, but also ensures that some process slack is baked into the WIP limits. You can then inspect-and-adapt the board-level and columnar limits as part of the continuous improvement process.

Also, remember that WIP limits are a negotiated constraint that can be adjusted and revised over time. WIP limits are not a capacity target! So, even if your optimum WIP limit in development is 4, developers should only pull jobs they're working on. The team should also handle work items dispositively when they are completed or blocked, rather than letting them queue or idle indefinitely.

As a corollary, that means that if you normally have 5 developers with a standing WIP limit of 4, if two of them are on vacation the actual work pulled into "development" should be 1 or 2 during that period even if the average optimal WIP limit for that activity is 4! The WIP limit is an upper bound, and should never exceed current capacity without triggering a stop-the-line inspect-and-adapt activity. There are some advanced techniques for enqueuing within a state at the expense of cycle time, but if the team/organization hasn't mastered the central idea of capacity-based flow then this is just begging for sub-optimal throughput for the overall process.

Always use WIP to reduce task switching and queue/cycle times. Don't treat it as a capacity target, ever! That way lies madness and voluminous quantities of self-inflicted pain. Just don't do it.

| improve this answer | |
  • I didn't say two-person team, I said two members of a team are developers (there can also be testers, designers). – Chris Brettini Jan 3 at 17:53
  • In agile team, how is "Team Size" different from "Task Performers"? A developer can do testing, reviewing. A tester does testing and also develops new tests. – Chris Brettini Jan 3 at 17:55
  • A little confused. Did the Question talk about treating WIP as a capacity target? Why bring it up? (Not that I disagree, just not seeing the relevance.) – Sarov Jan 3 at 20:26
  • @ChrisBrettini “Team size” includes all the people assigned to a project. “Task performers” are the people who will be performing the work on a specific task or a given work item. They are unlikely to be interchangeable terms. Just because individuals are cross-functional doesn’t mean they can multitask, so you can’t multiply people by tasks and get a sane result for WIP limits. – Todd A. Jacobs Jan 3 at 21:56
  • @Sarov Anytime WIP limits exceed available resources, it’s likely they’re being treated as utilization targets. The relevance is that the OP is currently setting the WIP limits at N+2 rather than N-1, making it likely that the numbers are both aspirational targets and reflections of work that’s technically queued rather truly “in progress.” – Todd A. Jacobs Jan 3 at 22:01

From the Agile Manifesto,

Individuals and interactions over processes and tools

It's hard to tell, with just a glance at the board, how many items are in a column, and why column WIP limits are important.

Comparatively, if you have someone who is unaware that s/he is working on multiple tasks, you have a much larger problem than this.

Likewise, it should be easy enough to just sit down with everyone and explain the cost of working on multiple work items. After that, assuming you're working with rational adults, everyone should be able to self-police his/her workload, making a board-enforced per-person WIP limit redundant.

If you're not working with rational adults, then, again, you've got bigger problems than this.

| improve this answer | |
  • Let us continue this discussion in chat. – Sarov Jan 3 at 17:51
  • @ChrisBrettini Having incomplete or partial work hanging around is inherently non-agile. Agile work is “done” or “not-done,” so trying to track partial progress is a known anti-pattern. This makes your OP a bit of an X/Y problem, so you may want to open a new question asking how to handle specific examples of blocked or postponed work. – Todd A. Jacobs Jan 7 at 16:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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