Tester: Controlling Work-in-Process

Perfect “flow” means that work goes through your organization without being slowed down unnecessarily.

One of the biggest factors in slowing down work is to have too much of it going on at the same time. It leads to excessive task switching, forgetting important information, stress, and many other documented sources of delay. The practice of controlling the amount of Work-in-Process provides a way for people to focus on just the work they can effectively service at any given time.

For any system, there is an optimal number of work items that can be processed effectively at any given time. Limiting the work items to just that number is not always immediately possible however.

Therefore, an individual, a team, or a larger group will set a “WIP limit” that is attainable but challenging. Over time, the goal will be to reduce the WIP Limit to the optimum number of simultaneous work items.

Generally speaking, as the WIP limit goes above capacity, the throughput of the system will decline. This is a sound principle that comes from queueing theory. A lower WIP limit means that the system is becoming more effective at processing small amounts of work at a time. This increased focus accelerates the work and improves flow.

The goal is to reduce the effective WIP limit. The more mature a system is, the lower its WIP limit can be made.

Why to do this practice

This practice results in higher work throughput, lower worker stress, and more consistent and predictable work throughput.

Who does this practice

All roles in a Lean-Agile organization.

For teams controlling WIP within a Kanban Management System, this especially involves the Product Owner, Team Agility Master, developers, testers, and special roles (e.g., UI, UX)

What to do

Keep the number of different work items being worked in a given step in the process at or below a limited number (the “WIP limit”)


Inputs to this practice include:

  • Information about how many work items are typically in process at any given time, for any given person or group of persons (e.g., “coders”)
  • Well-understood work process (for example, via a Value Stream Mapping)


  1. Prepare to become able to lower the WIP limit by removing delays in the process (using Value Stream Mapping) and reducing batch sizes.
  2. Set up a visual control to make it clear how many items a person or a group of persons (e.g., “the testers”) are being assigned to work on at the same time. A kanban board is good for this.
  3. Set policy so that workers will not be pressured to exceed their WIP limits. Set up means to highlight when WIP limits are exceeded. A kanban board is good for this too.
  4. Gradually decrease the WIP limit over time, to reveal bottlenecks in the system and remove them. This will increase overall team throughput.

When to do this practice

Initially, for instance when a kanban board is defined. Then, adjust on ongoing basis and follow up on discoveries of bottlenecks, by reducing their drag on throughput


This practice reduces over-tasking which is one of the biggest drains on productivity. The WIP limit can start somewhat larger but must then be intentionally driven to smaller and smaller numbers. This shrinking of WIP limits will allow ongoing work to reveal where the process has bottlenecks.

Bottlenecks are work steps in the value stream in which people cannot keep up with the amount of incoming work, so the people performing the bottleneck step fall behind and the work piles up in the work step before the bottleneck. This often happens in a QA or testing step for reasons such as the testers have been separated from the developers, too many errors are allowed during development due to process or tooling issues, or because too few people or too primitive tools have been allocated to testing. As bottlenecks are revealed, the organization/team should reduce them by a combination of making better use of the bottleneck resource (for example having developers and testers work together so fewer errors reach testing) and process improvement that reduces dependency on the bottleneck.