Scrum gives you focus and cadence. Kanban adds flow and predictability. Used together, you can deliver more steadily without changing Scrum’s roles, events, or artifacts. This guide shows exactly how to layer Kanban practices into your existing Scrum setup to visualize flow, limit WIP, and actively manage aging work—plus a 4-week pilot plan and clear success criteria.
Why add Kanban to Scrum?
- Smoother delivery: reduce end-of-sprint spikes and half-done work.
- Predictability: make cycle times measurable and stable.
- Transparency: see bottlenecks in minutes, not retros later.
- Better focus: WIP limits force finishing before starting.
The Kanban Guide for Scrum Teams explicitly positions Kanban as an enhancement to Scrum, not a replacement. You keep Scrum; you optimize its flow. Scrum.org+1
The 20% that drives 80% of the impact
- Visualize the Sprint Backlog as a workflow
Make work states explicit (e.g., To Do → In Progress → Review → Done). Add lanes or tags for classes of service (e.g., Standard, Expedite). Keep columns limited to real states you actually use. This creates instant transparency and shared language for flow. Scrum.org - Set smart WIP limits—then defend them
Start with WIP ≈ number of active developers for your core “In Progress” states and tune weekly. If you regularly hit the limit, swarm to finish items rather than starting new ones. Tie this to Little’s Law to communicate why lower WIP shortens cycle time and boosts predictability. Scrum.org+1 - Actively manage work item aging
Track the age of each in-progress item and compare it to your historical cycle-time percentiles. Anything aging past the 70th–85th percentile is a risk—swarm, unblock, or split it. Aging gives you a daily early-warning system. knowledgebase.businessmap.io+1 - Make flow policies explicit
Define entry/exit criteria for each column (Definition of “Ready for Review”, test evidence required, etc.), a blocking policy (how to mark, who unblocks), and service-class rules (what qualifies as Expedite and how to use it sparingly). Keep policies short and visible on the board. Scrum.org
How the practices fit inside Scrum events
- Sprint Planning: Forecast with throughput and recent cycle-time data. Select fewer, finish more. Use WIP limits to keep the plan realistic. Scrum.org
- Daily Scrum: Walk the board right to left. Discuss aging/blocked items first. Ask, “What helps the most items move to Done today?”
- Sprint Review: Include a 2-minute flow highlight (throughput, cycle-time trend, WIP breaches) alongside product outcomes.
- Retrospective: Pick one flow experiment (e.g., reduce Review WIP from 3→2 for a sprint).
- Backlog Refinement: Split large items until they fit within your typical cycle-time band. Tag risks that might age (integration, external approvals).
Designing your Kanban board (for a Scrum Team)
Columns (example):
Backlog → Selected (Sprint Backlog) → In Progress → Review/Test → Ready to Release → Done
Board conventions
- Avatars or owner tags to avoid silent multitasking.
- Blocked flag with reason code (Dependency, Environment, Waiting on PO).
- Aging indicator (e.g., dot/day or color heatmap) so stale work pops visually. knowledgebase.businessmap.io
WIP limits to start
- In Progress: team size (e.g., 5 people → WIP 5).
- Review/Test: half the team size (encourages finishing).
- System WIP: sum of all in-progress states ≤ team size + 1 buffer.
Reassess weekly based on where aging/queues occur.
Core metrics to track (and how to use them)
- Throughput (items finished per sprint/week): use for short-term forecasting.
- Cycle time (start → finish per item): aim for tighter spread and lower median.
- WIP (items in progress now): keep within limits to maintain predictability.
Little’s Law connects them: WIP ≈ Throughput × Cycle Time. Use this to explain why “starting more” slows you down. Scrum.org+1 - Aging WIP: today’s in-progress items plotted against your cycle-time bands. Anything beyond the 85th percentile needs swarming or splitting today. knowledgebase.businessmap.io
4-Week pilot plan (no org change required)
Goal: Stabilize flow and shorten cycle time within Scrum.
Week 1 — Instrument & visualize
- Build/adjust your board with clear states and policies.
- Set initial WIP limits.
- Start capturing start/finish times per item (your tool likely does this).
- Establish an Aging WIP view or daily export for a quick chart. knowledgebase.businessmap.io
- Daily Scrum: walk right-to-left, prioritize finishing and unblocking.
Week 2 — Enforce limits & manage aging
- Hold the line on WIP. When a column is full, swarm—don’t start new work.
- Introduce visible blocked markers and an escalation policy.
- Add an aging threshold: anything past your current 70th percentile gets extra attention (pairing, PO availability, or splitting).
- Retro: pick one experiment (e.g., lower Review WIP by 1).
Week 3 — Tighten predictability
- Start each day by reviewing items above the aging threshold.
- Split oversized items mid-flow if they stall; keep value increments independently releasable.
- Use a small Expedite class only when time critical and capacity exists; limit to one at a time.
- Share a mini flow report in Sprint Review (throughput, cycle-time trend).
Week 4 — Tune & institutionalize
- Recalibrate WIP where queues persist.
- Document the 3–5 explicit policies that truly matter and keep them visible on the board.
- Create a team flow playbook: how you forecast with throughput, how you react to aging, when to split, when to swarm.
- Agree on next sprint’s single flow experiment (continuous improvement over one-off “fixes”).
Success criteria (decide these upfront)
Pick targets appropriate for your baseline; examples:
- Cycle time: median down 20–30%; 85th percentile down 15–20%.
- Predictability: 85% of items finish within the stated SLA band (e.g., 8 working days).
- Throughput: more finished items per sprint with the same team and scope profile.
- WIP discipline: <5% of days with WIP breaches after Week 2.
- Aging control: ≤10% of items exceed the 85th percentile band by Sprint end.
- Quality: escaped defect rate stable or better (flow should not trade off quality).
These outcomes align with Kanban’s intent inside Scrum: optimizing flow through existing feedback loops—without altering Scrum’s definition. Scrum.org
Common pitfalls (and quick fixes)
- Too many columns → Collapse to real states you actively manage.
- Invisible policies → Pin them to the board; keep them short.
- Ignoring aging → Make the aging chart part of Daily Scrum. knowledgebase.businessmap.io
- WIP limits as “suggestions” → Treat breaches as blockers; swarm first, then consider tuning limits.
- Over-expediting → One expedite at a time, explicit entry criteria, and a post-mortem.
Tools, further reading, and next steps
- Kanban Guide for Scrum Teams (Scrum.org) — the official “how to” for adding Kanban to Scrum. Scrum.org+1
- Little’s Law explained for Scrum + Kanban (Scrum.org) — why WIP limits matter for predictability. Scrum.org
- Aging WIP Chart (Businessmap guide) — practical visuals to manage aging daily. knowledgebase.businessmap.io
If you want hands-on guidance applying this on your team, explore my Kanban and Scrum programs:
- Kanban Program — https://igorlakic.com/agile-coaching/kanban/ igorlakic.com
- Scrum Program — https://igorlakic.com/agile-coaching/scrum/ igorlakic.com
- Lakic Agile Academy — workshops and coaching for real-world flow improvement: https://igorlakic.com/lakic-agile-academy/ igorlakic.com
- Or connect directly: https://igorlakic.com/contact/
Copy-paste starter: explicit flow policies (template)
- WIP limits: In Progress = N; Review/Test = N/2 (rounded up).
- Blocked: Mark with 🚫 + reason; product/tech lead escalates within 24h.
- Aging: Items older than the 70th percentile get pairing; older than 85th → swarm/split decision.
- Definition of Done: code merged, tests passed, acceptance verified, ready to release.
- Expedite: One item max; product lead approves; post-mortem in Retro.
