You've committed to a Sprint Goal. The team agreed on the stories, the points make sense, and everyone's calendars are blocked. Then, on Day 3, production goes down.
Welcome to the most common Scrum failure mode in teams that support live software.
Learning Objectives
- Understand why unplanned work is structurally incompatible with standard Scrum sprints
- Describe how Scrumban emerged as a response to this tension
- Identify the warning signs that a team needs a hybrid approach
The Anatomy of a Disrupted Sprint
A classic Scrum sprint works beautifully for one reason: it creates a protected container for focused work. The Sprint Goal, once committed, should shield the team from new requests until the sprint ends.
The problem is that software in production doesn't read the Scrum Guide.
Three categories of work that break sprint commitments:
| Type | Example | Impact |
|---|---|---|
| Production bugs | Critical login failure | Drop everything — sprint goal abandoned |
| Support escalations | Enterprise client can't generate reports | Team split between sprint and support |
| Urgent business requests | CEO saw a competitor feature yesterday | New "priority 0" appears from nowhere |
When these arrive mid-sprint, teams typically face a lose-lose choice:
- Ignore it → business and clients suffer, trust erodes
- Absorb it → sprint goal is missed, velocity is unpredictable, team is demoralised
Where Scrumban Comes From
Scrumban was coined by Corey Ladas in a 2008 blog post titled "Scrum-ban." The core insight was simple: Kanban's flow-based thinking can complement Scrum's time-boxing, rather than replace it.
The name is not officially trademarked or governed by a body — unlike Scrum or Kanban — which makes "Scrumban" a loose term that different teams interpret differently. That's actually part of its appeal: it's a hybrid philosophy, not a framework with fixed rules.
What Scrumban preserves from Scrum:
- Sprint cadence (time-boxing)
- Team ceremonies (Planning, Review, Retrospective)
- Sprint Goal and backlog concept
What Scrumban borrows from Kanban:
- Visualised workflow with explicit states
- Work-in-Progress (WIP) limits
- Continuous flow for unplanned work
- Pull-based work assignment
When to Consider Going Scrumban
A team might need a Scrumban approach if they observe:
- Sprint goals are missed regularly despite the team working hard — the work that disrupts is consistently more urgent than the work that was planned
- Support capacity is unpredictable — some weeks it's 10% of effort, some weeks it's 80%
- The team has a dual mandate — they own both new feature development AND live system support
- Developers feel guilty about "protecting the sprint" — they know the external pressure is real
Pro Tip: If your team holds a retrospective and the word "interruptions" appears on the board every single time, that's a signal — not a coincidence. The process isn't matching the team's actual workflow.
The Scrum Purist's Objection
It's worth acknowledging the purist's counterargument: "Fix the organisation, not the process. Stop letting people interrupt the sprint."
This is technically correct and practically difficult. Sprint protection requires executive buy-in, a mature product organisation, and a culture that respects team commitments. Many teams don't have all three. Scrumban is often the pragmatic middle ground while those conditions are being built.
Summary
- Scrum's sprint commitment creates a tension with live production support
- This tension manifests as missed sprint goals, demoralised teams, and unpredictable velocity
- Scrumban blends Scrum's time-boxing with Kanban's flow to create a process that acknowledges both planned and unplanned work
- It's not a silver bullet — but it's a better map for teams whose territory is messy