1 Overview
Kanban is a method for managing knowledge work by making the state of that work visible and by limiting how much of it is allowed to be in progress at once. It grew out of lean manufacturing thinking, where a signal authorizes the next unit of production, and it was adapted for software and other service work in the mid-2000s. The core idea is simple: put every piece of work on a board, draw columns for the stages it passes through, and cap the number of items permitted in each column.
What separates Kanban from iteration-based approaches is that it does not require a team to change its existing process before starting. You begin by mapping what you already do, then you add limits and policies incrementally. There is no prescribed set of meetings, no required roles, and no fixed-length sprint. The method is descriptive before it is prescriptive, which is why teams often adopt it as a first step toward more deliberate flow management.
The board is the center of gravity. Columns represent stages, cards represent work items, and the limits written at the top of each column represent a commitment the team makes to itself. When a column is full, no new work enters it, even if someone is idle. That single rule is what turns a passive status board into an active control system, and it is the mechanism that makes bottlenecks visible rather than hidden.
2 The problem this method was built to solve
Most teams do not fail because they lack talented people. They fail because too much work is started and too little is finished. When everyone juggles several tasks at once, each task waits while attention moves elsewhere, and the average time from start to finish stretches far beyond the actual working time. The work is not slow because people are slow; it is slow because of queueing.
Kanban was built to attack that specific failure. By capping work in progress, it forces a team to finish before starting, which shortens queues and reduces the number of half-done items sitting around. It also makes the cost of overload visible. When a column is at its limit and a new request arrives, the team must decide explicitly whether to finish something, pull something back, or say no. That decision used to be invisible; now it happens at the board.
A second problem Kanban addresses is the mismatch between local efficiency and system throughput. A developer who is always busy can still be part of a slow system if their output piles up in front of a tester or a reviewer. Kanban shifts attention from individual utilization to the flow of the whole value stream, which is why it often reveals that the real constraint sits in a specialty that nobody thought to question.
3 How one cycle runs, from ready to done
A cycle begins when a work item is selected from a queue of ready options. In Kanban this selection is a pull, not an assignment: the team or the person responsible looks at the board, finds a column with room under its limit, and takes the next item that fits the entry criteria. The item is not started because someone is free; it is started because the system has capacity for it.
Once in progress, the item moves rightward through the columns, but only when its exit criteria are met and only when the next column has space. If testing is full, development stops pulling new work and helps clear the queue instead. This is the moment where Kanban differs most from a push-based process. Idle capacity is treated as a signal to improve the constraint, not as a reason to start more work.
A cycle ends when the item reaches the final column and satisfies the definition of done, which might include review, documentation, deployment, or customer acceptance. The team then records how long the item took from start to finish and how long it waited in each column. Over many cycles, those measurements show where time is actually spent, and the team adjusts limits, policies, or staffing based on evidence rather than intuition.
4 Roles and how they divide the work
Kanban prescribes no roles. That is a strength and a weakness. There is no product owner, no scrum master, and no mandated team structure. Instead, the method assumes that the people doing the work are best placed to design the board, set the limits, and write the policies. The team owns the system collectively, and anyone can propose a change to it.
In practice, teams often add lightweight responsibilities without turning them into formal titles. Someone may act as a board facilitator, keeping the board accurate and running the standup. Someone may manage the queue of incoming requests, deciding what is ready and what is not. Someone may watch flow metrics and raise the alarm when cycle time or queue size drifts. These are service roles, not authority roles, and they rotate or dissolve as needed.
Because roles are optional, Kanban can be adopted inside an existing structure without a reorganization. A support team, a platform team, and a data team can all use the same board mechanics while keeping their own reporting lines. The trade-off is that without explicit ownership, no one may feel responsible for the board, and it can decay into a stale status display. The method works best when someone genuinely cares about keeping the system honest.
5 Artifacts worth keeping
The primary artifact is the board itself, whether physical or digital. It shows columns for the stages of work, cards for individual items, and explicit limits at the top of each column. A board without limits is just a status wall; the limits are what make it a control mechanism. Cards should carry enough information to be understood at a glance, such as a title, an owner, and any blocking condition.
The second artifact is the set of written policies. These describe when an item is ready to enter, what must be true before it can leave a column, and how the team handles exceptions such as urgent requests or blocked work. Policies matter because they remove ambiguity and make the board reproducible. Without them, different people apply different standards and the limits lose their meaning.
A third artifact is the flow data the team collects over time, typically cycle time and throughput. Cycle time measures how long an item takes from start to finish, and throughput measures how many items are completed in a period. These are not reports for management; they are feedback for the team. When cycle time rises, the team can look at the board, find the column where items are piling up, and treat that as the next improvement target rather than guessing.
6 Where this method breaks down
Kanban's greatest strength is also its greatest limitation. It makes bottlenecks visible, but it does not tell you how to remove them. If the constraint is a single specialist, a slow approval, or a dependency on another team, the board will show the pile-up clearly and then offer no further instruction. Teams that expect the method itself to solve the problem will be disappointed; the method only surfaces it.
A second breakdown point is the absence of a planning horizon. Continuous flow works well when work arrives steadily and priorities are stable. When priorities shift constantly, or when the team must commit to a scope by a date, the lack of a fixed iteration can make forecasting harder. Some teams add cadence through regular replenishment or review meetings, but that is a local adaptation, not a built-in feature of Kanban.
Finally, Kanban can become an excuse for avoiding hard conversations. A team can maintain a tidy board, respect its limits, and still deliver slowly because nobody addresses the underlying constraint. The method also says little about cross-team coordination, so when several boards depend on one another, the local limits can create system-wide stalls that no single team can see. Kanban is a mirror, not a mechanic; it shows the problem and waits for the team to act.
7 Frequently asked questions
Does Kanban require a daily meeting? No. Nothing in the method mandates a standup. Many teams hold a short daily conversation around the board because it helps them coordinate and spot blockers, but the frequency and format are choices. Some teams meet twice a week, some meet only when the board changes significantly, and some rely on asynchronous updates. The only requirement is that the board stays accurate enough to be trusted.
Can Kanban and Scrum be combined? Yes, and they often are. A team can work in fixed-length iterations while using a board with work-in-progress limits inside each iteration. This hybrid keeps the planning and review rhythm of Scrum while adding the flow discipline of Kanban. The risk is that the limits become decorative if the team still pushes work in at the start of every sprint regardless of capacity.
How do you decide the right work-in-progress limit? There is no universal number. Teams typically start with a limit roughly equal to the number of people who can work in that stage, then lower it gradually and observe what happens. If cycle time improves and the team is not starved, the limit is probably reasonable. If items sit blocked and nobody can help, the limit may be too tight or the constraint may be elsewhere.
What if urgent work arrives? Kanban handles this through explicit policy rather than silent exception. A common approach is to reserve one slot in the relevant column for expedited items, with a rule that the team must swarm on it and that normal work resumes only when the slot frees up. The point is to make the trade-off visible instead of pretending the urgent item costs nothing.