A team finishes 5 items a week and has 14 items in progress. What's the average cycle time, and what happens if WIP drops to 5?

By Little's law, cycle time = WIP / throughput = 14 / 5 = 2.8 weeks; at WIP 5 it's 1 week — each item finishes almost three times sooner at the same throughput.

An engineer is blocked waiting for a vendor. What should they do under a WIP limit?

First help finish something already in progress — review, pair, test — rather than starting a new item; track the vendor wait visibly as an external blocker.

How do you choose an initial WIP limit?

Start around the number of engineers (or a bit lower), observe cycle time and blockers for a couple of sprints, then lower it gradually.

Limiting Work in Progress — The Team Lead Handbook

Scenario

Example team: the checkout team's board shows 14 items "in progress" for six engineers. Each engineer juggles two or three items and reviews for others. Items take three weeks on average from start to done; product asks why "small changes" take so long.

What you see on the team

Many items in progress, few finishing.
Long cycle times even for small items.
Constant context switching; items wait for review or for an answer.
Everyone busy, nothing done.

The common mistake

Maximising utilisation (everyone always busy, start new work when blocked) instead of flow (finish work before starting more).

Why it happens

Starting something new feels productive when you're blocked. But every started item adds to the queue, and Little's law links them: average items in progress = throughput × average time each item takes. If throughput stays the same, more work in progress means each item takes longer — the team just holds more half-finished work.

Little's law: same throughput, different WIPTry it yourself

throughput_per_week = 5.0   # items the team finishes per week (stable)

for wip in (14, 8, 5):
    cycle_time_weeks = wip / throughput_per_week     # Little's law: W = L / lambda
    print(f"WIP {wip:2} items -> average cycle time {cycle_time_weeks * 5:4.1f} working days")

print("\nSame team, same throughput: cutting WIP from 14 to 5 delivers each item ~2.8x sooner.")

Output

WIP 14 items -> average cycle time 14.0 working days
WIP  8 items -> average cycle time  8.0 working days
WIP  5 items -> average cycle time  5.0 working days

Same team, same throughput: cutting WIP from 14 to 5 delivers each item ~2.8x sooner.

In practice, lower WIP also raises throughput, because there's less context switching and work waits less for reviews.

The playbook

Make WIP visible: one card per item on a board with columns that show waiting (e.g. "ready for review").

Set a team WIP limit: start around the number of engineers (or fewer), then lower it gradually. Atlassian's guide to WIP limits describes the same approach.

"Stop starting, start finishing": when blocked, help finish something already in progress (review, pair, test) before pulling new work.

Swarm on the oldest item: in standup, walk the board right to left — what's closest to done, and what does it need?

Measure cycle time and WIP weekly (next lesson).

What to say

In standup:

"Let's walk the board from the right. The refund fix has been waiting for review for two days — who can take it now? Before anyone starts something new, can we get these three to done?"

Introducing a WIP limit:

"We have 14 items in progress for six people. Let's try a limit of six for the next two sprints and see what happens to cycle time. If someone is blocked, the first move is to help finish something else."

Trade-offs

Idle-looking time: with WIP limits, people sometimes pair or review instead of starting new work. That's the point — but it can feel uncomfortable.
Too low a limit can starve the team when items are genuinely blocked externally; adjust it with data.
Some work is truly parallel (long-running tests, vendor waits); track external waits separately.

Signals it's working

WIP stays at or below the limit.
Average cycle time falls; small changes ship in days.
Fewer items waiting for review.
Throughput holds or rises.

Key points

Little's law: WIP = throughput × cycle time, so at stable throughput more WIP means slower delivery.
Make WIP visible, set a team WIP limit and lower it over time.
Stop starting, start finishing: help finish before pulling new work.
Walk the board from the right in standup and swarm on the oldest items.