Kanban Explained: Why WIP Limits Matter More Than the Board

Kanban is not a task board. This matters because most teams think they’re doing Kanban when they’re doing something much simpler: running a visual task board. Task boards are useful. Kanban is a system for managing flow, and most “Kanban boards” I’ve seen don’t actually enforce the one property that makes Kanban work: work-in-progress limits.

Without WIP limits, you have a board. With WIP limits, you have Kanban.

Why Do WIP Limits Matter So Much?

A task board shows you what people are working on. Kanban shows you where work is flowing well and where it’s stuck. These are different questions with different implications.

Here’s what happens without WIP limits on a typical software team: every developer has four or five items “in progress” simultaneously. They’re context-switching constantly. Items sit in “In Progress” for two weeks because there’s always something more urgent to pick up. Nobody finishes anything completely before starting something new. The board is full of in-progress cards that are effectively stalled.

Here’s what WIP limits force: when the “In Progress” column hits its limit of three items, you cannot start new work. You must finish something first. This constraint feels uncomfortable, especially for developers who want to start the interesting new thing, and it is productive discomfort. It exposes blockers that were previously hidden by the illusion of activity.

Where Does Kanban Come From?

Taiichi Ohno’s insight at Toyota, developed from the late 1940s onward and described in his book “Toyota Production System” (1988), was elegant: instead of pushing production based on what the factory could make, pull production based on what customers actually ordered. The supermarket model (restock only what’s consumed) eliminated excess inventory and exposed production problems that overstock had hidden. The history of Agile traces how these ideas reached software.

David J. Anderson adapted this for software teams in the mid-2000s and set out the method in “Kanban” (2010). The parallel is direct: instead of pushing work onto developers based on what’s in the backlog, pull work based on capacity. WIP limits are the mechanism. When you can’t start new work until something finishes, you naturally expose where the real bottlenecks are. (The same idea sits at the heart of Lean software development.)

What Are the Core Practices of Kanban?

Anderson’s Kanban Method names six core practices. The Kanban Guide by Daniel Vacanti and Jim Coleman defines Kanban more leanly, around three, but both put WIP control at the center.

Visualize the workflow: this is the easy part. Map your actual process stages into columns, warts and all, rather than your ideal process. If there’s a “waiting for review” stage that work sits in for days, that’s a column.

Limit work in progress: set a maximum per column. The right number is determined empirically. Start with a limit that feels slightly too tight (you’ll know when things get blocked frequently). Adjust based on what you observe. One rule of thumb some teams start from: WIP limit = (team size × 1.5) for the main development column.

Manage flow: track how long items take from start to finish (cycle time). Track how long they take to arrive at done from creation (lead time). These numbers tell you more about system health than velocity ever will.

Make policies explicit: what does it mean for a card to move from “In Progress” to “In Review”? What makes a card “Done”? Teams that can’t answer these questions clearly are moving cards around based on vibes. Write the policies down and put them on the board.

Implement feedback loops: Kanban doesn’t prescribe specific meetings, but you need regular touchpoints to review what the flow data is telling you. A daily standup structured around the board (discuss blocked items, don’t just report status) and a weekly metrics review are the minimum.

Improve collaboratively: the data the system produces should drive process changes. If review is consistently the bottleneck, change the review process. If cycle times are high, examine why.

Kanban vs. Scrum: Which Fits Your Work?

Scrum suits teams with clear sprint goals and work that can be decomposed into approximately equal-sized chunks. The cadence of Sprint Planning, Sprint Review and Sprint Retrospective, as the Scrum Guide defines them, provides structure that works well for teams building discrete product increments.

Kanban suits teams whose work arrives continuously in varying sizes and types, where fixed sprint goals don’t fit the workflow. Support teams, operations teams, and teams with high interrupt-driven work often find Kanban more natural than Scrum.

Neither is universally better. The worst outcome is a careless “Scrum-ban”: running Scrum events and a Kanban board but having neither the discipline of Scrum’s sprint goals nor the flow optimization of Kanban. This is depressingly common.

Choose based on your actual workflow, and ignore what sounds more modern.

Why Do Kanban Implementations Fail?

Teams set WIP limits too high. If your limit is 10 and you have 8 developers, the limit isn’t actually limiting anything. WIP limits work by constraining behavior. If they’re never hit, they’re not doing anything.

Teams use the board to report instead of to manage. If the board is only updated during standups to give the appearance of progress, you’re wasting your time. The board should reflect reality in real time so that blockers are visible when they happen, not 24 hours later.

Teams don’t analyze flow metrics. Most Kanban implementations I’ve seen use the board but ignore cycle time, throughput, and lead time data. This data is what tells you whether your process changes are actually working. Without it, you’re making changes based on feelings.

Teams add columns without removing work. Every column transition is overhead. Kanban boards sometimes accumulate stages until every card goes through nine states and takes a week to get from one end to the other. If a stage is adding time but not value, collapse it.

How to Start Kanban Without Getting It Wrong

The most useful first step comes before the board: map your actual workflow, every stage a piece of work goes through from “someone has an idea” to “it’s in production.” Do this with your team, not by yourself. The conversation about what the stages actually are is more valuable than the board itself.

Then add one WIP limit, just on your main development column. Watch what happens. Where do things pile up? What gets blocked? That data tells you where to look next.

A pretty board is beside the point. The goal is a system that makes problems visible fast enough to fix them before they become disasters. If your board is showing you problems you didn’t know you had, it’s working. If everything always looks green, you’re not using it correctly.