Once a month, four customer groups sat down with the managers of a small Microsoft IT team, XIT Sustained Engineering, to rank everything the team had been asked to do.
The list had more than 80 change requests on it. It grew by as many as ten a month. The team finished six or seven. So most of what got ranked at each meeting would not be touched before the next one, and would be ranked again. Requests slid later and later. Due dates were missed and renegotiated “time and again,” in the words of the two people who later wrote it up.
Meanwhile, every new request had to get a rough estimate within 48 hours. A developer and a tester each spent about half a day on it. Estimating took up to 40% of the team’s capacity, though only about half the requests it estimated were ever built. And since the estimate was often made months before the work, by someone who might not end up doing it, whatever had been learned was gone by the time anyone started.
Dragos Dumitriu, who became the team’s program manager in September 2004, stopped both. The up-front estimates went, and only a small, fixed number of approved requests could wait in front of the developers. A request got a delivery date only when it got one of those slots. When a slot opened, the customers agreed among themselves which request should fill it.
By the account Dumitriu and his colleague David Anderson gave in a 2005 conference paper, the same six people went from finishing 17 requests a quarter to 44 within a year. Once a request got a slot, it typically reached user testing in 12 to 14 business days. Later, with two more people, the cap on development stood at about twelve: seven waiting and five in progress. The case has the rest.
Less in, more out
A cap on work in progress, or WIP, sounds like a way to do less. The team’s own explanation of why it did more comes down to three things. The cap held new work back “at a rate that the team could consume it.” It kept people “single-tasking,” moving one request through before picking up the next. And it made customers focus “on what is most important at that moment in time,” because a free slot was scarce.
There is arithmetic behind the speed, too. In 1961 the operations researcher John Little proved that, for a system running steadily over time, the average number of items in it equals the rate they arrive multiplied by the average time each one spends inside. Turn that around and, if the team finishes work at the same rate, half as much work in the system means the average time each piece spends there halves. That is Little’s law.
Little was careful about what his law does not do. It is “not in charge of changing these quantities,” he wrote in 2011. A cap can shorten the average time work spends inside the capped stage, if output holds up. It doesn’t make the wait from the customer’s first request disappear: work held outside the stage still waits, just before it starts, as the designer below finds. And it doesn’t by itself make anyone work faster. At XIT, the extra output came from what the cap made room for: no more estimating work that would never be built, no more monthly re-ranking, and a tester moved to development once it was clear testing had slack.
Nine projects open
Imagine a freelance designer with nine client projects open. Each gets a little progress each week, and each client emails to ask where things stand. Answering those emails, and reloading each project in her head, eats most of a morning.
She tries a rule: three projects active, the rest in a queue with a start date. Clients at the back wait longer to start. Once started, their work comes back in days instead of weeks. Whether she finishes more in a month depends on whether the switching time really goes away, and she can count that.
Agents start fast
AI agents make it cheap to start work, and the problem shows up in their own design. Anthropic’s engineers wrote in 2025 that early versions of their multi-agent research system made errors like “spawning 50 subagents for simple queries” and “distracting each other with excessive updates.” Their fix was to write limits into the prompts. Simple fact-finding gets one agent with 3 to 10 tool calls. Complex research might get more than 10 subagents “with clearly divided responsibilities.”
For most people using agents, though, the tighter limit sits downstream, at their own review. Start ten agent tasks before lunch and properly check three in the afternoon, and the other seven are work in progress, waiting on you. Like XIT’s estimates, the context you had when you assigned them fades while they wait.
So count the pile you haven’t reviewed, and give it a cap. When it is full, the next thing to do is finish checking something, not start another agent.