Introduction
If your team is always busy but cycle times bounce all over the place, you don’t have a motivation problem—you have a flow problem. Little’s Law in Scrum turns that chaos into math you can manage: average WIP × average time in system are tightly linked to throughput. Use that relationship to set smarter WIP limits, balance arrivals to completions, and stabilize cycle time.
In this guide, you’ll learn how Little’s Law works in everyday Scrum, how to design WIP experiments, and what effects to expect. You’ll walk away with a practical playbook to move your team from hectic to predictable.
Little’s Law for Humans (Not Math Textbooks)
The idea: In a stable system,
Items in system (WIP) = Throughput × Cycle Time.
Rearrange it and you get Cycle Time = WIP ÷ Throughput. When you lower WIP (and keep throughput steady), cycle time goes down—predictably. Wikipedia
What “stable” means for Scrum teams:
- Your work items are broadly comparable (or you at least track types separately).
- Arrival rate ≈ completion rate over time (you’re not starting way more than you finish).
- Policies (Definition of Workflow, WIP limits, pull rules) don’t change every other day.
If that sounds like Kanban, you’re right. The Kanban Guide for Scrum Teams explicitly recommends flow metrics and WIP limits inside Scrum. Scrum.orgscrumorg-website-prod.s3.amazonaws.com
Why WIP Limits Are the First Lever
If you consistently start more than you finish, WIP swells, context switches multiply, and everything slows. WIP limits create a pull system: you finish the oldest work before starting new work. That’s the fastest route to shorter cycle times and steadier delivery. The Kanban Guide for Scrum Teams calls out WIP limits and flow metrics (Throughput, WIP, Work Item Age, Cycle Time) as essential practices. Scrum.orgscrumorg-website-prod.s3.amazonaws.com
Back-of-napkin example:
- Current throughput: 10 items/week.
- Current WIP across active states: 25 items.
- Expected cycle time: 25 / 10 = 2.5 weeks.
- If you cap WIP at 15 (and keep throughput similar), expected cycle time drops toward 1.5 weeks.
Balance Arrivals to Throughput (Stop Overfeeding the System)
Even with WIP limits, you can still inject too much work into “In Progress.” A simple guardrail: don’t start more items per week than you typically finish per week. That keeps arrivals ~ throughput and helps the system meet Little’s Law’s stability assumption. In practice, this looks like capacity-aware Sprint Planning and pull-based Daily Scrums that prioritize finishing. The Kanban-within-Scrum guidance encourages exactly that flow-centric lens. Scrum.org
Also note: Industry benchmarks treat lead/cycle time as core indicators of performance (one of the DORA “four keys”). If you’re aiming for real predictability, improve those first. Dora
Step-by-Step WIP Experiments (with Expected Effects)
Experiment 1 — Set Column WIP Limits and “Finish Oldest First”
Steps
- Add WIP limits to active workflow states (e.g., Dev 6, Code Review 4, Test 3).
- In Daily Scrum, sort each column by oldest first and swarm the top card until it moves.
- Only pull a new item when the destination column is below its WIP limit.
Expected effect
- Cycle time trends down (by Little’s Law) as WIP shrinks.
- Throughput often rises slightly once context switching drops.
- Predictability improves as fewer items age out. Kanban-in-Scrum explicitly recommends these policies. scrumorg-website-prod.s3.amazonaws.com
Quick math sample
- Throughput ~ 12 items/sprint, WIP 24 → Cycle Time ≈ 2 sprints.
- After limits, WIP 14 → Cycle Time ≈ 14/12 = 1.17 sprints (≈ 40–45% faster).
Experiment 2 — Gate Arrivals with a “Throughput Budget”
Steps
- Compute average items finished per Sprint over the last 3–5 Sprints (throughput).
- In Sprint Planning, cap newly-started items to ≤ average throughput.
- Keep a small buffer for urgent work; replenish only when WIP drops.
Expected effect
- Arrival rate ≈ completion rate, stabilizing WIP and cycle time.
- Fewer half-done items at Sprint end; Sprint Goals become achievable.
Tip: Many orgs still over-index on velocity; the 2024 State of Agile found 36% of teams are measured on velocity vs 29% on value delivered. Shift attention to flow outcomes (cycle time, predictability). 2288549.fs1.hubspotusercontent-na1.net
Experiment 3 — Add a Work Item Age Alarm + Service Level Expectation (SLE)
Steps
- Pick an SLE (e.g., “85% of items finish ≤ 8 days”).
- Show Work Item Age on cards; flag any that near/exceed the SLE.
- In Daily Scrum, swarm aging items first; escalate blockers within 24h.
Expected effect
- Stuck work is surfaced early; WIP stops quietly ballooning.
- Cycle time distribution tightens; predictability goes up. (These flow practices are recommended for Scrum teams using Kanban.) Scrum.org
Experiment 4 — Batch Size Trim: “Slice to Thin, Independent, Valuable”
Steps
- Split large stories into independent, thin slices with clear acceptance criteria.
- Refuse to start any slice that spans multiple teams without a dependency plan.
- Track cycle time by work item type; tune WIP per type if needed.
Expected effect
- Smaller batch sizes move faster through the same pipeline; WIP needed is lower, so cycle time drops (Little’s Law again).
- Throughput becomes steadier because items are more uniform in size.
Measuring Flow the Simple Way (and Where to Use It in Scrum)
Minimum set to track:
- Throughput (finished items per Sprint/week)
- WIP (items started but not finished)
- Work Item Age (time since start, for in-progress items)
- Cycle Time (start → finish)
The Kanban Guide for Scrum Teams recommends these four metrics and applying them in every Scrum event (Planning, Daily, Review, Retro). Use them to right-size Sprint scope, focus daily on flow, show real delivery capability in Reviews, and choose one improvement experiment per Retro. Scrum.org
Common Pitfalls (and Fixes)
- Hidden queues (e.g., “Waiting for QA” that isn’t modeled): add the state and limit it.
- Unstable arrivals (big spikes of “urgent” work): reserve explicit capacity for expedite and keep it small.
- All WIP limits, no policy: write a Definition of Workflow (entry/exit rules, pull policy, blocked policy). The guide emphasizes explicit policies. scrumorg-website-prod.s3.amazonaws.com
- Velocity obsession: complement story points with throughput and cycle time to forecast by items as well as points. DORA’s focus on lead time underscores why. Dora
Internal Resources (for deeper help)
- Improve flow with the Kanban Program — hands-on coaching to implement WIP limits, SLEs, and pull-based planning. igorlakic.com
- Make decisions with evidence using the Evidence-Based Management Program — focus on outcomes and real capability. igorlakic.com
- Related reading: Stop Carryover: End Unfinished Sprints with Flow Metrics. igorlakic.com
Frequently Asked Questions
Q1: Does Little’s Law work with story points?
Yes. Little’s Law is about items, not estimates. If you keep your item sizes reasonably uniform (or track by type), the relationship holds well enough for planning and forecasting. For mixed sizes, compare per type.
Q2: Where should WIP limits live—in columns or per person?
Prefer column (team) limits. They enable swarming and reduce idle pockets. Use per-person caps only to reveal skill bottlenecks temporarily, then invest in skills/pairing to remove them.
Q3: How do I pick our first WIP limit?
Start with 1–2 items per person per active state, then tune based on Work Item Age, blocked trends, and your SLE breaches. The Kanban-in-Scrum guidance encourages explicit WIP and active item management. scrumorg-website-prod.s3.amazonaws.com
Q4: Are lead time and cycle time the same?
Not always. Cycle time is start → finish in your workflow; lead time can include waiting before start and deployment after finish. DORA treats lead time for changes as a core performance metric. Dora
Conclusion & Next Step
Little’s Law in Scrum gives you a steering wheel: limit WIP, gate arrivals to match throughput, and watch cycle time stabilize. Start with the WIP experiments above, measure with simple flow metrics, and iterate your policies. You’ll trade “always busy” for reliably predictable.
Want help applying this to your specific context? Let’s design a flow-based plan together—book a session via the Kanban Program or EBM Program.
