Kanban & Flow-Based Work: WIP Limits & Continuous Delivery

The Software Development Lifecycle

Chapter 4 · Kanban & Flow-Based Work: WIP Limits & Continuous Delivery

Scrum timeboxes work into sprints. Kanban timeboxes nothing — work is pulled continuously, one item at a time, the moment capacity opens up. Chapter 1's own interruption-cost finding already showed why unlimited work-in-progress is expensive; this chapter verifies the deeper, more precise reason WIP limits are Kanban's own central mechanism, using a well-known result from queueing theory that turns out to hold almost exactly in a real simulation.

Pull vs. Push, and the Metric That Actually Matters

Scrum plans a batch of work at the start of a fixed period (Chapter 3's own sprint). Kanban has no period — a team member pulls the next item from the backlog the moment they have capacity, and a strict work-in-progress limit caps how many items can be "in progress" across the whole board at once. The question this chapter answers: what does that limit actually protect against, precisely?

WIP Limits, Verified Across a Spectrum

# a team round-robins between whatever items are "in progress," # paying a real switching cost each time they move to a different one REORIENTATION_COST = 3 # minutes N_ITEMS = 20 ITEM_EFFORT = 10 # minutes of real work per item
WIP limitTotal time (min)Avg cycle time (min)
120010.0
279779.7
3797115.7
5797197.8
10797390.9
20797761.9
Verified directly — total completion time went nearly flat past WIP=2, but average cycle time kept climbing almost linearly
Once WIP exceeds 1, total time to finish all 20 items barely changes — 797 minutes, regardless of whether WIP is 2 or 20. But the average time any individual item took to actually finish grew from 79.7 minutes at WIP=2 to 761.9 minutes at WIP=20 — nearly 10× worse, for the same total throughput.
Verified directly — this is Little's Law, confirmed numerically, not just asserted
Little's Law, from queueing theory, states cycle time equals WIP divided by throughput. Computing throughput directly from the simulation (items completed ÷ total time) and multiplying by WIP: the predicted cycle time matched the measured cycle time closely at every WIP level tested — WIP=2: predicted 79.7, measured 79.7; WIP=10: predicted 398.5, measured 390.9; WIP=20: predicted 797.0, measured 761.9.
This is the precise version of Chapter 1's own finding
Chapter 1 showed unlimited WIP wastes real time overall. This chapter shows something sharper: even when total throughput barely changes, every individual piece of work sits "in progress but not actually progressing" for far longer as WIP grows. A stakeholder asking "where's my feature?" cares about cycle time, not aggregate throughput — which is exactly why Kanban boards cap WIP explicitly rather than just trying to work faster.

Cumulative Flow Diagrams: Making a Bottleneck Visible

BUILD_RATE = 4 # items entering "awaiting review" per day REVIEW_RATE = 2 # items Review can actually process per day
Verified directly — a capacity mismatch between two stages produces a growing, visible backlog
Tracking cumulative items built vs. cumulative items reviewed over 10 days: the gap between the two — items waiting for review — grows every single day, from 2 on day 1 to 20 by day 10. A cumulative flow diagram is exactly this data plotted as bands over time; a widening band between two adjacent stages is the bottleneck signal, visible without needing to ask anyone where the slowdown is.
A WIP limit on the bottleneck stage doesn't remove the bottleneck — it makes it impossible to hide
Without a WIP limit, Build keeps producing at 4/day even though Review can only absorb 2/day, and the growing backlog sits invisibly in a queue. A WIP limit on "awaiting review" of, say, 4 would force Build to slow down or stop once that cap is hit — converting an invisible, growing backlog into an immediate, visible signal that Review is the actual constraint, precisely when it becomes one.

When Kanban Fits Better Than Scrum

ScrumKanban
Best fit forPlanned feature work with a natural batch boundaryContinuous, unpredictable work — support queues, ops, ongoing maintenance
CadenceFixed sprint length (Chapter 3)Continuous — an item ships the moment it's done
Primary leverRealistic commitment at planning (Chapter 3's own 100%-vs-57% finding)WIP limit (this chapter's own cycle-time finding)

Where This Connects

This chapter's findingWhat it connects to
Cycle time scaling with WIP even as total throughput stays flatChapter 1's own 27.5%-slower interruption finding — the same underlying cost, measured more precisely
A cumulative flow diagram exposing a bottleneck automaticallyChapter 9's own retrospective material — a CFD is exactly the kind of concrete, undisputable data a good retrospective works from

Hands-On Exercises

Exercise 1

Using this chapter's own WIP simulation, add WIP=4 to the tested spectrum. Determine its total time and average cycle time, and verify Little's Law's own prediction (WIP ÷ throughput) against the measured result, the same way the chapter did for the other WIP levels.

📄 View solution
Exercise 2

Using this chapter's own cumulative flow simulation, raise REVIEW_RATE from 2 to 4 (matching Build's own rate). Determine how the "waiting for review" backlog behaves over the same 10 days, and explain what this reveals about a CFD's own bottleneck signal when capacities are matched.

📄 View solution
Exercise 3

Using this chapter's own cumulative flow simulation, apply a WIP limit of 6 to the "awaiting review" queue — Build stops producing new items once 6 are waiting, resuming only once Review absorbs one. Determine how many days it takes to process all of Build's own first 40 items under this constraint, and compare it to the unconstrained version's own day-10 backlog of 20.

📄 View solution

Chapter 4 Quick Reference

  • Pull vs. push: Kanban pulls the next item on demand; Scrum plans a fixed batch for a fixed period
  • Verified: raising WIP from 2 to 20 left total completion time nearly flat (797 min) but multiplied average cycle time by ~10x (79.7 → 761.9 min)
  • Verified: Little's Law (cycle time = WIP ÷ throughput) predicted the measured cycle time closely at every WIP level tested
  • Verified: a capacity mismatch between two pipeline stages produced a visibly growing backlog — 20 items waiting after just 10 days
  • The real lever: a WIP limit doesn't just save total time — it keeps any individual item's own cycle time from ballooning, and makes bottlenecks visible instead of hidden in a queue
  • Next chapter: Requirements & User Stories — what actually goes into the items pulled through this flow