Let me settle this debate once and for all: Scrum and Kanban are not competitors. This isn't a religious war. They address different aspects of how teams deliver value, and the smartest teams use both.
Scrum gives you the structure — roles, events, artefacts — that creates cadence, accountability, and inspect-and-adapt loops. Kanban gives you the flow management practices — visualisation, WIP limits, metrics — that make the work itself move faster and more predictably.
Using Scrum without Kanban is like having a great schedule but no map. You know when the meetings are, but you can't see where the work is getting stuck.
WIP Limits in Sprint
The Sprint itself is a WIP limit — it constrains how much work the team commits to in a time period. But within the Sprint, most teams have no limits at all. Every developer picks up a new item, and by mid-Sprint you've got 8 items in progress, all at 50%, and nothing finished.
Add WIP limits within the Sprint. For a team of 5 developers, limit work in progress to 3-4 items. When someone finishes their item, they either help someone else finish theirs (swarming) or pull the next item. The effect is dramatic: items finish sooner, feedback comes faster, and the end-of-sprint scramble disappears.
Try this experiment: in your next Sprint, set a WIP limit of "number of developers minus one." Track how many items are done by mid-Sprint compared to your usual pattern. I've seen teams double their mid-Sprint completion rate with this single change.
Flow Metrics Alongside Velocity
Velocity tells you how much the team completed in a Sprint. That's useful for capacity planning but tells you nothing about how work flowed. Adding flow metrics gives you a much richer picture:
- Cycle time: How long does an item take from "in progress" to "done"? If your cycle time is 8 days but your Sprint is 10 days, items are spending almost the entire Sprint in progress. That's a signal to investigate.
- Throughput: How many items complete per week (not per Sprint)? Weekly throughput shows you patterns that Sprint-level velocity hides — like the mid-Sprint lull where nothing finishes.
- Work item aging: How long has each in-progress item been in progress? Aging items are your early warning system. If an item has been in progress for 6 days and your 85th percentile cycle time is 5 days, that item needs attention now — not at the end of the Sprint.
- Flow efficiency: What percentage of an item's cycle time is active work vs. waiting? Most teams are shocked to discover that items spend 70-80% of their cycle time waiting — for review, for testing, for deployment, for someone to answer a question.
Visualising Work Beyond the Sprint Board
Most Sprint boards show a simplified view: To Do, In Progress, Done. That's not enough. Effective visualisation includes:
- Explicit workflow states: Break "In Progress" into its real steps — development, code review, testing, staging, deployment. Each stage where work can wait is a stage you can optimise.
- Blocked items: Make blockers visually screaming. A blocked item is a WIP zombie — it consumes capacity without delivering value. It should be visible and it should create urgency.
- Upstream work: The Sprint Board only shows committed work. But there's an entire upstream flow — discovery, analysis, refinement — where work often gets stuck before it ever enters a Sprint. Visualise this too.
- Policies: Make your policies explicit on the board. What does "ready for review" mean? What's the WIP limit for testing? When should someone swarm on a stuck item? Written policies prevent the daily debate about how things should work.
Practical Tips for Scrum Teams
- Start with visualisation. Before adding WIP limits or metrics, just map your actual workflow. Most teams discover steps they didn't know existed.
- Add one metric at a time. Start with cycle time. Just measure it for a few Sprints. The patterns will tell you what to improve.
- Use the Daily Scrum for flow. Instead of "what did you do yesterday?", try "what's aging? What's blocked? Where should we swarm?"
- Bring flow data to retrospectives. "Our average cycle time increased by 2 days this Sprint" is a better starting point for improvement than "things felt slow."
- Don't ask permission. Nothing in the Scrum Guide prevents you from using Kanban practices. They're additive. Just start.
Scrum gives you the rhythm. Kanban gives you the visibility. Together, they give you a team that delivers predictably and improves continuously.
Want to build deep flow intuition for your Scrum team? Our Mastering Kanban interactive lab teaches you the flow principles that make any framework work better — through simulation and hands-on experimentation, not theory.