Overview

• What you’ll learn: Little’s Law and its implications for software teams, how to calculate and set WIP limits, the psychology of multitasking, and practical strategies for enforcing WIP limits.
• Prerequisites: Lesson 34 — Flow Metrics.
• Estimated reading time: 15 minutes

Introduction

In 1961, John Little proved a theorem that would eventually revolutionize how we think about workflow: Average Cycle Time = Average WIP ÷ Average Throughput. This elegant equation, known as Little’s Law, mathematically proves what intuition suggests: the more things you work on simultaneously, the longer each thing takes.

Little’s Law Explained

The formula: CT = WIP / TH

Where CT is average Cycle Time, WIP is average Work in Progress, and TH is average Throughput.

Example: If your team has 15 items in progress (WIP = 15) and finishes 5 items per week (TH = 5), then the average cycle time is 15 / 5 = 3 weeks. If you reduce WIP to 10, cycle time drops to 2 weeks — with the same team doing the same work.

This is not magic. When you have fewer items in progress, context switching decreases, focus increases, blockers get resolved faster (because there are fewer alternatives to hide behind), and items flow through the system more quickly.

The Multitasking Tax

Research by Gerald Weinberg suggests that with every additional project a person juggles, they lose approximately 20% of their productive capacity to context switching. With two projects, you are at 80% efficiency. With three, 60%. With five, you are spending more time switching than working.

WIP limits are not about working less — they are about losing less to waste.

How to Set WIP Limits

There is no universally correct WIP limit. Start with a simple heuristic:

1. Per-person WIP = 1 or 2. One primary item, one secondary (for when the first is blocked).
2. Per-column WIP = team size or slightly less. If you have 5 developers, try a WIP limit of 4 or 5 for the “In Development” column.
3. System WIP = slightly higher than comfortable. Start conservative and observe. If the team feels idle, raise it slightly. If items are aging, lower it.

The goal is not to find the “perfect” WIP limit. The goal is to use WIP limits as a catalyst for conversation. When a limit is about to be exceeded, the team must discuss: Should we help finish something first? Is something blocked? Should we raise the limit?

Enforcing WIP Limits

WIP limits are agreements, not suggestions. When a column is at its limit:

• Option 1: Help finish an existing item (pair, swarm, remove blockers).
• Option 2: Wait until an item moves to the next column.
• Option 3: Discuss whether the limit should be temporarily or permanently adjusted.

What you should never do is silently ignore the limit. That makes WIP limits decorative, not functional.

Key Takeaways

• Little’s Law: CT = WIP / TH. Less WIP = shorter cycle time.
• Multitasking imposes a 20% tax per additional project.
• Start with WIP = 1–2 per person, adjust based on data.
• WIP limits are catalysts for conversation, not rigid rules.
• Never silently ignore a WIP limit.