Operations 9 min read

Controlling Work-in-Progress: The Lake‑Water‑Rock Effect and Principles for Setting WIP Limits

This article explains how to control work‑in‑progress using the lake‑water‑rock metaphor, outlines realistic and useful principles for setting WIP limits, describes common limiting methods such as swim‑lane caps, stage caps, and personal caps, and offers practical ways to determine initial limit values.

DevOps
DevOps
DevOps
Controlling Work-in-Progress: The Lake‑Water‑Rock Effect and Principles for Setting WIP Limits

The article continues a series on controlling work‑in‑progress (WIP) by focusing on the "how" aspect, introducing the lake‑water‑rock effect as a metaphor: the water level represents the amount of WIP, while rocks represent hidden organizational problems that become visible as the level drops.

Reducing WIP exposes issues such as coordination gaps between development and testing, or faulty assumptions in requirements, allowing teams to resolve them and improve delivery efficiency. As the water level lowers further, deeper problems emerge, requiring more substantial changes like organizational restructuring or pipeline integration.

Principles for setting WIP limits – limits must be realistic (aligned with the team’s current capacity) and useful (occasionally reached to signal problems). An appropriate limit is one that is hit occasionally—about once every one to two weeks—rather than constantly or never.

Common forms of WIP limits include:

Swim‑lane limits: restrict the maximum number of active items across the board, encouraging teams to finish work before starting new items.

Stage‑specific limits: cap the maximum number of items in a particular stage (e.g., a maximum of ten items awaiting testing).

Individual caps: limit the number of parallel tasks each team member can handle, often using physical tokens.

Determining an initial limit can be done by:

Deriving it from the current state—visualize work, eliminate obvious waste, and use the adjusted board’s concurrent item count as the starting limit.

Using team size—multiply the number of members by a reasonable parallelism factor.

Using target delivery cycle—apply Little’s Law (WIP = Cycle Time × Throughput) to calculate a theoretical limit based on desired cycle time and observed delivery rate.

The article concludes by summarizing the three‑part series on Kanban: visualizing value flow, making process rules explicit, and controlling WIP, which together form the foundation for a functional Kanban system.

operationsProcess ImprovementLeankanbanWIP limits
DevOps
Written by

DevOps

Share premium content and events on trends, applications, and practices in development efficiency, AI and related technologies. The IDCF International DevOps Coach Federation trains end‑to‑end development‑efficiency talent, linking high‑performance organizations and individuals to achieve excellence.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.