The Shared Design Studio
Three product teams share a four-person design studio. Requests arrive through a quarterly intake meeting, but product managers also send 'small' requests by chat. The studio's board has Design (WIP 14), Review (WIP 6) and Handoff (no limit). Average throughput is four designs per week and average lead time is 3.5 weeks. The studio calculates that 14/4 = 3.5, so it believes WIP is fine. Product teams complain that work is invisible until handoff; two designs have waited 12 days in Review because reviewers are also designers. The studio insists every design is on the board, so it sees no hidden work. The quarterly intake adds 20 requests at once, and the studio starts them all to 'show progress'. The head of product wants a dashboard showing design utilisation at 100% to justify more headcount.
1. Evaluate the studio's use of Little's Law and its conclusion that WIP is fine.
Read the worked answer
The calculation is arithmetically correct: 14 / 4 = 3.5 weeks. The conclusion is not. Little's Law describes the relationship between WIP, throughput and lead time; it does not say that the resulting lead time is acceptable or that WIP is fine. A 3.5-week lead time for design work may be a business problem, and the studio can reduce it by lowering WIP, improving throughput, or both. The WIP figure is also suspect: 14 may exclude chat requests and work waiting in Handoff, which has no limit. Review has a limit of 6, but two items waited 12 days because reviewers are also designers, so the limit is not protecting review capacity. The head of product's target of 100% utilisation would make the problem worse: at 100% utilisation, queues grow and lead time rises. The studio should treat WIP as a control, not a badge. It should measure lead time from request to handoff, including hidden chat requests, set a WIP limit below 14, and test whether lead time falls without losing throughput. The aim is shorter, more predictable flow, not maximum busyness.
2. Design a replenishment and intake policy that reduces batch starts and hidden requests.
Read the worked answer
Create one visible intake point and a regular replenishment cadence. All requests, including small chat requests, should enter the same queue or be explicitly rejected by policy; otherwise the board is incomplete. Define a definition of ready for design work, including a clear problem statement, constraints and decision-maker. At replenishment, product managers and the studio review the queue, apply classes of service, and pull only up to the available WIP slots. The quarterly intake should not release 20 requests into design at once; it should populate the ready queue, and work should be pulled as capacity frees. Publish capacity allocation across the three product teams, for example a percentage or a slot count, so the queue is transparent. Set WIP limits for Design, Review and Handoff, and make Handoff a real state with a policy. Use a fixed cadence for replenishment, such as weekly, and a separate operations review for flow. This reduces batch starts, makes chat requests visible, and gives product teams a predictable queue rather than a race for attention.
3. How should the studio handle review capacity and handoff to avoid the 12-day wait?
Read the worked answer
Treat Review as a constrained state with its own WIP limit that includes items waiting for a reviewer, not just active reviews. If reviewers are also designers, their review capacity competes with design work; make that trade-off explicit by reserving review time or separating reviewer duties for part of the week. Use a pull policy: a design cannot enter Review unless a review slot is free, and reviewers should swarm on the oldest review rather than start new design work. Reduce batch size by reviewing smaller increments earlier. Define a handoff policy with a definition of done for design, including what the receiving product team needs. Track aging in Review and Handoff; a 12-day wait is a signal to change policy, not to ask designers to work faster. If review is a genuine bottleneck, consider cross-training or a review rota, but do not solve it by removing the limit. The goal is to shorten the queue and make review capacity visible. Also check whether review and handoff are separate states; if they are combined, waiting time is hidden.