What is kanban? Principles, metrics, and implementation

Kanban is a visual, pull-based method for managing workflow that limits the amount of work that occurs simultaneously. This approach ensures that teams complete their ongoing tasks before pulling new ones. Work items transition across columns on a kanban board, with each column indicating a stage in the process. Work-in-progress limits regulate the amount of items that can be allocated to any stage at a given time. The method originates from the Toyota Production System, where kanban cards indicated precisely when a production line required additional components, thereby replacing forecasts with actual demand. This same logic is now applied to product teams, hospital wards, marketing departments, and software squads operating far from the factory floor. This guide addresses the key questions that determine whether kanban changes how work flows, including how the board works, which principles govern it, which metrics prove its effectiveness, and how to implement it without running into obstacles on day one.

A definition built for flow

Kanban meaning is often reduced to “a board with sticky notes,” but the board is only the visible layer of a deeper kanban system for regulating flow. At its foundation, kanban is a pull system: work is pulled into the next stage only when capacity exists to handle it, rather than pushed downstream according to a fixed schedule. This distinction traces directly to the Toyota Production System, where Taiichi Ohno used physical kanban cards to trigger replenishment from a supermarket-style inventory buffer instead of producing to forecast. Applied to workflow management, the same principle prevents overloading any single stage of a process, whether that stage is a welding cell, a legal review queue, or a sprint of engineering tickets. Kanban sits alongside other Lean Manufacturing Tools within the broader lean toolkit, earning its place as a standalone discipline because limiting work in progress, on its own, changes behavior: people stop starting new work and start finishing it. That shift is what makes kanban a continuous improvement engine rather than a static scheduling chart.

The kanban board: structure and mechanics

A kanban board turns an abstract process into something a team can see and manage immediately. The simplest kanban board example has three columns, To Do, In Progress, and Done, but most real boards add stages that mirror actual handoffs: Backlog, Analysis, Development, Review, and Released, for instance. Each column carries a work-in-progress limit, a hard cap on how many cards it can hold, and that cap is what separates a working kanban board from a decorative one. Columns without limits allow work to pile up invisibly. Columns with limits force a conversation the moment they fill: something must finish, or be actively unblocked, before anything new starts.

This is visual management in its purest form: status, bottlenecks, and blocked items are visible without a meeting or a report. In our work with operational teams, boards that pair kanban logic with structured daily review- the kind of discipline behind Daily KAIZEN™ boards- sustain the practice far longer than boards left unattended. A board nobody reviews degrades within weeks: cards go stale, limits get ignored under pressure, and the visual signal stops meaning anything.

The six kanban principles that actually change behavior

Kanban rests on a small number of practices, and the practical difference between teams that benefit from kanban and teams that just relabel their to-do list comes down to how seriously each one is applied.

1. Visualize the workflow: every stage of real work becomes a column, so hidden queues become visible queues.
2. Limit work in progress: each column gets an explicit Work In Progress (WIP) limit, forcing the team to finish before starting.
3. Manage flow: attention shifts from individual busyness to how smoothly cards move end to end.
4. Make policies explicit: entry and exit criteria for each column are written down, so “done” means the same thing to everyone.
5. Implement feedback loops: regular, cadence-based reviews at different levels catch problems while they are still small.
6. Improve collaboratively, evolve experimentally: changes to the process are treated as testable hypotheses, not permanent commitments.

These six kanban principles form the core of the cumulative flow diagram, and they apply whether the workflow in question builds cars or closes invoices. The principle that generates the most resistance, and the most benefit, is limiting work in progress. Most teams starting out set WIP limits too high because lower limits feel uncomfortable: people are used to juggling several things and calling it productivity. Tightening the limit exposes exactly how much unfinished work was already in flight, which is uncomfortable to see and extremely valuable to fix.

Kanban metrics: lead time, cycle time, and throughput

Kanban metrics answer the question a status meeting never quite settles: is work moving, or does it just feel busy? Three numbers matter most. Lead time measures the total elapsed time from when a request enters the system to when it is delivered, capturing the customer’s real waiting experience. Cycle time measures only the active working period, from the moment someone starts the item to the moment it finishes, and it is the number a team can most directly influence. Throughput measures how many items are completed per unit of time and indicates whether a backlog is shrinking or growing, regardless of how fast any single item moves.

A cumulative flow diagram plots these dynamics together: bands representing each workflow stage, stacked over time. A widening band signals a bottleneck accumulating in that stage; parallel, evenly spaced bands signal healthy flow, showing where work is stuck rather than just how much remains.

None of these numbers mean much without a baseline. Before setting WIP limits or comparing weeks, run a Value Stream Mapping exercise across the workflow being measured: map every step, every handoff, every queue, and every delay currently invisible to the team. That mapping step turns kanban metrics from an abstract dashboard into a diagnostic tied to the specific process generating the numbers.

How to implement kanban without stalling on day one

Teams that ask how to implement kanban successfully tend to follow a similar sequence, adapted to context but rarely skipping steps.

1. Map the current workflow exactly as it happens today, including the stages nobody officially acknowledges, like waiting for approval or sitting in a shared inbox.
2. Design the board to match that mapped reality, not an idealized version of the process.
3. Set an initial WIP limit for each column, generally lower than instinct suggests, and treat the first number as a hypothesis rather than a rule.
4. Write explicit policies for what qualifies work to enter and exit each column.
5. Launch the board with the team that will run it daily, not with a rollout memo.
6. Review flow metrics on a fixed cadence and adjust limits based on evidence rather than complaint volume.

The cadence in step six matters most. A weekly look at the board catches local problems; a broader review, conducted with the same rigor as KAIZEN™ Cycles, catches systemic problems that span teams rather than reside within a single column. Leadership involvement changes the outcome too: boards reviewed only by the team that owns them tend to optimize locally, while boards that also receive periodic Leadership gemba coaching surface cross-team constraints no single team can resolve alone. Kanban needs no big-bang rollout, only a board that reflects reality, limits enforced under pressure, and a review rhythm nobody skips when the week gets busy.

Kanban vs scrum: choosing the Right Flow System

The kanban vs scrum question assumes teams must pick one permanently, but the two solve different problems and can even run together. Scrum organizes work into fixed-length sprints with defined roles and ceremonies. Kanban has no required roles, no mandatory sprint length, and no prescribed meetings. Scrum fits work that benefits from batching and a fixed planning horizon, such as coordinated feature releases. Kanban fits work that arrives continuously and unpredictably, such as support tickets, maintenance requests, or an operations queue that never truly closes. The table below breaks down where each one fits.

Table 1 – kanban vs. scrum overview

Many teams use both: a scrumban approach that keeps sprint planning for roadmap work while limiting WIP within each sprint to prevent the overcommitment that turns sprints into wish lists.

Kanban beyond the factory: offices and knowledge work

Kanban left the factory floor decades ago; most teams reading this now meet it inside project management software rather than on a shop floor. The logic transfers cleanly: a marketing team limits how many campaigns are in active production, a legal department limits how many contracts are under review, a hospital ward limits how many patients occupy the discharge-planning stage at once. In these Agile office environments, the unit of work changes, not the principle: cards represent tickets, briefs, or claims rather than parts, and cycle time is measured in days rather than minutes. The failure mode transfers too. Teams that adopt the software without limiting WIP get a prettier to-do list. Enforced limits and honest daily review are what make it a working kanban system.

What ultimately determines results

Kanban rewards discipline more than adoption. The board, the limits, and the six principles are simple enough to sketch on a whiteboard in ten minutes. What takes longer, and what determines results, is enforcing WIP limits when the pressure to start new work is highest, and reviewing flow metrics even in the weeks nothing feels broken. Sustained results come from ongoing practice: teams that keep adjusting WIP limits and revisiting policies as conditions change are the ones that embed a continuous improvement culture around their kanban system, and their gains compound quarter after quarter. Kaizen Institute works with operations, service, and office teams to build kanban systems that survive past the initial launch, turning early flow gains into lasting reductions in lead time and steadier throughput. Start with one workflow, set the WIP limit lower than you feel comfortable with, and let the board tell you what to fix next. Kanban delivers when it stops being an initiative and becomes how the team works, the shift KAIZEN™ Culture consulting is built to make

Still have some questions about kanban?

What is kanban in simple terms?

Kanban is a way of managing work by visualizing it on a board, limiting how much happens at once, and pulling in new work only when there is capacity to handle it. It began as a scheduling system within the Toyota Production System and now organizes work across software teams, hospitals, marketing departments, and operations of all kinds.

What is the difference between kanban and scrum?

Kanban has no fixed iterations, no required roles, and no mandatory ceremonies; it manages flow continuously by limiting WIP. Scrum organizes work into fixed-length sprints with defined roles and events. Teams handling continuous, unpredictable demand generally favor kanban, while teams delivering coordinated feature releases often favor Scrum, or a blend of both known as scrumban.

What was the original kanban card used for?

At Toyota, a physical kanban card authorized a workstation to produce or move a specific quantity of parts, replacing forecast-driven push scheduling with actual downstream consumption. That card is the ancestor of every digital kanban board column limit used today.