After reading about an intriguing concept related to work in progress limits, I fell into a rabbit hole of research that kept pulling me deeper: mathematical principles and psychological findings that all point to the same uncomfortable conclusion. Doing more things at once means finishing fewer things, more slowly. (This wasn’t what I wanted to hear either.)
The equation you can’t argue with
Little’s Law is a foundational concept in queueing theory. The relationship is expressed as LT = WIP / TP, where Lead Time equals Work-In-Progress divided by Throughput. Little’s Law originates with John D.C. Little’s 1961 paper “A Proof for the Queuing Formula: L = λW” (Operations Research, Vol. 9). David Anderson later formalized its application to software development workflows in “Kanban: Successful Evolutionary Change for Your Technology Business” (2010), making WIP limits a centrepiece of the Kanban method.
The math is indifferent to your feelings about it. Working on multiple tasks simultaneously within a workflow prolongs the average time it takes to complete each one. Add more things to the pile, and everything slows down. Not because the people are less capable. Not because the process is broken. Because of arithmetic.
In the context of a Sprint, the equation translates directly: the more Product Backlog Items a team has in active development at once, the longer each item sits in progress before it reaches “Done.” A team working on twelve things simultaneously is no less than twelve times as productive as a team focused on fewer tasks. It is almost always slower.
This is the argument Scrum makes for Sprint Goals, not as motivational posters but as genuine constraints on scope. A committed Sprint Goal forces prioritization. It asks the team to decide what actually matters in this sprint and to protect that focus from everything else. The 2020 Scrum Guide reframed the Sprint Goal as a commitment precisely for this reason: focus has to be structural, not aspirational.
Your brain is not a processor farm
Beyond the mathematics, cognitive science confirms the same finding from a different angle. Miller’s law, from George Miller’s 1956 paper, tells us that short-term memory holds roughly seven objects, plus or minus two. When you switch between tasks, your brain must unload the current context and reload a new one. That transition is not free.
Research cited by Susan Weinschenk, Ph.D., puts the cost at up to 40 percent of your productivity. Forty percent. Not a rounding error. This is not an edge case for people who struggle to focus. A baseline cost, paid by everyone, every time.
We tend to explain this away. The interruptions are necessary, we say. The parallel tracks are unavoidable. Someone competent in their job should be able to handle it. The research does not support that story. Task switching is not a discipline failure. It is a structural problem, and it appears on the Poppendieck and Poppendieck list of seven wastes in software development, adapted directly from Taiichi Ohno’s Toyota Production System. Mary and Tom Poppendieck, “Lean Software Development: An Agile Toolkit” (2003), list task switching as one of seven wastes alongside partially done work, extra features, relearning, handoffs, delays, and defects. This is the direct lineage from lean manufacturing to agile software practice.
The word “waste” is doing real work here. It does not mean “bad habit.” It means value is being consumed without anything being produced. Every time a developer has to context-switch, the organization pays for the switch itself, not just the time spent on the task they switched to. Most cost models ignore this phenomenon. Most Sprint Reviews ignore it, too.
Fewer things. Actually fewer.
Researcher Matt Stine identified four concrete moves to reduce the damage of task switching, and they are all variations on the same principle: do fewer things at once.
Minimize context switches by reducing the number of simultaneous projects, not by getting better at switching, but by having fewer things to switch between. Rotate responsibility for handling interruptions across the team so the burden does not fall on the same person every time and become a permanent tax on one developer’s focus. Eliminate work and interruptions that do not deliver value, which requires the team to have a clear enough view of what value actually means to make that call. And ensure the knowledge needed for a task actually sits with the person doing it, so mid-task interruptions for information gathering become less frequent.
None of this work is so complicated. Most of it is obvious once stated. The difficulty lies in misunderstanding it. It resists the pressure to keep adding things to the plate because saying no to the next urgent request requires confidence in the priority you already chose, and that confidence is often lacking.
This is a scenario where the Scrum Master has a real job to do. Excessive task switching in a Scrum team is an impediment, and usually a structural one rather than a personal failing. The stakeholder who keeps pulling developers into quick calls. The product owner who adds urgent items mid-Sprint. The organization is running five parallel workstreams with the same people assigned to all five. A Scrum Master who sees this pattern and fails to name it is not protecting the team. They are watching the throughput drop and calling it a sprint.
Shielding the team from interruption, facilitating Sprint Goals that actually mean something, and keeping the Sprint Backlog focused enough to be meaningful. These are not process formalities; they are the practical application of Little’s Law. The goal is a shorter lead time. The method involves having fewer things in progress at once.
The question is not whether WIP limits work. The math settled that in 1961. The question is whether your organization is willing to act on what the math says or whether it will keep adding tasks to the queue and wondering why nothing ever gets done.