WIP: What It Is, What It Isn’t, and Why It Still Matters

‍You don't need to "start using WIP." You already are.

Every team has WIP. Whether you measure it or not. Whether you manage it or not. Whether you believe in flow or still mistake backlog grooming for delivery.

Work In Progress isn't a tool in your kit; it's a condition of your system. It's there. It's shaping your outcomes. And most of us are ignoring it.

That's a problem. Because WIP is the strongest driver of your system's behaviour, and it doesn't just reflect your delivery health, but actively shapes it. Get it wrong, and unpredictability is baked in. Treat it like a vanity metric or a board decoration, and you're flying blind.

Dan Vacanti, in the new 10th anniversary update of Actionable Agile Metrics, doesn't mince his words:

“If you have a problem with predictability, you have a problem with WIP.”

This post isn't about using WIP to "go faster." It's not about setting a WIP limit of three and patting yourself on the back. It's about understanding what WIP really is, what it tells you, and how it quietly governs everything from coordination cost to cycle time to whether your team ever feels "in control" of their work.

Shall we get started?

1. WIP: A Definition, Not a Directive

“WIP isn’t a practice. It’s a fact.”

You don't "do" WIP. You have WIP. At all times. It's the count of items your team has started but not yet finished. That's it. Nothing fancy. But boy, it's loaded.

WIP isn't:

• The number printed above a column on your board.
• A guideline to be waived "when things get busy."
• A cheat code for delivery.

WIP is:

• Everything you've started but not finished (however you have defined that).
• A real-time signal of load in your system.
• The biggest determinant of your delivery experience.

Here's something worth repeating: you don't get to choose whether you have WIP. You already do. The only choice is whether you see it and are willing to face up to what it's telling you.

Most teams don't. They confuse "WIP limit" with "WIP awareness." But WIP is a system condition, not a constraint you set. It's the reality of what's in motion, whether you like it or not.

Before you manage WIP, limit WIP, or optimise WIP…

Start by seeing it.

2. Why WIP Matters

“WIP doesn’t just reflect your system, it shapes it.”

WIP isn't some passive stat sitting on the sidelines. It's an active force. Every item you start adds friction - that's:

• More to coordinate.
• More to track.
• More to mentally juggle.

And every item you delay finishing? That's more time something spends stuck in the system, ageing like unpasteurised milk.

High WIP means:

• Context switching that kills flow.
• Coordination overhead that eats up your day.
• Delays that stack unpredictably.
• Flow debt that you'll pay later, with the required amount of interest.

But low WIP isn’t the goal either. Too little, and you risk starving the system; idle hands, blocked flow, wasted capability, and value left on the table.

Here's the nuance most teams miss:

Managing WIP doesn't always mean keeping it low.

It means keeping it appropriate. Calibrated. Tied to your system's actual capability, not its aspirations.

Think of WIP like your pulse. It doesn't tell you everything. But ignore it, and you'll miss the signs when things are going wrong. WIP spikes often precede system chaos. And persistent high WIP? That's not capacity, that's a slow bleed of predictability.

WIP is a mirror. If your reflection looks overworked, bloated, or slow, don’t blame the mirror.

3. WIP in Little's Law and the Five Constraints That Make It Work

“The law is elegant. But it only applies if your system behaves.”

Little's Law is a favourite among flow practitioners. You've probably seen it a hundred times:

Average WIP = Average Throughput × Average Cycle Time

It’s not a per-item rule. It’s not a forecast tool. It’s a long-run average relationship; like all averages, it hides as much as it reveals.

That tidy equation only holds if your system is stable, consistent, and obeys five specific constraints. Break even one, and the math still looks right, but the reality underneath is chaos. These constraints aren't academic; they're the health check.

The five non-negotiables:

1. Items that enter the system must eventually exit the system.
   No zombie cards. No half-finished mysteries. No, "we kind of started that."
2. Arrival rate ≈ departure rate.
   Input and output need to roughly match over time. No hoarding. No starvation.
3. The age of work items must be bounded.
   If nothing ever finishes, the system collapses. Ageing without limit breaks flow.
4. WIP must stay roughly steady.
   Your system can flex, but wild WIP swings mean you're flying without a safety harness.
5. Units must be consistent.
   Don't compare apples to oranges. Or features/month to tasks/week.

Here's the kicker:

You can plug numbers into Little’s Law and still lie to yourself.

That’s the danger of averages. They smooth over the volatility. They hide the spikes. They make the system look predictable while silently breaking under the surface.

So don't just quote the equation. Test your system against the constraints.

And if your WIP is climbing while work item age grows?

That's not a coincidence. That's a system quietly breaking.

4. What WIP Can and Can't Tell You

“WIP tells you how much is in play. It doesn’t tell you how long it’s been stuck.”

Let's be clear: WIP is foundational. But it's not a mind reader. It can't tell you where the bottlenecks are hiding. It doesn't know which card has been gathering dust for 27 days. It won't tell you if something is urgent, blocked, or just forgotten.

That's not a weakness, it's just scope.

WIP shows the size of the storm, not where the lightning is striking.

Think of it like this:

• WIP tells you how many things are in progress.
• It doesn't tell you how old any of them are.
• Or how risky.
• Or whether something’s quietly past its use-by date.

That's why Work Item Age matters. That's your early warning signal. But that's another post.

So let's be clear, when WIP goes unmanaged, you create the conditions for everything else to go wrong. Ageing work, surprise delays, and broken forecasts thrive in a system where "started" work quietly piles up.

WIP won’t explain your problems, but it will shine a very bright light into the corners where they’re accumulating.

So no, it's not enough. But it's never optional.

5. Managing WIP (Beyond Limits)

“WIP limits are just one kind of policy. Managing WIP is a team habit.”

Let's kick a myth into touch:

WIP limits on your board ≠ WIP management.

That [3] above your “Development In Progress” column? It’s meaningless if nobody respects it. If you ignore it whenever you're up against it, it’s not a policy, it’s just writing on the wall.

Yes, WIP limits are useful. They can be powerful. But only if they're part of an active, living policy, something the team actually uses to make decisions. Not a decorative sticker on your workflow.

Real WIP management isn't about numbers.

It's about awareness.

It's about knowing:

• What we've started.
• What's stuck.
• What's ageing.
• What we're realistically capable of finishing.

That kind of awareness doesn't come from a limit. It comes from conversations. From pull policies. From replenishment discipline. From team agreements to when we're truly "done" and when something's just been shoved to one side.

“We can only have 3 things in progress” is a rule.

“Let’s make sure we finish what we start before we start something new” is a mindset.

Dan puts it plainly: if you're not actively limiting WIP, you're not doing Kanban. But I'll take it a step further:

If your team has WIP limits and still doesn't talk about what's in flight, you're not managing anything, you're just role-playing flow.

Real WIP management is what happens in the white space between the cards, not just on the board.

6. Variability and WIP: Why Fluctuation Matters

“Flow isn’t static. But unmanaged variation is where systems break.”

Every system flexes. Workloads shift. Dependencies wobble. That's normal.

But when your WIP chart looks like a seismograph, up, down, up again, you're not scaling, you're staggering. That kind of volatility doesn't just erode predictability. It makes every forecast feel like fiction.

“Flowquake: The System Is Telling You Something…”

High variability in WIP often means:

• You're pulling new work before finishing old work.
• You're reacting, not managing.
• You're committing beyond your system's capability.

And when WIP surges and slumps, you can't trust your throughput, ageing data, or forecast windows. Because you've lost the rhythm.

Here's what healthy systems do:

They fluctuate within bounded limits. Think of it like breathing. Inhale, exhale. Not gasping one minute and holding your breath the next.

WIP is your early indicator that the system’s capacity is being stretched, or ignored.

So no, we're not aiming for robotic consistency. But if your WIP chart is all spikes and cliffs, you're not managing flow, you're surviving it.

And the worst part?

When variation goes unmanaged, WIP loses its meaning. It stops being a signal and becomes noise.

7. Final Thoughts: WIP Is a Mirror, Not a Manipulation

“If you want to improve flow, WIP is the place to start seeing, not solving.”

WIP isn't a dial you twist to hit some mythical 'optimal state.' It's not something you weaponise in a standup. It's not a KPI to optimise for slide decks.

It's a mirror. It shows you how much is in motion, how much is unfinished, and how much is at risk of quietly going stale.

You don't manage WIP to control your team.

You manage WIP to understand your system.

And if that understanding feels uncomfortable? Good. It should. Until you face your WIP honestly, you'll be stuck trying to improve flow through wishful thinking and Jira gymnastics (and you DON'T want to be there).

Start simple:

• Track WIP over time.
• Look for trends, not snapshots.
• Ask what your system is capable of finishing, not just starting.
• Watch how much WIP varies, and when.

Use WIP to guide better conversations. Build situational awareness. Let it tell you when you're stretched, when you're stagnant, and when you've taken on too much hope disguised as progress.

You don’t control WIP to control your team.

You respect WIP to understand your system.

That's the difference between managing work and just rearranging it.

‍