It can be argued that Kanban is the pursuit of balance. A stable Kanban system is one in which capacity is balanced with demand.
This balance applies to both averages and daily fluctuations. Over time, the average rate at which new work enters the system matches the average rate at which work exits the system (i.e., “Done”). Scrum teams using a Kanban Board can spot and respond to sudden spikes in demand before they derail the Sprint Goal or exceed the Service Level Expectation.
Early warning signs of fluctuations in demand can appear directly on the Kanban Board:
- If the queue (Product Backlog) grows faster than usual.
- If Work Item Aging shows PBIs lingering longer than usual in any column.
- If Work-In-Progress (WIP) limits are breached.
Any of these signals tells the team that demand has begun to outpace current capacity.
The Daily Scrum: Spot and Adapt to Signals
In the Daily Scrum, team members can inspect the Kanban Board for those signals (e.g., rising queue length, aging PBIs, or breached WIP limits). Such signals can prompt them to ask: is the Sprint Goal at risk?
If yes, they can adapt immediately. The team may:
- Swarm on the oldest or most critical aging PBIs to manage flow.
- Stop pulling new work until WIP drops below the agreed-upon limits.
- Or even call for external help, such as pairing with another team or escalating blockers.
These real-time adjustments restore balance, protect the Sprint Goal, and respect the team’s Service Level Expectation (SLE).
Benefits of Blending Kanban into Scrum
I meet many Scrum Teams that manage an impressive variety of work: discovery, UX experiments, architectural improvements, feature implementation, and service requests from other teams. Much of their work is interrupt-driven or, for various good (and bad) reasons, does not fit neatly into Sprint timeboxes.
In such cases, I encourage teams to strive for PBIs small enough to be completed within their Sprint length. (Said another way: strive for an average Cycle Time shorter than the Sprint length.) That way, they can manage flow effectively and feel less anxious about the few PBIs that “carry over” from one Sprint to the next.
Aside: The fact that some types of work require attention beyond one Sprint length (e.g., longitudinal UX research) should not be general permission to avoid splitting Product Backlog Items. Strive for incremental delivery, and be as disciplined as possible in keeping PBIs smaller than a Sprint.
Thus, another kind of balance a Scrum Team must achieve when blending Kanban is to emphasize flow without allowing the size or Cycle Time of PBIs to exceed the Sprint length too often.
Evidence of Success When Blending Kanban with Scrum
- The team achieves predictable delivery: Their Kanban Board can signal overload, allowing the team to adapt and keep cycle times stable while respecting their SLE.
- Sprint Goal protection: Early detection of spikes in demand enables proactive swarming or dependency escalation.
- Sustainable pace: WIP limits reduce multitasking, burnout, and defects.
- Data-driven decisions: Visual metrics (aging, cumulative flow diagrams, and cycle time scatterplots) replace guesswork in Daily Scrum, Review, and Retrospective.
Blend Kanban to make Scrum's empiricism immediate and actionable. Transform fluctuations into controlled flow.