Scrum is not the only Agile game in town. Kanban — pulled into software from Toyota's manufacturing system via David Anderson's 2010 book — focuses on flow. It is older than Scrum in spirit and complements it well.
The Core Practices
Kanban is not a process; it is a method that overlays whatever process you have today. Six core practices:
- Visualise the workflow. Make work and its state visible on a board.
- Limit work in progress. Cap how many items can be in each column.
- Manage flow. Optimise for items moving through, not workers staying busy.
- Make policies explicit. Definition of Done for each column; pull rules.
- Implement feedback loops. Replenishment, daily stand-ups, service delivery review.
- Improve collaboratively, evolve experimentally. Change small, measure, keep what works.
The Kanban Board
| Backlog | Ready | In Dev (WIP=3) | Review (WIP=2) | Done |
|---------|-------|----------------|----------------|------|
| ... | A | B | D | F |
| ... | C | | E | |Cards move left to right. WIP limits constrain how many items each column may hold. When Review is full, no new card can enter Review — and therefore no card can leave In Dev.
WIP Limits
The most counter-intuitive Kanban practice. Why limit work in progress?
- Reduce context switching. Splitting attention across 8 items is slower than finishing 3 sequentially.
- Surface bottlenecks. If Review keeps filling up, the bottleneck is reviewers, not developers.
- Force prioritisation. When WIP is full, the team has to decide what to finish before starting more.
- Improve flow. Lower WIP correlates with shorter cycle time.
Setting limits: start with team size or 1.5x team size; tighten until pain is visible; loosen one notch.
Pull, Not Push
In Scrum, the team commits to a Sprint Backlog up front. In Kanban, the team pulls the next-highest-priority item when capacity opens. There is no commitment to specific items by date — only to flow rates.
Core Metrics
| Metric | Definition | Use |
|---|---|---|
| Cycle time | Time from "started" to "done" per item | How fast items flow |
| Lead time | Time from "requested" to "done" | What customers experience |
| Throughput | Items completed per time window | Capacity |
| WIP | Items in progress right now | Bottleneck signal |
Little's Law connects them: Cycle time = WIP / Throughput. If you halve WIP and keep throughput, cycle time halves.
Cumulative Flow Diagram
Stacked area chart showing items in each state over time. Reveals:
- Bands widening = WIP growing in that state, possible bottleneck.
- Flat band = nothing moving, blocked.
- Sudden jump = batch arrival, smoothing problem.
One of the most useful charts in operational Agile.
Service Classes
Not all work is equal. Common Kanban service classes:
- Expedite. Critical issue, jump the queue, special swimlane, WIP-1 always reserved.
- Fixed date. Hard deadline; goes ahead of standard work as the date approaches.
- Standard. Default; pulled in priority order.
- Intangible. Tech debt, exploratory work; pulled when other classes do not need capacity.
Service classes give explicit policies for the trade-offs the team makes informally anyway.
Replenishment Meeting
Kanban's lighter answer to Sprint Planning. The team and Product Owner regularly (often weekly) review the upcoming queue and pull a small batch of items into "Ready." That keeps the front of the board fresh without committing to a Sprint Goal.
When Kanban Beats Scrum
- Operations and support teams with unpredictable arrivals.
- Mature teams where Scrum events feel ceremonial.
- Teams under continuous pressure that cannot afford a Sprint Goal lock-in.
- Multi-team coordination where flow matters more than sync points.
When Scrum Beats Kanban
- New product teams that need a clear cadence to learn.
- Teams where stakeholders expect predictable demos.
- Work where a Sprint Goal genuinely focuses effort.
- Cultures that want explicit roles and ceremonies as guard rails.
Scrumban
Most teams blend the two. Common patterns:
- Scrum cadence + WIP limits. Sprint structure stays; columns get caps.
- Kanban board for support work + Scrum for feature work. Two streams, different policies.
- Drop the Sprint Backlog commitment but keep the events. Plan a Sprint Goal; pull items as capacity opens.
The label "Scrumban" matters less than asking: what gives focus, and what controls flow? Use whichever practices answer those questions.
Cert Mapping
| Cert | Scope |
|---|---|
| PSM I | Mentions Kanban as an alternative; not deeply tested |
| PMI-ACP | Kanban and lean are core exam content |
| Kanban Management Professional (KMP) | Dedicated cert |
The next lesson covers what to do when one team is not enough — scaling Agile.