Kanban
Kanban is a method for managing flow: visualize work, limit work in progress (WIP), manage flow, make policies explicit, implement feedback loops, and improve collaboratively. Unlike Scrum, Kanban does not prescribe sprints or fixed roles — it evolves your current process.
Architecture and platform teams, SRE queues, and product teams with interrupt-driven work often prefer Kanban because arrival rates are uneven and artificially forcing sprint batches adds wait time without adding learning.
info
Visualize the workflow
Columns reflect real states (Ready, In progress, Review, Verify, Done). Make blocked items visible. Include expedite lanes sparingly.
Limit WIP
Cap items per column or per person. WIP limits expose bottlenecks and force finishing over starting.
Manage flow
Watch queue times; swarm on blockers; balance demand vs capacity.
Make policies explicit
Entry/exit criteria per column; DoD; expedite policy; dependency handling.
Feedback loops
Daily standups focused on flow; replenishment meetings; delivery reviews; operations reviews.
Improve experimentally
Change one policy at a time; measure lead time impact.
Why limit WIP: multitasking destroys throughput and increases cycle time; unfinished work is inventory risk. How: start with current WIP, set a slightly lower limit, and tighten as flow stabilizes. When a column is full, help downstream or upstream instead of pulling more.
| Symptom | Likely cause | Kanban response |
|---|---|---|
| Many items 'almost done' | No WIP limit / weak DoD | Tighten WIP; strengthen exit criteria |
| Review column forever | Reviewer bottleneck | Limit review WIP; pair; swarm |
| Constant expedites | Priority chaos | Explicit expedite policy + capacity reserve |
| Long wait in Ready | Overstuffed backlog | Replenish based on capacity, not hope |
best practice
| Metric | Meaning | Use |
|---|---|---|
| Lead time | Request → Done | Customer-facing expectation |
| Cycle time | Start → Done | Process efficiency |
| Throughput | Items Done per time | Capacity planning |
| WIP | Items in progress | Control knob |
| Aging WIP | How long current items have aged | Predict breaches early |
Plot cycle time scatterplots and percentiles (p50/p85) rather than averages alone. Use aging WIP charts in standups to spot items going stale.
| 1 | Ready → In progress: AC clear, deps known, WIP allows pull |
| 2 | In progress → Review: tests green locally, AC self-checked |
| 3 | Review → Verify: approved diff, fitness checks pass |
| 4 | Verify → Done: DoD met, observability OK, rolled forward/back plan noted |
| Aspect | Kanban | Scrum |
|---|---|---|
| Cadence | Continuous; optional meetings | Fixed sprints + events |
| Commitment | Service level expectations | Sprint goal / forecast |
| Roles | None prescribed | PO, SM, Developers |
| Change | Add anytime under WIP rules | Mid-sprint change discouraged |
| Best for | Flow/ops/mixed work | Product increments + demos |
Teams can combine: Scrumban uses sprint cadence for planning/reviews with Kanban WIP limits inside the sprint. Choose deliberately — do not accumulate ceremonies from both without purpose.
- Interrupt-driven work (support, SRE, security response).
- Platform teams serving many consumers with uneven demand.
- Maintenance and modernization backlogs mixed with small features.
- Teams graduating from Scrum who find sprint boundaries artificial.
- Need to improve an existing process without a big-bang framework swap.
| Requirement / constraint | Kanban implication |
|---|---|
| Unpredictable arrival rate | Pull system + WIP beats batch sprints |
| Need stakeholder demo cadence | Add review meeting; or prefer Scrum |
| Regulatory release trains | Kanban build + gated release packages |
| Many small tickets | Classes of service (standard/expedite/fixed date) |
Kanban surfaces architectural friction as flow problems: review bottlenecks from unclear ownership, long cycle times from tangled modules, expedites from missing feature flags. Use metrics as inputs to architecture enablers on the backlog.
note
- Board mirrors org chart fantasy, not real workflow.
- No WIP limits — Kanban wallpaper.
- Measuring utilization instead of lead time.
- Unlimited expedite lane that destroys flow.
- Ignoring blocked items because they are 'someone else's problem'.
Start from your current process (Kanban principle: start with what you do now):
- Map the real workflow — include waiting states.
- Put all WIP on the board — stop invisible work.
- Set initial WIP limits slightly below current WIP.
- Agree policies for expedite and blocked items.
- Measure lead time for two weeks before major policy changes.
- Run a weekly replenishment meeting with clear capacity.
Classes of service
Standard, expedite, fixed-date, intangible (debt). Allocate capacity percentages so expedites cannot consume the whole system.
Service level expectation
e.g., 85% of standard items Done within 5 days — use for forecasting, not blame.
pro tip
| 1 | Backlog | Ready(WIP5) | Dev(WIP3) | Review(WIP2) | Verify(WIP2) | Done |
| 2 | |
| 3 | Expedite: max 1 system-wide; requires named approver |
| 4 | Blocked: orange tag + owner + age alert at 48h |
| 5 | Bug vs Feature: same board; type label for metrics |
Kanban does not remove requirements, design, or testing — it visualizes them as states or as item types. A design spike can be a card with its own exit criteria; a compliance verification can be a column before Done.
Once you have cycle time history, forecast delivery with percentile-based ranges instead of single-point estimates. Monte Carlo simulation on past throughput is a common Kanban practice for "when will this epic finish?" answers.
Community
Get help on Slack, Discord or VIP
Stuck on a guide? Join the community and ask.