Kanban: Limit Work in Progress, Improve Flow
Kanban is a visual pull system for managing work. Tasks move across a board representing the real stages of a process, and each stage carries an explicit limit on how many items may occupy it at once — which forces bottlenecks into view and improves the speed at which work completes.
What Is It?
Kanban is Japanese for signboard. The system originated at Toyota in the early 1950s, where Taiichi Ohno was addressing a specific problem: how to produce only what the next stage actually needs, rather than what the previous stage is capable of producing. His reference point was the American supermarket, where shelves are restocked in response to what customers remove rather than to a production forecast. Physical cards signalled replenishment, and nothing was made until a card authorised it.
The knowledge-work adaptation came much later. David J. Anderson formalized it while working at Microsoft and Corbis, publishing Kanban: Successful Evolutionary Change for Your Technology Business in 2010. His central insight was that software and service teams suffer the same pathology as unbalanced factories — work piling up between stages — but cannot see it, because the inventory is invisible. A half-finished feature occupies no floor space.
This produces a distinctive property. Kanban does not prescribe roles, ceremonies or iteration lengths. It starts with the process you have, makes it visible, and improves it incrementally. That makes it unusually easy to adopt and unusually easy to adopt badly.
The Six Core Practices
- Visualise the workflow. Build a board reflecting how work actually moves, including the waiting states teams normally leave out — "awaiting review", "blocked on vendor". Those columns are where the time goes.
- Limit work in progress. Cap how many items may sit in each stage. This is the practice that does the work, and the one most often omitted.
- Manage flow. Measure how quickly work moves and where it stalls, then address the stalls. The object of attention is the work, not the workers.
- Make process policies explicit. Write down what "done" means for each column, who may pull work forward, and how blocked items are escalated. Unwritten rules are applied inconsistently and cannot be improved.
- Implement feedback loops. Regular reviews at the board, at the delivery level, and at the strategic level.
- Improve collaboratively, evolve experimentally. Change the system through small tested adjustments rather than reorganization.
Why WIP Limits Are the Point
A board without WIP limits is a status display. It may be useful, but it does not change behavior, and teams that stop at this step generally conclude Kanban did nothing for them.
The reasoning rests on Little's Law, which states that average cycle time equals average work in progress divided by average throughput. Since throughput is bounded by team capacity, the only variable a team directly controls is work in progress. Halve the number of items in flight and you roughly halve the time each takes to finish. Nothing was worked on faster; less was worked on at once.
The mechanism is uncomfortable by design. When a column hits its limit, nobody may start anything new — the correct response is to help finish what is already there. Idle time becomes visible, and teams instinctively fill it by starting more work, which is precisely the behavior causing the problem. A team that never hits its limits has set them too high.
Worked example
Why a WIP limit cuts cycle time, with the arithmetic
An illustrative composite. A six-person software team, board already in place, columns already visible, no limits on any of them. Delivery felt slow and nobody could say why, because everyone was demonstrably busy.
Little’s Law, in the form used for knowledge work, states that average cycle time = average WIP ÷ average throughput. Both inputs are countable from the board without any new tooling.
| Measure | Before | After a WIP limit of 8 | What happened |
|---|---|---|---|
| Items in progress (WIP) | 24 | 8 | The only thing the team deliberately changed. |
| Throughput | ~4 items/week | ~4.5 items/week | Barely moved. Nobody started working faster or longer. |
| Average cycle time | 24 ÷ 4 = 6 weeks | 8 ÷ 4.5 ≈ 1.8 weeks | Fell by roughly two-thirds, as arithmetic requires. |
| Items finished per quarter | ~52 | ~58 | Slightly up, and each one landed far sooner. |
| What it felt like at first | Everyone busy | People idle at the board | The hardest part. Idle capacity looks like waste and is the mechanism working. |
The point most explanations skip
Nobody worked faster. Throughput moved by about ten per cent, which is within noise. Cycle time collapsed because there was less work in the system, and cycle time is WIP divided by throughput. Reduce the numerator and the answer falls whether or not anyone changes their behavior.
This is why “work harder” and “hire more people” so often fail to make delivery feel faster. Both raise throughput a little. Neither reduces the queue, and the queue is what the customer is waiting behind.
Flow Metrics That Matter
- Cycle time — elapsed time from starting an item to finishing it. The primary measure, and far more useful as a distribution than an average.
- Lead time — from request to delivery, including the queue before work started. This is what the customer experiences.
- Throughput — items completed per period. Used for forecasting.
- Work in progress — items currently in flight. The lever.
- Flow efficiency — active work time as a percentage of total elapsed time. Commonly under 15% on first measurement, which is usually the number that convinces sceptics.
Cumulative flow diagrams plot these together; widening bands indicate a stage accumulating work faster than it can clear it.
Before you start
Is Kanban actually your framework?
Kanban suits work that arrives continuously, varies in size, and cannot easily be batched into fixed iterations — support, operations, maintenance, editorial, small product teams with unpredictable intake. It is a way of managing flow, not a project method and not a planning system.
It is also unusually easy to adopt in name only, because the visible artefact is a board and boards are free. What makes it Kanban is the limit, not the columns.
| If your real problem is… | You probably want |
|---|---|
| Work arrives in planned batches with a fixed cadence | Scrum or Sprint Planning Compare Kanban and Scrum |
| One specific step is clearly the bottleneck | Theory of Constraints — Kanban reveals bottlenecks, TOC is built to exploit them Not sure which? Compare |
| The process itself is wasteful end to end | Value Stream Mapping — map the whole flow before limiting it Compare all three |
| The work has a fixed scope, sequence and end date | Critical Path Method or Gantt Chart Not sure which? Compare |
| We need continuous small improvements to a stable process | Kaizen or 5S Not sure which? Compare |
| Work arrives unpredictably and everything takes too long | Kanban — you are in the right place |
The distinction that matters
A board without a WIP limit is a to-do list with columns. It may be a useful to-do list, but it will not change how long anything takes, because nothing about it constrains how much work is in the system. If you take one thing from this page, take the number written at the top of the column — not the column.
When to Use
- Teams with continuous, unpredictable intake — support, operations, maintenance, internal platform work
- Work that cannot sensibly be batched into fixed iterations
- Teams that are visibly busy but delivering slowly
- Where frequent context-switching is the suspected problem
- Organizations where imposing new roles and ceremonies would meet resistance
- Alongside Scrum, as the flow-management layer within sprints
When NOT to Use
- When you need date commitments. Kanban forecasts probabilistically from throughput history; it has no deadline mechanism of its own. Fixed-scope, fixed-date work needs Gantt-based planning alongside it.
- For genuinely sequential projects. Construction and regulated processes with mandatory phase gates do not benefit from a pull system.
- To fix prioritization. Kanban controls how much work is in flight, not whether it is the right work. Pair it with a prioritization method.
- As a substitute for capacity. WIP limits make an overloaded team's overload visible. They do not create capacity, and management sometimes finds the resulting visibility unwelcome.
In practice
How WIP limits get faked
Almost every disappointing Kanban implementation has a limit that does not bind. These are the ways that happens, usually without anyone intending it.
| What you see | What it usually means | What to do |
|---|---|---|
| Columns have names but no numbers | There is no limit, so there is no Kanban system | Put a number at the top of each in-progress column. Start at roughly half your current WIP; you can raise it, and you almost certainly will not need to. |
| The limit was set at current WIP | It was chosen so it would never be hit | A limit that never binds does nothing. It has to be uncomfortable at least weekly or it is decoration. |
| Limits are per person — “two items each” | The limit is on people rather than on the workflow | Limit the column, not the individual. Person-level limits guarantee everyone stays busy, which is the behavior you are trying to stop. |
| Blocked items sit outside the count | The largest queue has been made invisible | Blocked work still occupies the system. Count it, or the limit is a fiction and blockers stop being urgent. |
| The limit is raised whenever it is reached | The signal is being silenced instead of read | Hitting the limit is the system working. It means finish something before starting something. Raise a limit only after a retrospective, never in the moment. |
| Only cycle time is tracked | You are watching a lagging indicator | Cycle time is only known once an item finishes. Track work item age too — it is the same clock, running on things that are still stuck, and it lets you intervene while it still matters. |
Sourced
What the evidence says
The WIP-to-cycle-time relationship is a theorem, not a heuristic.
John Little proved in 1961 that for a queuing system in steady state, the average number of items in the system equals the arrival rate multiplied by the average time each spends there — L = λW. Rearranged for knowledge work: average cycle time = average WIP ÷ average throughput. This is the source people are usually looking for when they ask whether limiting WIP really reduces cycle time. It is arithmetic, and it holds regardless of how hard anyone works.
Little, J. D. C., “A Proof for the Queuing Formula: L = λW”, Operations Research 9(3), 1961, pp. 383–387. Paper
But the law has conditions, and boards routinely break them.
Little’s proof assumes a system in steady state, with the relevant averages finite and stable over the measurement window. A board where items are abandoned rather than finished, where the definition of “started” drifts, or where a reorganization lands mid-quarter does not satisfy that. The relationship still points the right way — less WIP, shorter cycle time — but treat the specific numbers as an estimate rather than a forecast, and measure over a period long enough to contain your normal variation.
WIP and the WIP limit are different things, and the distinction matters.
WIP is a measurement: how many items are started but not finished. A WIP limit is a policy: a constraint the team adopts in order to bring that measurement down. Conflating them is why teams report “our WIP limit is 12” while running 20 items — they have written a number down without adopting a constraint. The Kanban Guide defines four flow measures: WIP, cycle time, work item age, and throughput.
The Kanban Guide, Daniel Vacanti and John Coleman; Kanban Guide for Scrum Teams, Scrum.org.
Work item age is the metric most teams are missing.
Cycle time is a lagging indicator: you learn an item took nine weeks only once it has taken nine weeks. Work item age is the same clock running on items still in progress, which makes it a leading indicator — the only one of the four you can act on while the outcome is still changeable. An aging chart plots each unfinished item against your historical cycle time distribution, so anything drifting beyond the usual range becomes visible before it becomes a surprise.
Its origins are industrial, and the translation was deliberate.
Kanban began as a physical signalling system in Toyota’s production system under Taiichi Ohno, where a card authorised replenishment and nothing was made without one. David J. Anderson adapted the ideas for knowledge work in 2010, keeping the signal-and-limit mechanism and dropping the manufacturing specifics. Both versions rest on the same premise: capacity is signalled by completion, not requested by intention.
Anderson, D. J., Kanban: Successful Evolutionary Change for Your Technology Business, Blue Hole Press, 2010.
Key Strengths
- Adopt without reorganising. Start with existing roles, titles and process. Adoption cost is close to zero and resistance is correspondingly low.
- Bottlenecks become undeniable. A column at its limit with items queued behind it is visible to everyone, including people outside the team.
- Fast feedback. Teams typically see cycle-time improvement within weeks.
- Honest forecasting. Throughput history supports probabilistic forecasts grounded in evidence rather than estimation.
- Domain-agnostic. Works for engineering, legal, HR, marketing and manufacturing alike.
Key Weaknesses
- Easy to implement superficially. Most failed adoptions are a board with no WIP limits — visualisation without the constraint that produces change.
- No timeboxes or deadlines. Without iteration boundaries, some teams lose urgency and long-running items drift.
- Weak on planning. Kanban says nothing about roadmaps, dependencies or sequencing across teams.
- WIP limits are hard to hold. Enforcement requires discipline and management support; the first genuine stoppage is where most adoptions fail.
- Optimises the visible. Work that never reaches the board — interruptions, unlogged requests — stays invisible and distorts the metrics.
Quick Reference
How It Works
| 1 Primary Input | Existing workflow stages, current in-flight work, historical completion records |
|---|---|
| 2 Data You Need | Real process stages including waiting states, item start and finish timestamps, blocker records |
| 3 Primary Output | A visual pull system with explicit WIP limits, flow metrics for cycle time and throughput, and a ranked view of where work accumulates |
Comparison with Related Frameworks
Kanban vs Scrum
Scrum prescribes roles, fixed-length sprints, a committed backlog and defined ceremonies; Kanban prescribes none of these and works continuously. Scrum suits work that can be planned into batches with stable priorities for two weeks. Kanban suits continuous, interrupt-driven intake. Many teams run both — Scrum for cadence, Kanban's WIP limits for flow inside the sprint.
Kanban vs Theory of Constraints
Both target bottlenecks. Theory of Constraints identifies the single system constraint and subordinates everything to it, working top-down from analysis. Kanban surfaces constraints bottom-up through WIP limits and expects them to move over time. TOC is stronger analytically; Kanban is far easier to start.
Kanban vs Value Stream Mapping
Value Stream Mapping is a point-in-time analysis producing a current and future state map. Kanban is a continuous operating system. VSM is the better diagnostic for a process you do not yet understand; Kanban is what you run afterwards to hold the improvement.
Sequencing
What to run before and after Kanban
Unlike most frameworks on this site, Kanban is not run once and concluded. It is adopted and lived in. What follows is the order that tends to work around it.
Before
Agree what “started” and “finished” mean
Every flow metric is defined against those two points. Without them, WIP is uncountable and cycle time is unmeasurable, and the board will produce numbers nobody trusts.
During
Limit, measure, and hold the limit
The board plus the four flow measures. The work is mostly resisting the urge to raise the limit when it binds — which is the moment it is doing its job.
After
Fix what the queue exposed
A binding limit turns invisible problems into visible stoppages: a slow approval, a single reviewer, an unreliable environment. Kanban surfaces these and does not fix them.
Common questions
Kanban and WIP limits: quick answers
What is Kanban in simple terms?
It is a way of managing work where every task is visible on a board that mirrors your real process, and each stage has a hard limit on how many tasks it can hold at once. When a stage is full, nobody starts anything new until something moves — which forces the team to finish work rather than accumulate it.
What is a WIP limit and why does it matter?
A work-in-progress limit caps how many items may sit in a stage simultaneously. It matters because of Little's Law: cycle time equals work in progress divided by throughput. Since throughput is bounded by capacity, reducing the number of items in flight is the most direct way to make each one finish sooner. A board without WIP limits is a status display, not a Kanban system.
What is the difference between Kanban and Scrum?
Scrum uses fixed-length sprints, defined roles and a committed backlog; Kanban is continuous and prescribes no roles or timeboxes. Scrum works well when priorities are stable enough to commit for a sprint. Kanban works well when intake is unpredictable. They are frequently combined.
Who invented Kanban?
Taiichi Ohno developed it at Toyota in the early 1950s as part of the Toyota Production System, inspired by supermarket restocking. David J. Anderson adapted it for software and knowledge work, publishing the definitive treatment in 2010.
How do I choose the right WIP limit?
A common starting point is roughly one to one-and-a-half items per person in a stage, then adjust based on what happens. If the limit is never reached it is too high to change any behavior; if work is constantly blocked and idle time is large, it may be too low. The limit is meant to be tuned, not set once.
Can Kanban be used outside software teams?
Yes. It originated in manufacturing and is used in legal, HR, marketing, finance and healthcare operations. Any process with identifiable stages and a tendency to accumulate half-finished work is a candidate.
Does Kanban work for meeting deadlines?
Not directly. Kanban forecasts probabilistically from throughput history — for example, that eighty-five percent of items complete within twelve days — which is often more reliable than estimation. But it has no built-in deadline mechanism, so fixed-date commitments need a complementary planning approach.
How do I set a WIP limit for the first time?
Count what you currently have in progress and halve it. The number will feel too low, which is the point — a limit that does not bind changes nothing. Run it for two weeks, watch where work stops moving, and adjust in a retrospective rather than in the moment.
Do WIP limits really reduce cycle time, and what is the source?
Yes, and it follows from Little’s Law rather than from any claim about productivity. John Little proved in 1961 that for a system in steady state, average cycle time equals average WIP divided by average throughput. Reduce the amount of work in the system and cycle time falls arithmetically, even if nobody works any faster.
What is a WIP aging chart, and why use one?
It plots every unfinished item by how long it has been in progress, usually against your historical cycle time percentiles. Cycle time only tells you about work already delivered; work item age tells you about work still in flight, which makes it the one flow metric you can act on while the outcome can still change.
What is the difference between WIP and a WIP limit?
WIP is a measurement — the number of items started but not finished. A WIP limit is a policy the team adopts to bring that number down. Teams that write a limit on the board without treating it as a constraint have the number but not the system.
Frameworks related to Kanban
- Scrum FrameworkAgile framework for iterative product development using sprints, with defined roles (Scrum…
- Value Stream MappingVisualize the flow of materials and information through a process to identify waste and…
- Theory of ConstraintsIdentify and manage the bottleneck limiting your system performance using the Five Focusing…