1 Overview
Kanban is a method for managing and improving the flow of work through a system. It is not a software development lifecycle, a project management framework, or a team-building program. At its center is a board that visualizes work items as cards moving through columns that represent stages of delivery. Each column has explicit policies that describe what it means for a card to enter, reside in, and leave that stage. The most important of those policies is often the work-in-progress limit, which caps how many cards may occupy a stage at once. That limit is not a target; it is a constraint that forces the system to finish work before starting more.
The method is deliberately light on prescribed roles, meetings, and artifacts. It assumes that an organization already has a workflow, whether that workflow is healthy or not, and asks people to make it visible before changing it. Improvement then comes from observing flow metrics, finding bottlenecks, and adjusting policies. Because Kanban does not require a new team structure or a fixed iteration, it can be adopted incrementally by teams that cannot pause delivery to reorganize. That same flexibility is also its main limitation: Kanban will not tell you what to build, how to split work, or how to resolve deep organizational dysfunction. It is a mirror and a set of constraints, not a transformation program.
2 The problem this method was built to solve
Kanban emerged from the observation that many teams were busy but not delivering. Work started faster than it finished, queues grew, and priorities shifted before anything reached customers. The visible symptom was a board full of cards in progress, but the underlying problem was a system that rewarded starting over finishing. When there is no limit on work in progress, people naturally pull more work than the system can complete. Each new card adds coordination cost, context switching, and delay to every other card. The result is long cycle times, unpredictable delivery dates, and a growing pile of almost-done work that hides the real bottleneck.
The method was built to make that behavior visible and then constrain it. By limiting work in progress, Kanban forces the team to finish what it started before taking on more. By making policies explicit, it removes ambiguity about when work is ready, who pulls it, and what done means. By measuring cycle time and throughput, it replaces opinion with observation. The problem Kanban addresses is not a lack of effort or skill; it is a lack of flow. Teams often know how to do their individual jobs, but the handoffs between them create delay. Kanban targets those handoffs and the queues around them, not the people performing the work.
3 How one cycle runs, from ready to done
A cycle begins when a work item is selected from a backlog or input queue and placed on the board. That selection is governed by a replenishment policy: what kinds of work are allowed, how many items may enter, and in what order. Once on the board, the card moves through columns that represent the actual stages of delivery, such as analysis, development, review, and release. Each column has an explicit policy describing what must be true for a card to enter and what must be true for it to leave. A card is not moved because someone feels it is time; it is pulled when the next stage has capacity under its work-in-progress limit.
As the card moves, the team records its cycle time, typically from the moment work starts to the moment it is done. When a card reaches the final column, it is delivered or released according to a defined policy. The board is then replenished with new items up to the allowed limit. This cycle is continuous rather than iterative: there is no sprint boundary that resets the board. Instead, the team reviews flow metrics at a regular cadence, identifies where cards are waiting, and adjusts policies or limits. The cycle is therefore both a delivery loop and a learning loop. Each card is a small experiment in how the system behaves, and the accumulated data from many cards shows whether the system is improving or degrading.
4 Roles and how they divide the work
Kanban does not define roles such as product owner, scrum master, or team member. It assumes that people already have jobs and responsibilities, and it asks them to make their work visible without renaming themselves. In practice, three responsibilities often emerge. The first is managing the service request queue: deciding what work enters the system, in what order, and under what class of service. The second is managing service delivery: watching flow, removing blockers, and ensuring that work-in-progress limits are respected. The third is managing the flow system itself: tracking metrics, facilitating reviews, and proposing policy changes. These responsibilities can be held by one person, shared across a team, or distributed by existing role.
Because there are no prescribed roles, Kanban can expose role confusion that other methods would paper over. If no one owns replenishment, the board fills with low-value work. If no one owns delivery, cards age in a queue while everyone assumes someone else is handling it. If no one owns the system, limits are ignored and policies drift. The method does not solve these problems by assigning a title; it solves them by making the consequences visible. A team that cannot decide who pulls work or who talks to stakeholders will struggle with Kanban, not because the method is complex, but because it refuses to hide accountability behind a framework.
5 Artifacts worth keeping
The central artifact is the kanban board itself, whether physical or digital. It shows columns, cards, work-in-progress limits, and the policies that govern movement. A board without explicit policies is just a task list; the policies are what turn it into a management system. Cards should carry enough information to be actionable and no more. A typical card identifies the work item, its class of service, its start date, and any blocking condition. Overloading cards with detail slows movement and encourages people to treat the board as a documentation repository rather than a flow tool.
The second artifact is the set of flow metrics. Cycle time measures how long a card takes from start to done. Throughput measures how many cards are completed in a period. Work-in-progress measures how many cards are active at once. These metrics are not performance reviews; they are diagnostic tools. A rising cycle time with stable throughput usually indicates growing queues or blocked work. A falling throughput with stable work in progress usually indicates that cards are getting larger or that a downstream stage has become a bottleneck. The third artifact is the policy record itself: a written description of what each column means, what limits apply, and how exceptions are handled. Without that record, the board becomes a matter of individual interpretation, and improvement becomes impossible to sustain.
6 Where this method breaks down
Kanban struggles when the organization needs more than flow improvement. Because it does not prescribe roles, meetings, or a planning cadence, it can leave teams without a shared commitment to a goal. A board can show work moving smoothly while the product drifts, because Kanban optimizes the delivery system, not the decision about what to deliver. Teams that need strong cross-functional planning, a clear product vision, or a regular opportunity to renegotiate scope may find Kanban too passive. It will not force those conversations; it will only make the consequences visible if someone is watching.
Kanban also struggles when the existing workflow is fundamentally broken. If work must pass through a stage that is chronically understaffed, over-specialized, or politically protected, a work-in-progress limit will simply expose the bottleneck without resolving it. The method can make the problem undeniable, but it cannot make the organizational change required to fix it. In addition, Kanban assumes that work items are roughly comparable and that flow can be measured. When work is highly variable, when urgent interruptions dominate, or when done is ambiguous, the board can become a source of frustration rather than clarity. Finally, Kanban offers little guidance on team formation, skill development, or technical practice. It is a management method, not an engineering method, and it should not be asked to solve problems that belong to those domains.
7 Frequently asked questions
Is Kanban just a board with columns? No. A board without explicit policies and work-in-progress limits is a visualization, not a Kanban system. The limits and policies are what create the feedback loop that drives improvement. Can Kanban and Scrum be combined? Yes, many teams use a kanban board inside a Scrum framework to visualize sprint work and limit work in progress. The combination can work well, but it requires care: Scrum's fixed iteration and Kanban's continuous flow have different assumptions about planning and change. Does Kanban require a dedicated coach or manager? No. It requires someone to own replenishment, delivery, and system improvement, but those responsibilities can be distributed. The method does not prescribe a title.
How do you handle urgent work in Kanban? Most teams define a class of service for urgent items, with its own policy and sometimes its own work-in-progress limit. The key is to make the exception explicit rather than letting urgency silently override every limit. How do you know if Kanban is working? Look at cycle time, throughput, and work in progress over time. If cycle time is stable or falling while throughput is stable or rising, the system is likely improving. If work in progress is rising without a corresponding rise in throughput, the system is accumulating delay. What is the biggest mistake teams make with Kanban? Treating the board as a status report for managers rather than a tool for managing flow. When the board is updated for appearances, the metrics become unreliable and the feedback loop breaks.