TL;DR
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:
- They were ready to actively work on it.
- 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:
- being actively worked on, or
- 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.
