Kanban is a method for managing and improving the flow of work by making work visible, limiting work in progress and using actual workflow conditions to guide improvement. The term originates from Japanese production practices, where kanban can refer to a signboard or visual signal used to authorise and control production or movement of materials. The method became strongly associated with the Toyota Production System and was subsequently adapted for knowledge work and software development. Modern Kanban implementations commonly use a visual board with columns representing workflow states and explicit limits on the amount of work allowed in particular stages.
A basic Kanban system represents work items visually as they move through a defined workflow. A software team might have stages such as ready, development, testing and done, while a service organisation might use intake, analysis, waiting for customer information, processing and completed. The exact columns depend on the process. Visualisation allows teams to see work that is blocked, waiting or accumulating. This is valuable because queues and bottlenecks can remain hidden when work is tracked only through individual task lists or periodic reports. The board represents the flow of work rather than simply a list of responsibilities.
Work-in-progress limits, commonly called WIP limits, are central to Kanban. A WIP limit restricts how many items can simultaneously occupy a workflow stage or system. The purpose is to prevent the organisation from starting more work than it can effectively finish. If a testing stage has a capacity of five items and ten development tasks are allowed to enter it, a queue can grow while developers continue starting additional work. A WIP limit creates pressure to finish existing work, resolve blockers and improve the constrained stage before starting more work. This is closely related to the principle that limiting unfinished work can improve flow and reduce cycle time.
Pull is another important Kanban concept. Under a pull system, new work is started when capacity becomes available rather than being pushed continuously into downstream stages. If the testing column has room for another item, the team can pull the next suitable item from development. This differs from a push approach in which each upstream function sends work forward according to its own output target. Pull can reduce queues and make capacity constraints visible. However, a pull system still requires appropriate prioritisation, clear policies and attention to dependencies; simply moving cards across a board does not automatically create effective flow.
Kanban emphasises flow metrics. Cycle time measures how long a work item takes to move through the relevant workflow, while throughput measures how many items are completed in a given period. Work-in-progress measures how much unfinished work exists in the system. Lead time can describe the time from a customer's request or commitment point until delivery, depending on the defined measurement boundaries. Teams can use these measures to identify bottlenecks and evaluate whether process changes improve flow. Little's Law, expressed as average WIP equals average throughput multiplied by average cycle time under appropriate stable-system assumptions, provides a useful mathematical relationship between these variables.
Kanban is often described as an evolutionary approach because it can be introduced without requiring an organisation to replace its existing roles, hierarchy or development process. Teams can begin by visualising their current workflow, identifying explicit policies and introducing suitable WIP limits. Improvement then proceeds through observation and measured changes. This differs from methods that require an organisation to adopt a comprehensive set of roles and ceremonies from the beginning. However, evolutionary adoption does not mean that Kanban is informal or unstructured; explicit workflow policies, service expectations and measurement are important components of a mature Kanban system.
Kanban differs from Scrum even though both are widely used in agile and software environments. Scrum organises work around Sprints and defines specific accountabilities, events and artefacts. Kanban does not inherently require Sprints, Scrum roles or a fixed iteration cadence. Kanban focuses on flow, WIP, visualisation and continuous improvement. A Scrum team can use Kanban practices to improve flow within Sprints, and a Kanban team can use agile planning and feedback practices without adopting Scrum. Kanban also differs from a simple task board because a true Kanban system uses explicit workflow policies, manages WIP and seeks measurable improvement in flow.
Kanban can improve visibility, reduce excessive multitasking, expose bottlenecks, shorten cycle times and create a shared understanding of process performance. Its limitations include the risk of creating a visually attractive board without changing workflow behaviour, choosing inappropriate WIP limits, measuring activity rather than completed value and failing to address structural constraints. Kanban is most effective when teams use the board as an operational management system rather than merely a reporting display. Its underlying purpose is to manage and improve the movement of work through a system by making demand, capacity, queues, policies and performance visible and actionable.
