Kanban

A pull-based flow methodology. No sprints, no roles, no ceremonies (in pure form). Work flows continuously through a board with explicit Work-in-Progress (WIP) limits. Originated at Toyota in the 1940s for manufacturing; adapted to software by David Anderson (2010).

For sprint-vs-flow comparison: see 07_comparison_and_choosing.md.

The core ideas

The vocabulary is from manufacturing. “Kanban” is Japanese for “signboard” — the physical cards in Toyota’s just-in-time factories.

A Kanban board

| Backlog      | Ready   | In Progress (3) | Code Review (2) | Done  |
|--------------|---------|------------------|------------------|--------|
| Story F      | Story C | Story A          | Story B          | Story 1|
| Story G      | Story D | Story E          |                  | Story 2|
| Story H      |         |                  |                  | Story 3|

Columns are workflow states. The number in parentheses (e.g. “In Progress (3)”) is the WIP limit. With WIP=3, no more than 3 items can be in that column at once. If column is full, no one pulls a new item until something exits.

Pull, not push

In Scrum / Waterfall, work is pushed through phases. Designer hands off to developer, developer to tester, etc.

In Kanban, work is pulled: when a developer has capacity, they pull from “Ready.” When the testing column has room, a tester pulls from “In Progress.” Bottlenecks reveal themselves — if “Code Review” is always full, the org has a review bottleneck.

The pull model is critical. Without it, Kanban becomes “Scrum without sprints” — work piles up at the bottleneck stage, throughput suffers.

WIP limits — the key lever

The most counterintuitive part. Lower WIP = higher throughput. Why:

WIP limits feel like a constraint at first. Teams want flexibility. But the data is consistent: lower WIP, higher throughput.

How to set them:

• Start with WIP = team size (rough heuristic).
• Tighten if a column is constantly full.
• Loosen if items wait excessively.

There’s no formula. Tune by watching cycle time and throughput.

Little’s Law

Kanban’s foundational equation:

Lead Time = WIP / Throughput

If you have 30 items in progress (WIP) and finish 6 per week (throughput), average lead time is 5 weeks.

Implications:

• To reduce lead time: reduce WIP, or increase throughput.
• To increase throughput: usually reduce WIP first (counterintuitively) — multitasking costs hurt more than they help.
• Predictable systems require stable WIP.

Little’s Law works for any queue system; Kanban applies it to software work.

Metrics that matter

Kanban favors flow metrics over commitment metrics:

These are observable from the board. Story points and velocity aren’t necessary — Kanban teams often skip estimation entirely.

The CFD is the diagnostic chart. Constant widths between bands = stable flow. Bands diverging = work piling up at a stage. Bands converging = work draining at a stage.

Cycle time distributions

Plot cycle time of completed items as a histogram. You get a distribution (typically log-normal-ish).

Use the 85th percentile for forecasting: “based on history, 85% of items take ≤ X days.” Tell stakeholders “we can deliver this in 7-12 days with 85% confidence” instead of “5 story points = 5 days.”

Probabilistic forecasting + flow data beats estimation in many contexts.

Scrum vs Kanban

Scrum’s strength: cohesive iteration goals, rhythm of demos and retros, focus. Kanban’s strength: smooth flow, no batching cost, fits support / ops / unpredictable arrival.

Many teams blend (“Scrumban”) — fixed cadence + WIP limits + retros, but pull-based work flow within the sprint.

When Kanban wins

• Support / ops teams — tickets arrive unpredictably; sprint boundaries are awkward.
• Continuous-flow work — content production, ongoing feature work without major releases.
• Bug-heavy maintenance — bugs don’t respect sprint boundaries.
• Teams already burned out on Scrum ceremonies — minimal-process appeal.
• Highly interrupt-driven work — when emergencies routinely break sprint plans.

When Kanban struggles

• Long-running features that need coordination — Scrum’s sprint goal provides natural alignment.
• External stakeholder rhythms — execs want demos on a cadence.
• New teams — Scrum’s structure gives newer teams scaffolding; Kanban assumes maturity.
• Cross-team coordination at scale — Kanban scales less obviously than SAFe / LeSS.

Common Kanban antipatterns

No WIP limits

The board is visualized but nothing’s limited. Becomes “task tracker, not Kanban.” Throughput doesn’t improve; the team just sees their pile.

“WIP limit = 5 per person”

Per-person WIP defeats the purpose. WIP limits are per-column (workflow stage) and per-team. Individual focus follows naturally.

Columns that don’t reflect real workflow

The board has stages no one uses (“Design Review” that nobody does) or skips stages people actually do (“Stakeholder Review” missing). Cycle time and flow efficiency don’t match reality.

No metrics

Board visualizes work but no one tracks lead time or throughput. The team can’t see if changes are helping. Improvement is vibes-based.

Treating Kanban as “no process”

“We’re Kanban” used as cover for no planning, no estimation, no commitments. Customers see indeterminate delivery. The opposite of Kanban’s predictability promise.

Bottleneck blindness

Code Review is always full; team responds by adding columns elsewhere instead of solving the review bottleneck. Optimize the constraint (Theory of Constraints), not the non-constraint.

Classes of Service

Some teams categorize work into “classes of service” with different flow rules:

Visualized as colored cards or swimlanes. Helps when “everything’s a priority” — explicit policies for what jumps the queue.

Kanban in tools

Most issue trackers (Jira, Linear, GitHub Projects, Trello, Asana) support Kanban boards. The simple version is easy; the value comes from:

• Enforcing WIP limits (Jira does; Linear too).
• Tracking cycle time (CFD/cycle-time reports).
• Customizing columns to your actual workflow.

Pure Kanban requires no special tooling — a whiteboard with sticky notes is enough. The metrics tooling matters more for teams interested in continuous improvement.

Interview angle

• “What’s Kanban?” — pull-based flow methodology. Visualize work on a board, limit WIP per column, manage flow continuously. No sprints, no required roles or ceremonies. Originated at Toyota; adapted to software ~2010.
• “What’s a WIP limit and why?” — cap on items in a workflow stage. Reduces context-switching, makes bottlenecks visible, increases throughput. Counterintuitive but consistent: less WIP = more done.
• “Little’s Law?” — Lead Time = WIP / Throughput. To reduce lead time, reduce WIP or increase throughput. To increase throughput, typically reduce WIP first.
• “Kanban vs Scrum?” — Scrum has fixed sprints, roles, events; Kanban is continuous flow with explicit WIP limits and no mandated roles. Scrum for cohesive iterative goals; Kanban for continuous-flow / support / unpredictable arrival.
• “What’s a Cumulative Flow Diagram?” — stacked area chart showing items in each column over time. Constant widths = stable flow; diverging bands = work piling up at a stage; converging = draining. Primary diagnostic chart.
• “When would you choose Kanban over Scrum?” — support / ops teams with unpredictable ticket arrival, continuous-flow work, bug-heavy maintenance, teams burned out on ceremonies. Scrum better for feature development with clear iteration goals.
• “What’s an antipattern in Kanban?” — no WIP limits (board becomes just a task tracker), per-person WIP instead of per-column, no metrics, treating Kanban as “no process” — losing the predictability promise.