Reducing WIP: Why Finishing Beats Starting

The problem

A team can look fully busy and finish almost nothing: every name attached to something, standups full of motion, and an empty “shipped” column. The reflex is to read it as a staffing shortage. It’s usually a work-in-progress problem, and hiring makes it worse.

I nearly wrote the headcount case. End of a long quarter: nine initiatives in flight, everyone busy, the backlog growing — therefore, more hands. Then I listed every initiative with its start and finish dates. The “finished” column was mostly empty; the “started” column went back months. We weren’t short on people. We were short on endings. WIP had quietly climbed until the team spent more time switching between threads than moving any single one forward.

The model

Throughput is governed by how much work is in progress, not by how much you start. Little’s Law makes it concrete: average cycle time equals work-in-progress divided by throughput. Hold throughput roughly fixed — which is what capacity does — and every extra in-flight item stretches how long each one takes to finish. Start more, and everything finishes later. The activity is real; busyness just isn’t the constraint. Adding people to a system with no WIP discipline raises the number of half-done things and the tax of keeping them all alive. Finishing beats starting: a shipped thing has value and frees attention, while a started thing is a liability carrying interest.

What to do

Set explicit WIP limits and enforce finish-before-start. Each engineer carries at most one primary item; the team carries a hard cap on concurrent initiatives. Picking up something new requires closing something out.
Cut concurrent initiatives and swarm the survivors. Pause roughly half the in-flight work explicitly — a written “not now,” not a silent drift — then put multiple people on the items closest to done.
Measure cycle time and aging, not starts. Retire “how much did we kick off.” Track “how long are things taking” and “what is our oldest open item,” and name an aging work-item in standup.
Make starting expensive and finishing cheap. A new initiative needs a short justification and a parking decision for whatever it displaces; finishing gets celebrated and unblocked aggressively.

The results

Within about two months the numbers moved. Cycle time on a typical item dropped from roughly three weeks to a little over one — not because anyone worked harder, but because they worked on fewer things at once. Throughput, measured as items actually closed per month, roughly doubled with the same people, and the oldest open item went from “I’d rather not say” to under two weeks and stayed there.

The caveat: strict WIP limits are blunt, and early on they created visible idle moments — an engineer finished, the next item wasn’t groomed, and they sat waiting. The fix wasn’t to loosen the limit but to keep a small buffer of ready work and treat idle as a grooming signal, not a utilization failure. I set the limits too tight at first and had to walk a couple back. And WIP limits don’t do prioritisation for you — they force the hard “which one” conversations, they don’t have them for you.