Kanban is a method for managing and improving the flow of work by making work visible, limiting work in progress, managing flow, establishing explicit policies, implementing feedback loops and improving collaboratively and experimentally. In software development, Kanban commonly uses a visual board representing workflow states such as selected, development, review, testing and done, although the exact states should reflect the actual process rather than a universal template.
Work items move through the system as capacity becomes available instead of necessarily being assigned to fixed-length iterations. A central principle is limiting work in progress, or WIP, because excessive concurrent work can increase context switching, queues and cycle times. Kanban originated from manufacturing practices associated with the Toyota Production System, where visual signals were used to coordinate replenishment and production. The modern software-development method adapts these ideas to knowledge work, where work items are less physically tangible and workflows can involve analysis, coding, testing, deployment and operational activities.
The historical roots of Kanban lie in industrial production rather than software. Toyota developed just-in-time manufacturing practices in which production and replenishment were closely connected to actual demand and available capacity. Visual cards or signals communicated when materials or work should move through the system. Software teams later adapted the underlying ideas to manage queues of knowledge work, particularly in environments where incoming work was continuous and unpredictable. David J.
Anderson played a major role in articulating a Kanban Method specifically for knowledge work and software development. Modern Kanban retains the emphasis on visualising workflow and controlling work in progress while adding explicit attention to service delivery, flow metrics and evolutionary improvement. The Japanese word kanban can be translated in contexts as signboard, billboard or visual card, reflecting the method's emphasis on visible signals. However, a simple task board is not necessarily Kanban: Kanban requires management practices such as WIP limits, explicit workflow policies, flow management and continuous improvement.
A Kanban system begins by defining and visualising the workflow through which work actually travels. Columns or states represent meaningful stages, while cards represent work items and provide information needed to understand their status. Work-in-progress limits restrict the number of items allowed in particular states, encouraging teams to finish existing work before starting more. When a downstream stage reaches capacity, upstream workers may assist with blocked work rather than continuously adding new tasks.
This creates a pull system in which work is pulled into a stage when capacity exists. Policies should make the workflow rules explicit, including definitions of when an item enters or leaves a state, priority rules, service expectations and handling of blocked work. Feedback loops such as regular replenishment, delivery planning and service-delivery reviews allow the system to be inspected and adjusted. The objective is not simply to make a board visually attractive but to create a transparent model of how work moves through the organisation.
Kanban is strongly associated with quantitative flow concepts. Cycle time measures the elapsed time between defined start and completion points for a work item, while throughput measures how many items are completed within a specified period. Work in progress is the quantity of unfinished work currently in the system. Little's Law, under appropriate stable-system assumptions, relates average WIP, throughput and average flow time through the relationship WIP equals throughput multiplied by cycle time.
This relationship provides a useful conceptual basis for understanding why increasing concurrent work can increase average completion time when throughput does not increase proportionally. Cumulative flow diagrams can visualise the amount of work in different workflow states over time and expose growing queues or bottlenecks. These measurements should be interpreted statistically and in context because work items vary in size and complexity. Treating a single average cycle time as a guarantee can be misleading, which is why mature Kanban practices may examine distributions, percentiles and variability rather than relying solely on averages.
Kanban differs from Scrum in several important respects. Scrum defines a specific framework involving Sprints, accountabilities and formal events, whereas Kanban does not require fixed-length iterations or Scrum roles. Kanban can operate continuously, allowing work to be pulled whenever capacity becomes available. It can therefore be particularly useful where incoming demand is variable, work items differ substantially or urgent operational requests are common.
Kanban and Scrum are not mutually exclusive: a Scrum team can use Kanban practices such as WIP limits and flow metrics, and organisations sometimes combine iterative planning with flow-based execution. Kanban also differs from simply assigning every worker a fixed number of tasks because its emphasis is on managing the system as a whole. Optimising individual utilisation can actually damage overall flow if it creates queues or prevents workers from helping constrained stages. The relevant unit of analysis is therefore the movement of work through the system rather than the apparent busyness of individual people.
Kanban can improve delivery by exposing bottlenecks, reducing excessive concurrency, making queues visible and encouraging completion over starting. WIP limits can reduce context switching and reveal process constraints that remain hidden when teams continuously accept new work. Because Kanban is evolutionary, teams can begin by mapping their existing process rather than replacing it wholesale with a prescribed workflow. This can make adoption less disruptive in organisations that cannot easily reorganise around fixed iterations.
However, Kanban is not simply an instruction to put tasks on a board. Poorly designed boards can conceal important workflow states, and arbitrary WIP limits can create artificial constraints if they do not correspond to actual system capacity. Excessive focus on flow metrics can also encourage local optimisation or gaming. Kanban cannot resolve fundamental problems such as inadequate staffing, poor product strategy or contradictory priorities merely through visualisation. Its purpose is to make system behaviour visible and provide mechanisms for deliberate improvement.
Kanban is applicable beyond software feature development. It can support maintenance, technical support, infrastructure work, content production, security remediation, documentation, incident follow-up and other knowledge-work processes where items progress through identifiable stages. Different classes of service can be used when work has different urgency or handling requirements, provided the policies are explicit. Blocked work can be represented visibly so that dependencies do not disappear inside apparently active tasks.
Replenishment decisions determine which items enter the system, while delivery policies determine how completed work is released to customers or downstream processes. In environments with continuous deployment, Kanban can connect product work to a continuous release flow rather than requiring a batch release at the end of an iteration. This makes the method adaptable to many operational models, although its usefulness still depends on having a workflow that can be meaningfully visualised and managed.
The broader significance of Kanban is its treatment of development as a flow system rather than a collection of isolated individual activities. Its principles encourage organisations to understand queues, bottlenecks, variability, dependencies and capacity instead of assuming that more simultaneous activity necessarily means more output. A mature implementation continuously examines whether WIP limits, workflow policies, prioritisation rules and system boundaries produce desirable outcomes. Kanban is therefore both a management method and an improvement discipline.
Its visual boards, cards and metrics are mechanisms rather than the essence of the method. The deeper concepts are transparency of workflow, controlled work in progress, pull-based movement, explicit policies, feedback and incremental improvement. When these principles are applied consistently, Kanban can provide a flexible framework for improving predictability and flow without requiring an organisation to adopt a completely different development lifecycle.
