Kanban is a method for managing and improving the flow of work through a system by making work visible, limiting work in progress, managing flow, making policies explicit, establishing feedback loops and evolving the system through improvement. The word kanban is Japanese and can be translated broadly as signboard, visual card or sign. The method has historical roots in the Toyota Production System, where kanban cards and other signals were used to support pull-based production and replenishment.
Modern Kanban as a knowledge-work and service-management method was significantly developed by David J. Anderson and others, who adapted flow-management principles to software and professional work. Kanban is not synonymous with a physical board, although visualisation is one of its core practices. A basic Kanban system represents work items and stages of a workflow, making queues, bottlenecks and work in progress visible. The method is deliberately evolutionary: rather than requiring an organisation to replace its existing process wholesale, Kanban generally begins with the current workflow and uses observed flow problems to guide incremental change.
In manufacturing, kanban originated as a signalling mechanism within the Toyota Production System. A downstream process could signal the need for components, causing an upstream process to replenish what had been consumed. This supported pull production and helped regulate inventory and production quantities. Physical cards were a common form of signal, but kanban can also be implemented through containers, electronic signals or other mechanisms.
Modern Kanban for knowledge work uses the same underlying idea of controlling flow through explicit signals and limits, but the work items may be software features, customer requests, documents, incidents or other intangible outputs. The historical relationship is therefore important: manufacturing kanban and modern knowledge-work Kanban share concepts of signalling and flow but are not identical operational systems. The contemporary method is concerned with the whole workflow, including queues and policies, rather than merely providing a digital or physical board for displaying tasks.
Visualising work is fundamental because invisible queues and hidden dependencies are difficult to manage. A Kanban board typically represents workflow states such as requested, ready, in progress, review and completed, although the actual columns should reflect the organisation's real process rather than a generic template. Work items move through the workflow, allowing teams to see how much work is active, where it is waiting and where flow is being interrupted.
Policies determine when work can enter or leave each state, and these policies should be understandable to participants. Visualisation can expose problems such as too many items being started, excessive review queues, blocked work or uneven workloads. A sophisticated Kanban system may represent different classes of service, explicit dependency information, blocked states, service-level expectations and capacity constraints. The purpose is not visual attractiveness but improved shared understanding of how work actually moves through the system.
Limiting work in progress, or WIP, is one of Kanban's most important mechanisms. If too many tasks are started simultaneously, attention is divided, switching costs increase and completed work may accumulate in downstream queues. A WIP limit restricts the amount of work that can occupy a particular workflow state or system. When a downstream stage reaches its limit, upstream workers should generally help resolve the blockage rather than starting additional work.
This encourages a pull-like behaviour in which new work is started when capacity becomes available. Little's Law, expressed in a stable system as average work in progress equals average throughput multiplied by average cycle time, provides a useful quantitative relationship for understanding why reducing unnecessary WIP can reduce lead or cycle times when throughput remains stable. WIP limits do not automatically improve performance; poorly chosen limits can starve capacity or create artificial restrictions. They should therefore be treated as hypotheses that can be adjusted using flow data and observation.
Kanban places strong emphasis on managing flow rather than maximising local utilisation. Useful flow metrics can include lead time, cycle time, throughput, work-in-progress levels, ageing work items and flow efficiency. A cumulative flow diagram can show how work accumulates across workflow states and can help reveal bottlenecks or growing queues. Control charts can be used to examine cycle-time distributions and identify unusual variation.
Service-level expectations can be derived from historical delivery data rather than arbitrary promises, although forecasts remain probabilistic and should be communicated appropriately. These measurements allow teams to identify whether changes to WIP limits, policies or workflow design actually improve performance. Kanban therefore has a strong empirical dimension. A board full of cards without measurement or improvement is not necessarily an effective Kanban system. The method is concerned with the behaviour of the system over time, including predictability, flow, bottlenecks and the relationship between demand and delivery capacity.
Kanban differs from Scrum in important ways. Scrum defines a framework with specific accountabilities, events and artefacts, whereas Kanban does not require a Product Owner, Scrum Master, Developers, Sprints or the same formal cadence. Kanban can be applied to an existing workflow and does not require an organisational reset. It also differs from a simple task board because Kanban explicitly incorporates WIP limits, flow management, explicit policies and feedback mechanisms.
Kanban is compatible with Agile and Lean thinking, but it is not identical to either. Agile provides a broader set of values and principles for adaptive product development, while Lean provides a broader management and operational philosophy involving value, flow and waste. Kanban can support both without requiring every associated practice. This distinction is particularly useful in organisations where teams need to improve an existing process incrementally rather than adopt a complete alternative delivery framework.
Kanban can be applied to software development, IT operations, customer support, marketing, legal work, recruitment, procurement, manufacturing and other processes in which work items move through identifiable stages. A support team might visualise incoming requests, diagnosis, waiting for customer information, active resolution and completion. A software team might use Kanban to manage defects, maintenance work and operational changes. A legal department might represent matters progressing through review, drafting, approval and completion.
In each case, the value comes from understanding the actual flow and controlling the amount of work entering constrained stages. Kanban can also help identify policies that cause delays, such as excessive approval requirements or large batch sizes. However, not every workflow benefits from an elaborate board. If work is highly unpredictable, extremely short-lived or difficult to define as discrete items, visualisation may require adaptation. Kanban should represent the system rather than forcing the system into an artificial template.
Kanban's evolutionary nature is one of its defining characteristics. Rather than declaring the current process wrong and replacing it with a prescribed model, Kanban encourages organisations to understand the existing system, identify problems and introduce changes incrementally. This can reduce resistance and allow improvements to be evaluated against actual flow data. However, “evolutionary” does not mean that every existing policy should remain indefinitely. If evidence demonstrates that a policy creates a serious constraint, the policy can be changed.
Kanban also requires attention to demand, capacity, quality and classes of service; simply reducing WIP without addressing a structural bottleneck can move the queue elsewhere. The method's broader significance is that it treats work as a flow system whose performance depends on interactions among demand, capacity, queues, policies and constraints. By making those interactions visible and measurable, Kanban provides a practical mechanism for improving predictability and flow without requiring every organisation to adopt the same fixed process.
