WIP Limit

A work-in-process (WIP) limit caps work already in progress within a defined stage or workflow. It helps teams finish and unblock work before starting more. DORA recommends making work visible, setting limits from usable capacity, and examining the obstacles those limits expose. A limit controls a count or other declared measure of work; it is not itself a measure of staffing capacity or a guarantee of higher throughput.

Define what enters and leaves

Choose a unit that makes demand visible, such as a change package awaiting integration acceptance. State its entry and completion conditions, expected size range, and treatment of blocked work, rework, and withdrawals. A column limit can govern admitted work while a separate queue waits upstream; show that queue and its age as well. Counting teams is different from counting changes: four teams can have twenty-three packages in progress if one has twenty and the others one each.

When a stage reaches its limit, help finish or unblock admitted work before pulling another item. Keep unresolved blocked work visible and counted within the declared boundary. If an authorized urgent exception temporarily exceeds the limit, record it, its consequences, and the revised commitments. Moving work off the board without resolving it hides demand. DORA advises investigating why people are waiting rather than relaxing a limit simply to keep them occupied; reassess the policy when evidence about capacity or workflow changes.

Capacity includes more than headcount

Account for skills, available time, support, meetings, reviews, technical debt, environment constraints, and variability. DORA’s example of four developer pairs and four development cards assumes that work arrangement; it is not a conversion formula for every process. Likewise, membership in two projects does not necessarily mean two tasks are being performed at once. A specialist may provide reserved sequential support. Assess simultaneous demand and switching costs, and specify priority and conflict-resolution rules. Dedicated staffing is an option when bounded sharing cannot meet commitments.

In a fictional rail program, two full-time engineers maintain a shared integration environment. The initial limit is four admitted, versioned change packages, each leaving only after its integration checks and receiving team’s acceptance. The engineers support automated checks; one package does not imply one permanently occupied engineer. Blocked and rework packages stay counted. Size and test duration are tracked, and a visible admission queue prevents waiting from disappearing outside the limit. Four is a provisional local policy to test, not a number implied by two engineers or seven consuming teams.

Check the flow, not just compliance with the limit

For that case, elapsed time runs from a valid integration request through acceptance, including admission waiting and rework. Completed-request medians move from nineteen calendar days in the eight weeks before recovery to two in weeks twenty-nine through thirty-six. Report open-request ages, withdrawals, work mix, and quality beside those medians. Staffing, interface agreements, testing, and WIP all changed, so the example does not identify the effect of the limit alone. DORA recommends examining whether limits expose obstacles and whether teams address them. Eleven Green Projects and One Red Program places this policy in the program plan; small batches concerns the size of each change rather than the number in progress.

References

• DORA, Work in process limits (CC BY 4.0)