Kanban is a method for managing work as a continuous flow. Each piece of work is a card on a board, divided into columns that show its stages, such as to do, in progress, testing and done. The team sets a limit on how many cards can be in each stage at once, and pulls in new work as items finish and capacity frees up. The result is a visible picture of what is happening, where work is stuck and how long it takes to get through. Kanban started in manufacturing and is now widely used in software development, IT operations and support.
At a glance
- Work is shown on a board, physical or digital, with columns for each stage.
- Limits on work in progress stop the team from starting more than it can finish.
- There are no fixed cycles: work is pulled in when capacity frees up.
- Teams measure flow, especially how long items take from start to finish.
- It is generally considered one of the Agile approaches, and is often used for maintenance, support and operations.
What problem it solves
Many teams have more requests than capacity, and the instinct is to start everything at once. Work then piles up half-finished, people switch constantly between tasks, and nothing gets done quickly. Managers can’t see where the blockage is, and requesters can’t get a straight answer about when their item will be finished.
Kanban makes that problem visible and puts a brake on it. Seeing every item on a board shows where work queues up, for example a long line waiting for testing or approval. Work-in-progress limits force the team to finish before starting, which tends to shorten the time each item takes. And because there are no fixed cycles, urgent work can be pulled in as soon as there is room, without waiting for the next planning point. That suits teams whose work arrives unpredictably, which is why Kanban is common in support, maintenance and operations.
How it works
Visualize the work. Every item becomes a card, and the board’s columns reflect how work actually moves. Many boards add lanes for different kinds of work, such as urgent fixes versus planned changes.
Limit work in progress. Each column, or the board as a whole, has a maximum number of items. When a column is full, the team clears it before pulling more in.
Pull, don’t push. People take the next item when they have capacity, rather than having work assigned faster than it can be done.
Make policies explicit. The team agrees what each column means, what “done” means for each stage, and how priorities are set.
Measure and improve. Common measures are lead time (from request to delivery), cycle time (from start of work to finish) and throughput (items finished per week). The team reviews these regularly and adjusts the board, limits or process.
Kanban doesn’t define roles or required meetings. Teams often hold short daily stand-ups and periodic reviews, and some combine Kanban boards with Scrum sprints.
When it matters for buyers
- When a provider runs your support or maintenance work. Many help desk, application support and DevOps teams use Kanban. Our help desk overview covers how support providers are compared.
- When a contract covers ongoing work rather than a project. A statement of work (SOW) for Kanban-style work usually commits to capacity, response times and flow measures rather than a fixed list of deliverables. Check that lead time or throughput is reported, not only hours spent.
- When working alongside IT service management. Kanban boards often sit next to ITSM ticket queues and change processes. Make sure the two stay consistent.
- When small fixes keep losing out. A dedicated lane or capacity limit for technical debt and maintenance helps keep that work moving.
Questions to ask vendors
- Which work do you manage with Kanban, and can we see the board?
- What work-in-progress limits do you use, and who sets them?
- How do you prioritize and expedite urgent requests?
- Which flow measures will you report to us, such as lead time and throughput, and how often?
- How is the work priced: by capacity, by item or by hour?
- How does the board connect to our ticketing and change processes?
How it differs from Scrum
Scrum organizes work into fixed-length sprints with defined roles and a set of recurring meetings: planning, a daily check-in, a review and a retrospective. Priorities generally change between sprints. Kanban has no required sprints, roles or meetings; priorities can change at any time, and the main controls are the board and the limits on work in progress. Scrum tends to suit building a product in planned increments with regular stakeholder reviews. Kanban tends to suit continuous or unpredictable work, such as support queues and operations. Neither is better in general, and many teams use a blend.