Walk into almost any software company's engineering floor and you will likely find a wall — physical or digital — covered in columns and cards. Chances are high that what you are looking at is a Kanban board: a simple, visual representation of work in progress that has become one of the most widely adopted workflow management tools in the world.
Kanban is not a project management framework invented by a consulting firm in the 2000s. It is a method with industrial manufacturing roots dating to postwar Japan, adapted and refined over decades for knowledge work. Understanding where it came from, how it works mechanically, and why its core principle — limiting work in progress — is counterintuitively effective can fundamentally change how you manage both team and personal workflow.
Origins: Toyota's Production System
The word kanban (看板) is Japanese and translates roughly to "signboard" or "visual card." The method was developed by industrial engineer Taiichi Ohno at Toyota in the late 1940s as part of the broader Toyota Production System (TPS), which would later become the foundation of Lean manufacturing.
Ohno was studying American supermarkets, which restocked shelves based on actual customer demand rather than production forecasts. When a shelf space emptied, that visual signal triggered a replenishment order. The system was self-regulating: restocking was pulled by real consumption rather than pushed by predictions.
Toyota applied this logic to manufacturing. When a production stage needed more parts from the upstream stage, a physical kanban card was passed back to trigger supply. Nothing was produced until the downstream signal arrived. This pull system was the opposite of the prevailing push approach, in which production ran at maximum throughput and sent inventory downstream regardless of whether it was needed.
The result was dramatically lower inventory, fewer quality defects (because problems surfaced quickly rather than being buried in large batches), and faster overall throughput.
David Anderson adapted these principles for software development around 2007, publishing the foundational text Kanban: Successful Evolutionary Change for Your Technology Business in 2010. The modern knowledge-work Kanban method is his adaptation, though it draws heavily on Ohno's original principles and W. Edwards Deming's systems thinking.
The Kanban Board: Core Structure
A Kanban board is divided into columns that represent stages in a workflow. Work items — typically represented as cards with a brief description, owner, and any relevant details — move from left to right through the columns as work progresses.
A minimal board for a software team might have five columns:
| Column | Meaning |
|---|---|
| Backlog | Work identified but not yet started |
| Ready | Prioritized and ready to be picked up |
| In Progress | Actively being worked on |
| Review | Awaiting code review, testing, or approval |
| Done | Complete |
More mature boards add columns that reflect the team's actual workflow in finer detail — for example, splitting "In Progress" into "Development" and "Testing," or adding a "Blocked" swimlane for items waiting on external dependencies.
The columns themselves are not the differentiating feature of Kanban. Many teams use column-based boards without practicing Kanban. What makes a board a Kanban board is the WIP limit.
Work-in-Progress Limits: The Core Mechanism
A WIP limit is an explicit cap on the number of cards that can be in a column at any time. If the "In Progress" column has a WIP limit of 3 and there are already 3 cards there, no new card can enter the column until one is completed and moved forward.
This feels counterproductive. Shouldn't people always be busy? The answer, supported by both queuing theory and practical experience, is no.
Why WIP Limits Improve Flow
Little's Law, a mathematical theorem from operations research, states:
Average cycle time = Average WIP ÷ Average throughput
If your team completes 5 items per week (throughput) and has 20 items in progress simultaneously, the average cycle time is 4 weeks per item. Halve the WIP to 10 items and — assuming the same throughput — average cycle time drops to 2 weeks.
More practically, every time a person switches from one task to another, they incur a context-switching cost: time spent re-loading the mental model of the new task, re-reading prior notes, and rebuilding momentum. Studies by Gerald Weinberg estimated that each additional simultaneous project reduces effective time for any single project by roughly 20%. Five simultaneous projects leave only 5% of your time effectively available for any one of them.
WIP limits force completion before new starts. The discomfort of not starting new things — sitting at a limit and having to help clear a blocked item rather than picking up fresh work — is the mechanism by which Kanban surfaces problems and accelerates actual delivery.
Setting WIP Limits
A common starting point is to set WIP limits at twice the number of people working that stage. For a three-person development team, a WIP limit of 6 for the "In Progress" column allows some parallelism while preventing unlimited accumulation. These numbers should then be adjusted based on actual flow data — if items frequently stack at a stage, the limit and the underlying reason for the stacking both need examination.
Pull vs Push Systems
Kanban implements a pull system: work is pulled into a stage only when capacity opens up. This contrasts with a push system, where work is assigned or scheduled regardless of current capacity.
In a push system, a project manager assigns five tasks to a developer who already has three open items. All five are now "in progress" by the plan, though realistically they will each take five times longer due to context switching. Deadlines slip, estimates prove wrong, and the cause — overloading — is obscured by the busyness of apparent activity.
In a pull system, the developer picks up a new task only when a previous task is complete. The manager's role shifts from assignment to prioritization of the backlog — ensuring the right things are at the top of the ready column so that when capacity opens, it flows to the highest-priority work.
This shift in how work enters the system — from manager-pushed to worker-pulled — is one of the most significant cultural changes teams encounter when adopting Kanban.
Kanban vs Scrum: Choosing the Right Method
Kanban and Scrum are both agile methods, but they take fundamentally different approaches. Understanding the differences helps teams choose appropriately rather than adopting one by default.
| Dimension | Kanban | Scrum |
|---|---|---|
| Cadence | Continuous flow, no fixed iterations | Fixed sprints (typically 2 weeks) |
| Roles | No prescribed roles | Product Owner, Scrum Master, Developers |
| Ceremonies | No mandatory meetings | Sprint planning, daily standup, review, retrospective |
| Change during work | Allowed anytime | Discouraged during active sprint |
| Primary metric | Cycle time and flow efficiency | Sprint velocity (story points per sprint) |
| Best suited for | Continuous, unpredictable incoming work | Product development in planned increments |
Neither is universally superior. Scrum's regular cadences and ceremonies provide structure that benefits teams building complex products iteratively. Kanban's lack of prescribed structure suits teams handling continuous operations, support tickets, or maintenance work where the volume and nature of incoming items cannot be predicted two weeks in advance.
Many teams use Scrumban — a hybrid that takes Scrum's planning and retrospective practices and combines them with Kanban's WIP limits and flow metrics, without the strict sprint commitment model.
Kanban Metrics: Measuring Flow
Kanban provides a rich set of metrics for understanding and improving process performance.
Cycle Time
Cycle time is the elapsed time from when work on an item actively begins to when it is completed. It is measured for individual items and analyzed as a distribution, not just an average.
A cycle time distribution that is wide and skewed right (most items finish quickly but some take extremely long) indicates process instability — blocking events, unclear requirements, or dependency problems that affect some items unpredictably. Narrowing the distribution is often more valuable than reducing the average, because predictability allows better planning.
Lead Time
Lead time is the elapsed time from when an item is requested or added to the backlog to when it is delivered. It includes waiting time in the backlog as well as active cycle time.
From a customer perspective, lead time is what matters. A team that processes items quickly but accumulates a huge backlog still delivers slowly. Kanban teams monitor both metrics to understand whether flow problems are in the active work stages or in backlog prioritization.
Throughput
Throughput is the number of items completed per unit of time (typically per week). It is a measure of sustainable team output.
Throughput is more useful for forecasting than estimates. If a team consistently completes 12-15 items per week and has 60 items in the backlog, a Monte Carlo simulation using historical throughput distributions can forecast completion with statistical confidence — far more reliably than summing point estimates for each item.
Flow Efficiency
Flow efficiency is the ratio of active work time to total elapsed time for an item. In most organizations, this number is startlingly low — industry studies suggest an average of 5-15% for knowledge work, meaning items spend 85-95% of their lead time waiting rather than being actively worked on.
Improving flow efficiency means identifying and reducing wait states: approvals, reviews, dependency resolution, and handoffs.
The Cumulative Flow Diagram
The Cumulative Flow Diagram (CFD) is Kanban's signature visualization tool. It plots the number of items in each workflow stage over time, with each stage stacked in a band.
A healthy CFD shows bands of roughly consistent width progressing upward at a steady pace. Widening bands indicate growing WIP (items accumulating in a stage). Flat lines indicate stages that are not completing work. Sudden drops indicate batched completions, which often reflect invisible queuing upstream.
The CFD gives teams a continuous picture of system health without requiring per-item status meetings.
Kanban Board Design Principles
Effective Kanban boards are not just aesthetic tools — they are carefully designed representations of reality.
Represent your actual workflow. Boards that show only three generic columns when the actual process has seven stages hide the bottlenecks Kanban is designed to expose. Map what actually happens, including reviews, approvals, and waiting states.
Make blockers visible. Items blocked by external dependencies, decisions, or resource constraints should be visually distinct — many teams use a red sticker or a separate "Blocked" label. Invisible blockers are the most common reason WIP accumulates.
Include classes of service. Not all work is equal. A production outage and a low-priority enhancement both move through the same board but require different response speeds. Classes of service define different policies (including different WIP limits and service level expectations) for different types of work — for example, expedite, fixed-date, standard, and intangible.
Limit the backlog too. An unlimited backlog is a form of hidden WIP. Teams that admit 300 items into the backlog inevitably spend time managing, re-prioritizing, and re-estimating work that will never actually be done. A ready queue limited to a manageable number (often one to two weeks' worth of work) forces harder priority decisions and reduces waste.
When to Use Kanban
Kanban is particularly well-suited to:
- Continuous service and support work where items arrive unpredictably and must be processed ongoing
- Maintenance and operations teams handling a mix of planned and reactive work
- Teams transitioning from chaos to structure — Kanban's evolutionary, non-prescriptive approach makes it easier to adopt incrementally than Scrum
- Individuals managing personal workloads — personal Kanban (popularized by Jim Benson and Tonianne DeMaria Barry) applies the same principles to individual task management
It is less suited to teams with strong dependencies on external stakeholders who require predictable committed delivery dates, where Scrum's sprint cadence may provide more useful coordination.
Summary
Kanban is a visual workflow management method built on two core ideas: make work visible, and limit how much work is in progress at any given time. Its roots are in Toyota's manufacturing revolution; its modern form is a powerful approach to managing knowledge work.
The principle of WIP limits — limiting starts to improve finishes — is counterintuitive but mathematically sound. Combining it with visible boards, pull-based flow, and metrics like cycle time and throughput gives teams a feedback-rich system for continuous improvement without the ceremony overhead of heavier frameworks.
Whether you adopt full Kanban, use its principles to improve a Scrum process, or simply apply WIP limits to your personal task list, the fundamental insight applies universally: finishing existing work before starting new work is almost always faster than running everything simultaneously.
Frequently Asked Questions
What is Kanban in project management?
Kanban is a visual workflow management method that uses a board of columns representing process stages, with cards representing individual work items. Its defining feature is work-in-progress (WIP) limits — caps on how many items can be in each stage simultaneously. Rather than pushing work into the system, Kanban pulls new items forward only when capacity opens up downstream.
What are WIP limits in Kanban and why do they matter?
WIP (work-in-progress) limits are explicit caps on how many items can be in any column at one time. They matter because multitasking and context switching are costly — research by Gerald Weinberg found that each additional simultaneous project reduces available time by roughly 20%. WIP limits force the team to finish existing work before starting new work, which surfaces bottlenecks and improves flow rather than hiding congestion behind a growing pile of in-progress items.
What is the difference between Kanban and Scrum?
Scrum organizes work into fixed-length sprints (usually two weeks) with specific roles (Product Owner, Scrum Master, Development Team) and ceremonies (planning, daily standups, retrospectives). Kanban has no fixed iterations, no prescribed roles, and no mandatory ceremonies — it focuses purely on visualizing and optimizing the flow of work through a system. Scrum is more structured and suits teams building products in planned increments; Kanban suits teams with continuous or unpredictable incoming work.
What is cycle time in Kanban?
Cycle time is the elapsed time from when work on an item actively begins (typically when it enters the 'In Progress' column) to when it is complete. It is the most important operational metric in Kanban because it reflects actual team capacity and process efficiency. Tracking cycle time distributions over time reveals whether the process is stable, improving, or degrading.
Where did Kanban come from?
Kanban was developed at Toyota in the late 1940s by industrial engineer Taiichi Ohno, who was inspired by the replenishment system used in American supermarkets. In manufacturing, physical kanban cards signaled that a bin was empty and needed replenishing. David Anderson adapted this method for knowledge work around 2007, introducing the modern software/knowledge-work Kanban method that most teams use today.