WIP Limits: The One Kanban Rule That Makes You Ship Faster

Open your board right now and count how many cards sit in your "In Progress" column. If the number is bigger than the number of humans on your team, you have already found the reason you feel busy but never seem to ship. That gap — between motion and progress — is the most common, most expensive, and most fixable mistake in solo and small-team software work.

The fix is almost insultingly simple. You put a number on a column and refuse to break it. That's a work-in-progress limit, and it is the single rule that does more for your delivery speed than any tool, framework, or productivity system you will ever adopt.

---

What a WIP limit actually is

A work-in-progress limit is a hard cap on how many tasks are allowed to be "in flight" at the same time. On a Kanban board, it's usually a small number written next to a column — "In Progress (2)" — that you treat as a real constraint, not a suggestion. Once the column is full, you are not allowed to start anything new. To start something, you first have to finish something.

That's it. There is no ceremony, no certification, no two-day workshop. The entire discipline of Kanban compresses into one stubborn habit: stop starting, start finishing.

It sounds like a constraint that slows you down. It does the opposite. The constraint is the whole point — it forces the half-finished work that's quietly rotting on your board to get pushed across the finish line before anything new is allowed to compete for your attention.

---

The real enemy: a board full of half-done cards

Here's the trap. Starting a new task feels like progress. You drag a card to "In Progress," you feel the little dopamine hit of momentum, and you tell yourself you're making things happen. But a started task delivers exactly zero value. A task delivers value the moment it ships — not a second before.

So a board with fourteen cards in progress and zero cards shipped this week is, in the only metric that matters, a board that has produced nothing. You've spread your finite attention across fourteen open loops, each one accruing the mental overhead of "I still need to get back to that."

Psychologists call those nagging open loops the Zeigarnik effect — unfinished tasks occupy working memory and keep tugging at you. Fourteen open cards isn't fourteen tasks waiting patiently. It's fourteen background processes eating your RAM.

The half-done card is worse than the not-yet-started card, because the half-done one has already cost you. You paid the setup cost — loading the problem into your head, opening the files, remembering the edge cases — and then you abandoned it for something shinier. When you return, you pay that setup cost again. Multiply that across a board full of stalled work and you have a tax you're paying every single day without noticing.

---

Little's Law, in plain English

The reason WIP limits work isn't motivational. It's arithmetic. There's a piece of queueing theory called Little's Law, and once it clicks, you can't un-see it.

In its plainest form, for a stable workflow:

Cycle time = Work in progress ÷ Throughput

Cycle time is how long a single task takes from "started" to "done." Throughput is how many tasks you finish per unit of time — say, per week. The law says those two things are linked by how much work is in progress.

Hold throughput roughly constant — you can only actually finish so much in a week, because there's only so much of you. Now look at what happens to cycle time as WIP goes up:

If you finish about three tasks a week and you keep three things in progress, each one clears in roughly a week. Pile fourteen things into "in progress" against that same throughput, and each task now drags out to nearly five weeks before it's done. Same effort. Same person. Wildly different delivery times — purely because of how much you let yourself start.

This is the unintuitive heart of it: the more you start, the longer everything takes to finish. Not "the more you finish." The more you start. WIP limits attack the one variable in that equation you can directly control.

---

The context-switching tax

Little's Law assumes throughput stays flat as WIP climbs. In real life it gets worse than that, because juggling more work actively lowers throughput. The culprit is context-switching.

Gloria Mark's research at UC Irvine found it takes about 23 minutes to fully return to a task after an interruption. That's the recovery cost of one switch. Now imagine your fourteen-card board: every time you bounce between cards, you eat some version of that tax. The deep state you need to write a tricky migration or untangle a race condition simply never forms, because you keep blowing it away before it sets.

For developers this is brutal, because the work that matters most is the work that requires the longest uninterrupted ramp. Shallow tasks survive interruption. The hard, valuable, "this is why they pay me" tasks do not. A high-WIP board systematically starves exactly the work that creates the most value.

A WIP limit is, functionally, a context-switching governor. By capping how many things can be open, you cap how often you're forced to switch. You give the deep state a chance to form and hold. This is the same logic behind tracking cycle time instead of velocity — you optimize for how fast real work clears, not for how busy everyone looks.

---

Unlimited vs limited: the honest trade-off

WIP limits are not free. They feel restrictive, and the restriction is doing real work on your psychology. Here's the straight comparison.

Notice the pattern. The unlimited board's pros are all about feeling. The limited board's pros are all about results. That's the trade in one image: you give up the comfortable feeling of unlimited starting, and you get the uncomfortable reality of actually finishing.

---

How to set your number (and enforce it without ceremony)

The most common question is "what number do I use?" The honest answer: start low and tune. But here are defaults that work.

The per-person rule

Cap "In Progress" at one to two cards per person. That's the whole formula.

• Solo dev: limit of 2. One thing you're actively building, plus one slot for the thing that's genuinely blocked-waiting (a review, a deploy, a client reply) so you're not fully idle while you wait.
• Three-person team: limit of 3 to 4. Not "4 per person" — 4 total. The limit belongs to the column, not the individual.

Why so low? Because the limit's job is to make you uncomfortable enough to finish. If the number is high enough that you never bump against it, it isn't a limit, it's decoration.

Enforce it with the pull rule, not policing

You don't need an admin or a process cop. You need one rule everyone agrees to: to start something new, finish something first. The column is full until a card moves to Done. This is the "pull" model — work gets pulled into progress only when there's capacity, instead of getting pushed in whenever someone feels restless.

When you hit the limit and can't start anything, that's not a failure. That's the system working. The discomfort is a signal pointing at a blocked card. Go un-block it. Swarm it. Pair on it. That stuck card is now the single most important thing on the board, and the limit is what made it obvious.

You do not need heavy tooling for any of this. A column header with a number and the willingness to honor it is enough. In GritShip the limit lives right on the column and the board stays under your fingers — N to file a new task into the backlog instead of cramming it into progress, drag-and-drop to pull the next card when a slot opens. But the discipline is the product here, not the software. You could do this on a whiteboard.

---

A worked example: 14 cards down to 3

Let me make this concrete with a team I'll call the three-person crew — two engineers and a founder who also ships code.

Before. Their board had 14 cards in "In Progress." A half-finished billing refactor. Two features at "80% done." A flaky test someone meant to fix. A dependency upgrade. A landing-page tweak. A customer bug that kept getting bumped. Every standup was a tour of stalled work, and the recurring phrase was "yeah, still working on that." They were busy every day and shipped maybe one thing a week.

The change. They set the "In Progress" limit to 3 and ran the count-down: everything currently in progress had to either get finished or get pulled back to the backlog. Painful afternoon. By the end, 3 cards stayed in progress; 11 went back to "To Do."

After. With only three slots, finishing became the only way to make room. The billing refactor — stuck for two weeks because nobody could start it without abandoning something else — got swarmed by all three people and shipped in two days. Cycle time dropped from "vaguely several weeks" to a measurable handful of days. They didn't work more hours. They stopped scattering the same hours across fourteen things.

The eye-opener wasn't the speed. It was discovering how much of their "in progress" work had been quietly dead for weeks. The limit didn't slow them down. It exposed how little of their motion had been progress.

---

Where WIP limits fit your workflow

WIP limits aren't a standalone trick — they're the backbone of flow-based work. If you've already ditched the artificial cadence of two-week iterations, you'll find that capping WIP is what makes continuous flow without sprints actually function. Without a limit, "continuous flow" just becomes "continuously starting things."

They also pair naturally with how solo devs and tiny teams should think about boards in general. If you're still deciding whether a Kanban board even beats a plain list, the WIP limit is the deciding feature — it's the one thing a Kanban board does that a to-do list can't. A to-do list lets you add infinitely. A limited board forces a reckoning. For the bigger picture on running lean without process overhead, the solo dev PM guide without bloat covers how this slots into a no-ceremony setup.

A few field notes from running this in practice:

• The limit applies to "In Progress," not your whole board. Your backlog can hold a thousand cards. That's fine — backlog items cost nothing. It's started work that costs.
• Resist per-task exceptions. "This one's special, I'll just start it too" is how the limit dies. The limit is only real if it's inconvenient sometimes.
• A jammed column is a gift. When work piles up at one stage — say, everything's "in review" and nothing's getting reviewed — the limit just diagnosed your bottleneck for free. Fix the stage, don't raise the limit.
• Lower beats higher when in doubt. A limit that's a touch too tight makes you finish things. A limit that's too loose does nothing at all.

---

Frequently asked questions

What is a good WIP limit for a solo developer?

Start with a limit of 2 on your 'In Progress' column: one thing you're actively building, plus one slot for work that's genuinely blocked-waiting (a review, a deploy, a reply). If you find yourself idle, raise it to 3. If your board feels chaotic, drop back to 1. The right number is the lowest one that keeps you moving.

Doesn't limiting work-in-progress just slow me down?

It feels that way, but the math says otherwise. By Little's Law, cycle time equals work-in-progress divided by throughput — so the more you start, the longer each task takes to finish. Limiting WIP lowers cycle time, meaning individual tasks ship faster even though you start fewer of them at once.

What's the difference between WIP and my backlog?

Your backlog is unstarted work waiting in line — it can be as large as you want because unstarted items cost nothing. Work-in-progress is started-but-not-done work, which carries real cost in attention and context-switching. WIP limits apply only to the 'In Progress' column, never to the backlog.

How do I enforce a WIP limit without special software?

Write the number next to the column and honor the pull rule: to start something new, you must first move something to Done. That's the whole enforcement mechanism. A whiteboard or any Kanban board with a column counter is enough — the discipline matters far more than the tooling.

What do I do when I hit the limit and can't start anything?

That's the system working, not failing. Being unable to start means everything in progress is either close to done or blocked. Don't start new work — go finish or unblock what's already there. The most stuck card is now your single highest priority. Swarm it.

How does context-switching relate to WIP limits?

Every time you jump between open tasks, you pay a refocus cost — research from Gloria Mark at UC Irvine puts full recovery at around 23 minutes. A high-WIP board forces constant switching, which starves the deep focus that hard work requires. Capping WIP caps how often you're forced to switch.

Count your "In Progress" column. If the number is bigger than your headcount, you don't have a productivity problem, a tooling problem, or a motivation problem. You have a WIP problem, and it's the cheapest one in software to fix. Pick a number, write it on the column, and refuse to break it. Stop starting. Start finishing. The board will get quieter, the work will get faster, and for the first time in a while you'll be shipping as fast as you've been feeling busy.