Limiting WIP is a Superpower

If there were a single practice that could dramatically improve almost any kind of work, it would be limiting Work in Progress (WIP). It sounds deceptively simple—do fewer things at once—but in practice it is one of the most powerful levers available to teams and organizations.

Limiting WIP makes almost everything better. Even traditional, plan‑driven (waterfall) environments improve when fewer projects are running at the same time. But for Agile teams - especially those using Scrum, Kanban, or other forms of iterative development - limiting WIP is particularly relevant.

Why Doing Less Gets More Done

Most organizations suffer from a common misconception: that starting more work leads to finishing more work. In reality, the opposite is usually true. When too many things are in progress at once, several predictable problems emerge:

• Context switching drains focus and productivity.

• Partially done work piles up, delivering no value until it’s finished.

• Bottlenecks form, often invisibly, until they cause last‑minute chaos.

• Feedback is delayed, which increases rework and frustration.

Limiting WIP directly counters these problems. By constraining how much work can be started, teams are forced to focus on finishing. Flow improves, quality improves, and stress goes down.

Agile Teams Feel the Pain of Excess WIP First

Agile teams tend to feel the impact of excessive WIP more acutely because they operate in short cycles and rely heavily on collaboration across roles. Scrum teams, in particular, often experience a familiar pattern:

• Early in the Sprint, developers are busy building, while testers wait.

• Late in the Sprint—often the last few days—testers are overwhelmed, while developers run out of new work to start.

• The Sprint ends with a large chunk of planned work unfinished and carried over.

This isn’t a people problem. It’s a system problem. And the system is usually overloaded with work in progress.

A Real‑World Scrum Team Example

I once worked with a Scrum team that was really struggling. Sprint after Sprint, they were completing only about 60% of the work they planned. Morale was low. Testers felt crushed at the end of every Sprint, and developers were frustrated by the constant stop‑start rhythm of their work.

When we looked closely, a clear pattern emerged. During the first half of the Sprint, testers often didn’t have enough meaningful work to do. During the second half—let’s be honest, usually the last few days—they were completely overwhelmed. Developers, meanwhile, had already moved on to new items and were waiting for feedback.

The issue wasn’t a lack of skill or effort. It was too much work in progress.

The Changes We Made

We didn’t overhaul their process or add new roles or tools. We made two simple but powerful changes.

1. Cut Work Smaller

First, we focused on slicing work into smaller pieces. Every Product Backlog Item pulled into the Sprint had to be small enough to be realistically completed within that Sprint—including development, testing, and any other work needed to reach “Done.”

Smaller items reduced risk and made it easier to keep work flowing across the team instead of piling up at the end.

2. Limit WIP to One Item per Developer

Next, we introduced a strict Work in Progress limit: no more than one item per developer at a time.

This turned out to be incredibly effective. When a developer could only work on one item, a few important things happened automatically:

• They focused on finishing, not starting.

• They passed work to testers as soon as it was ready instead of holding onto it.

• They stopped task‑switching and juggling multiple partially done items.

If their current item was blocked, they helped unblock it—or helped someone else—rather than pulling in new work.

The Results

The impact was immediate and measurable. The team went from completing about 60% of planned Sprint work to over 80%.

But that wasn’t the most important outcome.

The real win was flow.

Work moved through the system faster. Testers and developers were busy at the same time, working together instead of in waves. The stressful end‑of‑Sprint crunch largely disappeared. People felt calmer, more focused, and more satisfied with their work.

Limiting WIP didn’t just help the team deliver more—it helped them deliver sooner, with less frustration.

Why Limiting WIP Works So Well

Limiting Work in Progress forces teams to confront reality:

• You can’t finish what you don’t focus on.

• Starting work has a cost.

• Value only exists when work is done.

By making WIP visible and constrained, teams naturally optimize for completion, collaboration, and quality.

This is why limiting WIP is foundational in Kanban, critical for healthy Scrum Sprints, and beneficial for anyone doing iterative or incremental development.

The Superpower Hiding in Plain Sight

Limiting Work in Progress doesn’t require a new framework, a big reorganization, or heroic effort. It requires discipline—and the courage to say “not yet” to starting new work.

That’s why it’s a superpower.

Whether you’re running multiple large projects, leading a Scrum team, or trying to improve flow across an entire organization, start here. Do fewer things at once. Finish what you start. Let flow do the rest.

Join us for the Professional Scrum with Kanban class and we will prove to you through a series of fun activities that limiting work in progress is a superpower.