Limiting Work in Progress: Why Less Parallel Work Delivers Faster

Less parallel work delivers faster because, by Little's Law, average lead time equals the amount of work in progress divided by throughput. If a team halves the number of running initiatives at the same throughput, the time to a finished result halves too. Task switching adds to the effect: those who keep changing lose time that appears in no plan.

This article shows the calculation, backs it with findings from queueing theory and work psychology, and describes five steps by which a team introduces a limit on work in progress (WIP). It is written for managers who want to understand why full diaries and full boards rarely mean fast delivery, and who want to give their teams a rule that can be justified.

Why does less parallel work deliver faster?

Less parallel work delivers faster because work in a team only gets finished when someone works on it, and work that has been started but sits idle consumes time without creating value. The relationship can be calculated. Little's Law, proved by John Little in 1961, states for stable systems that the average number of items in the system equals average throughput multiplied by average lead time. Rearranged: lead time equals work in progress divided by throughput.

A worked example shows the effect. A team completes five tasks a week on average and has 30 tasks in progress. Average lead time is 30 divided by 5, which is six weeks. If the team limits work in progress to 15 tasks and still completes five a week, lead time is three weeks. The team has not achieved more, but every client receives the result three weeks earlier on average. The calculation holds for averages and assumes stable throughput, yet the direction is clear: reduce the amount of work in progress and you reduce the wait.

This relationship underlies the practice that the 2020 Kanban Guide describes as part of actively managing work. The guide asks a team to set a limit for each step of its workflow or for the workflow as a whole, and to keep to it until the team consciously changes it. David Anderson described the practice in his 2010 book on Kanban as a core element of the method. How the measures read in daily practice is shown in the article on flow metrics.

What does constant task switching cost?

Switching between tasks costs concentration, and the cost grows with the number of parallel initiatives. In a 2009 study Sophie Leroy described what she calls attention residue: those who move from an unfinished task to the next keep thinking about the first, and performance on the second declines. Gloria Mark and colleagues showed in 2008 that interrupted workers complete tasks faster but experience more stress, frustration and time pressure. Both findings come from experiments with knowledge tasks and count as a pointer for knowledge work generally.

In his 1992 book “Quality Software Management”, Gerald Weinberg gave a rule of thumb for dividing capacity among parallel projects: with one project all the time goes into the work, with two projects 40 per cent remains for each, with three 20 per cent each, and the rest is lost to switching. The figures are a practical estimate rather than a measurement, but the order of magnitude matches what teams experience when requests reach them from three directions at once.

In operations the effect shows in symptoms. Tasks sit in the “in progress” status for a long time without moving, and participants report interim states instead of delivering results. Shortly before a deadline the team works on everything at once. The article on waiting times in processes describes how much of lead time is waiting rather than working.

How does high utilisation affect waiting time?

High utilisation lengthens waiting time disproportionately, because a queue grows ever faster as utilisation approaches 100 per cent. Queueing theory describes this for the simplest case with the formula utilisation divided by one minus utilisation. An item's waiting time then amounts to a multiple of the processing time.

The table shows a model with random arrivals and random processing times, so it does not depict a specific team, but it shows the direction. A team at 95 per cent utilisation waits, in the model, nineteen times the processing time for each item. In 2009 Donald Reinertsen applied this curve to development processes in “The Principles of Product Development Flow” and questioned 100 per cent utilisation as a goal. A WIP limit prevents work from piling up at high utilisation, because new work starts only when room opens up in the flow.

How do you introduce a WIP limit in five steps?

You introduce a WIP limit in five steps that a team can complete in a few weeks.

1. Make the workflow visible: the team maps its actual steps, from intake to delivery, on a board. Items that appear nowhere are work that nobody steers.
2. Measure the baseline: for four weeks the team records current work in progress, lead time and throughput. These values show where the workflow stands today and serve as a comparison after the rollout.
3. Set the limit: a first limit sits just below today's amount of work in progress, at around 80 per cent. A fixed number, such as 1.5 tasks per person plus a reserve, gives the team orientation, and a review after a few weeks shows whether it fits.
4. Apply the rule: a new item starts only when another is finished. When the limit is reached, the team first helps to finish before anyone starts something new.5. Measure and adjust: after four weeks the team checks lead time and throughput. If lead time falls at the same throughput, the limit is lowered until the first bottlenecks appear. When a step stalls, that is the bottleneck where improvement begins.

The limit makes bottlenecks visible that previously disappeared in the noise of many open tasks. A team that discovers at a limit of ten that all items are waiting for one person's approval has found the bottleneck. The question then becomes how to speed up or spread the approvals.

What objections do people raise against WIP limits?

Three objections reach managers most often. The first is that idle time arises when someone cannot progress their item and may not start anything new. The team resolves this by helping colleagues to clear the bottleneck. The second is that clients would have to wait. That is true, but they wait before the start, where their request sits in a visible order, and they no longer face work that has long been running and is going nowhere. The third is that urgent tasks need exceptions. For these the team reserves a fixed slot in the flow for urgent items and checks how often it is used.

A portfolio needs a limit as well. A company that lets 40 initiatives run at once has the same problem as a team with 30 open tasks. The article on clearing out the project portfolio describes how a company reduces the number of initiatives without losing priorities. How WIP limits fit into an overall framework is covered in the article on choosing between Scrum and Kanban.

Limiting work in progress with Niehues Consulting

Niehues Consulting is a consultancy for AI management and organisational design from the delivery perspective, based in Düsseldorf. Founder Marin Niehues builds organisations that deliver, in projects from VC-funded scale-ups to DAX 40 corporations and in more than 20 countries on six continents. In the delivery management service he takes the role of delivery manager, project manager or product owner and steers deliveries across teams and departments.

The approach follows the Niehues Delivery Model. Three of its test questions count for limiting work in progress: what is the baseline, and how do we measure success? Which roles and decision paths does operations need? Which metric shows after 90 days that the solution has landed? For lead time the metric is obvious: it falls when the limit works. The scope and terms of an engagement are discussed in the free initial consultation, which you can arrange via contact.