Work Methodologies DefinedTerm

Kanban

Also known as: Kanban Method, Kanban Board

A lean method to manage and improve work through workflow visualization, work-in-progress limits, and continuous optimization.

Updated: 2026-01-04

Definition

Kanban is a method for managing and improving work through human-based systems, derived from the Toyota Production System. In the software context, the method was adapted by David Anderson (2010) as an alternative or complement to iterative approaches like Scrum.

The name comes from Japanese “看板” (visual signal). The fundamental principle is to visualize workflow and limit work-in-progress (WIP) to identify and resolve bottlenecks, continuously improving lead time and throughput.

Core Principles

Kanban is based on 4 core principles and 6 general practices:

Principles

  1. Start with what you do now: Kanban doesn’t require upfront organizational changes
  2. Agree to pursue incremental, evolutionary change: no revolution, only continuous improvement
  3. Respect current roles, responsibilities, and titles: preserve what works
  4. Encourage leadership at all levels: not just top-down

Practices

  1. Visualize the workflow: make the process explicit with a Kanban board (columns = work states)
  2. Limit WIP: each column has a maximum number of in-progress items to prevent multitasking and overload
  3. Manage flow: monitor and optimize work movement through the system
  4. Make policies explicit: clear criteria for “done”, pull policies, prioritization
  5. Implement feedback loops: standups, reviews, retrospectives
  6. Improve collaboratively, evolve experimentally: use data and models to guide change

How It Works

Kanban board: physical or digital visualization with columns representing states (e.g., To Do, In Progress, Review, Done). Each card is a work item. Columns have WIP limits (e.g., “In Progress: max 3”).

Pull system: work is “pulled” from the next column when there’s capacity, not “pushed” based on schedule. If a column is at its WIP limit, new work cannot be pulled.

Flow metrics:

  • Lead time: total time from request to delivery
  • Cycle time: time from work start to completion
  • Throughput: number of items completed per time unit
  • Work in Progress: items currently being worked on

Cumulative Flow Diagram (CFD): chart visualizing work item distribution across states over time. Allows identification of bottlenecks and trends.

Differences with Scrum

Cadence: Scrum has fixed time-boxed sprints, Kanban is continuous flow without predefined iterations.

Roles: Scrum defines Product Owner, Scrum Master, Developers. Kanban doesn’t prescribe roles; adapts to existing organization.

Commitment: in Scrum the team commits to a set of work for the sprint. In Kanban commitment is implicit in WIP limits but can change continuously.

Metrics: Scrum uses velocity (story points/sprint). Kanban uses lead time, cycle time, throughput.

Scrumban: hybrid combining Scrum sprints with Kanban WIP limits and flow. Used by 9% of agile organizations (State of Agile 2024).

Use Cases

Continuous flow work: support, operations, maintenance benefit more from Kanban than Scrum. No need for artificial time-boxes when work arrives continuously.

Mature teams: already effective teams wanting to optimize without upheaval benefit from Kanban’s evolutionary approach.

Combination with Scrum: many Scrum teams add WIP limits and flow metrics to identify intra-sprint bottlenecks.

Portfolio management: Kanban scales naturally to portfolio level to visualize cross-team initiatives.

Practical Considerations

WIP limits: start with permissive limits and gradually tighten while observing flow. Too low limit blocks work, too high hides problems. Rule of thumb: ~2x number of people per column.

Card granularity: work items too large mask flow, too small create overhead. A complete cycle should complete 10-30 cards per month.

Tooling: physical tools (post-its on wall) maximize visibility and collaboration for co-located teams. Digital tools (Jira, Trello, Azure Boards) necessary for distributed teams.

Classes of Service: differentiate urgency/priority with swimlanes or colors (Expedite, Standard, Fixed Date, Intangible). Each has different SLA policies.

Common Misconceptions

”Kanban is just a board with columns”

No. The board is the visualization tool, but the method includes principles, practices, metrics, and a culture of data-driven continuous improvement.

”Kanban means no planning”

False. Kanban requires continuous refinement and backlog prioritization. Planning is just-in-time rather than upfront, but always present.

”Kanban is better than Scrum (or vice versa)”

It depends on context. Scrum works well for new teams, projects with defined scope, fixed release cadence. Kanban for mature teams, continuous work, optimizing existing systems. Many teams use both.

”WIP limits should be violated when there’s urgency”

No. Urgency reveals a system problem (prioritization, capacity planning). Violating WIP limits degrades flow for everyone. Kanban provides “Expedite” lane for true emergencies, but with rigorous policies.

Sources

Back to Glossary