← Back to glossary

Kanban

A pull-based workflow system where work flows through defined states (To-Do, In Progress, Review, Done), with explicit limits on work-in-progress to prevent bottlenecks and reduce context-switching.

What is Kanban?

Kanban is a visual management system originating from manufacturing, applied to knowledge work. Work items flow through states on a board: Backlog → To-Do → In Progress → Review → Done. Teams limit work-in-progress (WIP)—you can’t pull in new work until current work is completed. This constraint focuses effort and surfaces bottlenecks.

The power is simplicity and visibility. Everyone can see what’s blocked, who’s overloaded, and what’s ready to ship. No ceremony required: updates happen as work moves between states.

Work-in-Progress Limits

WIP limits are the core control mechanism. If your team has 5 engineers and the WIP limit for “In Progress” is 5, then once all 5 spots are full, nobody starts new work—they complete or unblock existing work. This prevents the chaos of 10 half-finished features that nobody can integrate.

Finding the right WIP limit takes experimentation. Too low (WIP=1) forces serialization; work is blocked by review bottlenecks. Too high (WIP=10) creates chaos; people multitask and context-switching kills efficiency. Most teams find balance around WIP = 1.5x team size.

Continuous Flow vs. Timeboxed Iterations

Kanban is continuous—work flows through as it’s ready, no fixed sprint boundaries. This differs from agile’s fixed sprints. For maintenance work, support, or operations, continuous flow is more natural. For product development, many teams hybrid: sprints for planning, but WIP limits within sprints.

Continuous flow also removes the sprint pressure: if you have 3 items in progress and 5 waiting, you can see clearly you need to unblock or ask for help. No surprises at sprint end.

Metrics and Insights

Kanban provides visibility: cycle time (how long from To-Do to Done), throughput (how many items complete per week), and bottleneck identification. If most items get stuck in Review, code review is a bottleneck—maybe you need more reviewers or lighter review process.

These metrics are quieter than agile’s velocity, but they’re real. Track them over time: if cycle time is increasing, something’s slowing down (more complexity, more dependencies, or increasing defects requiring rework).

Why It Matters for Product People

Kanban is ideal for teams doing mixed work: some feature development, some bugs, some support. Instead of forcing everything into sprints, you acknowledge the mix and limit parallel work.

It’s also powerful for revealing bottlenecks. If design is always waiting for engineering or engineering is always waiting for testing, the board shows it. This clarity enables intervention: add capacity where needed, automate bottlenecks, or reorganize.

For operations and maintenance, kanban is often more effective than agile. Support tickets, infrastructure work, and bug fixes don’t fit sprint boundaries well; continuous flow is more natural.

Kanban connects to throughput (measuring how many items complete), bottleneck analysis, and continuous improvement (the Japanese concept of kaizen applies directly). It also relates to team organization—WIP limits expose whether team size matches workload.