Code should be reviewed when someone is ready to review it, and when the team has the capacity to perform the code review without "stopping the line" or impacting other work-in-progress.
In any pull-queue system, work is pulled (never pushed) when someone is ready to work on it. So, work should be pulled into your "Code Review" column when:
- Someone has a current need for that work item, e.g. they need it to be reviewed now so they themselves (or someone else with a near-term demand) can do something with it shortly thereafter.
- Someone has sufficient capacity to take temporary ownership of the work item.
- The state into which the work item is being pulled is not currently at the WIP limit for that column.
- The rightward shift of all work will not exceed the WIP limit of the board overall. NB: There are use cases where the WIP limit of the Kanban board can be lower than the WIP limit of a given column; in those scenarios, the board limit generally takes precedence over column limits.
When workflows are properly visualized and WIP limits are set appropriately, work may queue up in one state or another, but should rarely (if ever) necessitate the kind of task switching you're describing. Work that requires actively pulling resources from WIP in other states to work on something else generally indicates that WIP somewhere on the board is too high for your current capacity. This should raise immediate concerns, and trigger an inspect-and-adapt cycle to determine why the process isn't flowing smoothly. The team should then optimize working agreements, adjust queues, and right-size WIP limits to reduce or eliminate this type of resource contention in the future.
It seems likely that your board limits are too high. If a task requires two or more people, the WIP limits of other columns needs to be reduced to ensure that there are sufficient resources within the process to allocate to work in that column. For example, given the following WIP limits:
# Board-Level WIP Limit: 4
- Development (2)
- Code Review (1)
- QA (1)
this example Kanban process can have at most 4 work items in progress anywhere on the board. WIP limits say nothing about how many people you need for each work state, but an experienced Kanban practitioner would typically assume a team size of 5-6 people given these column limits in order to provide sufficient slack. Alternatively, a team of four people might set a board-wide limit of three to provide adequate slack at a more-pragmatic capacity of
Think of it this way: no matter how many states you have, if you have only one person on the team then
board_WIP_limit = 1 is your max even if particular columns would otherwise be allowed to queue with values like
column_WIP_limit = 2. Your total throughput can't realistically exceed your available resources, so think about the entire process holistically rather than targeting utilization on a per-state basis.
Resource constraints, especially when you have a fixed team size, should generally trigger a process-wide reduction in WIP to optimize throughput. In your specific case, the core recommendation is to stop multiplying tasks by people or states to identify WIP limits. Instead, identify your significant work states, your available team capacity, and then limit work across all states to an aggregate that's less than the team's total capacity.