You understand the theory. Now let's build something. A Scrumban setup isn't a revolution — it's an evolution of your existing Scrum process. The goal is to make your board smarter, not throw away what's working.
Learning Objectives
- Design a Scrumban board with appropriate columns and WIP limits
- Distinguish between sprint backlog items and continuous flow items
- Explain trigger-based planning and when it replaces or supplements Sprint Planning
- Describe how to handle urgent work without abandoning the sprint goal
The Scrumban Board
A typical Scrumban board extends the standard Scrum sprint board with explicit flow stages and WIP limits. The board has two horizontal swim lanes — one for committed sprint work, one for continuous support flow — sharing the same WIP-limited columns:
┌─────────┬───────┬─────────────┬───────────┬────────────┬──────┐
│ BACKLOG │ READY │ IN PROGRESS │ IN REVIEW │ IN TESTING │ DONE │
│ │ WIP:3 │ WIP:4 │ WIP:2 │ WIP:3 │ │
├─────────┼───────┼─────────────┼───────────┼────────────┼──────┤
│ Sprint │ │ │ │ │ │
│ Stories │ │ │ │ │ │ ← Sprint lane
├─────────┼───────┼─────────────┼───────────┼────────────┼──────┤
│ Support │ │ │ │ │ │
│ Items │ │ │ │ │ │ ← Flow lane
└─────────┴───────┴─────────────┴───────────┴────────────┴──────┘
Both lanes share the WIP limits — filling the flow lane with urgent work directly competes with sprint stories for the same column capacity.
The column breakdown in detail:
| Column | WIP Limit | What enters here |
|---|---|---|
| Backlog | — | Sprint stories (at Planning) + support items (anytime) |
| Ready | 3 | Items groomed and ready to pull |
| In Progress | 4 | Active development work |
| In Review | 2 | Awaiting code review |
| In Testing | 3 | Awaiting QA sign-off |
| Done | — | Completed items |
Two swim lanes (rows):
- Sprint lane: planned sprint stories — committed to the sprint goal
- Support/Flow lane: production bugs, urgent requests, unplanned work — governed by WIP limits
Key design decisions:
- WIP limits apply to the entire column (both lanes combined) — this forces explicit prioritisation when unplanned work arrives
- Support items can enter the board at any time; sprint stories enter only at Sprint Planning
- The Sprint Goal is tied to the sprint lane only — support work doesn't threaten it
Trigger-Based Planning
Standard Scrum plans work at a fixed interval: every sprint. Scrumban introduces trigger-based planning: the team re-plans the backlog when a condition is met, not just when the calendar says so.
Common triggers:
- WIP trigger: when the "Ready" column drops below a threshold (e.g., fewer than 3 items), the team pulls from the backlog to refill
- Backlog size trigger: when the sprint backlog has fewer than N items remaining, a mini-planning session occurs
- Emergency trigger: a production P1 incident triggers an immediate decision: who handles it, and what gets deprioritised?
The Emergency trigger is the most important one for QA. When a P1 hits:
- The incident is added to the support lane immediately (bypassing normal flow)
- The team lead or Scrum Master makes an explicit decision about who's pulled from sprint work
- That decision is visible on the board — the sprint story goes back to "Ready", the engineer moves to the incident
- The Sprint Goal is re-assessed at the next Daily Scrum
This transparency is key. In traditional Scrum, a P1 often causes invisible disruption — developers switch context without the team knowing, and the sprint "mysteriously" misses its goal. In Scrumban, the impact is explicit and acknowledged.
Sizing and Classifying Work
Scrumban typically uses two different sizing approaches for its two types of work:
Sprint stories: sized in story points (standard Scrum) or effort hours. These are relatively predictable — they've been refined in backlog grooming.
Support items: classified by service class (a Kanban concept), not sized. Service classes define how the item flows through the board:
| Service Class | Example | Flow policy |
|---|---|---|
| Expedite | Production outage | Bypass all WIP limits, fix immediately |
| Fixed Date | Compliance deadline | Must reach Done by date X |
| Standard | Normal bug fix | FIFO through the board |
| Intangible | Tech debt, refactoring | Pulled only when sprint lane has capacity |
Pro Tip for QA: The "Expedite" class is a powerful tool and a dangerous one. When everything is expedite, nothing is. Your job as a QA is to challenge expedite classifications that don't meet the bar — a P2 bug is not a P1, no matter how upset the account manager is.
The Retrospective in Scrumban
The sprint retrospective remains intact in Scrumban. But it gets an additional data point: flow metrics.
In addition to the standard "what went well / what went wrong" discussion, a Scrumban retrospective reviews:
- How many support items entered the board this sprint vs. last sprint?
- What was the average time a support item sat in "Ready" before being picked up?
- Did any sprint stories get permanently blocked by support work?
These metrics tell you whether your Scrumban setup is working or whether the support lane is quietly eating the sprint lane.
When to Abandon Scrumban
Scrumban is a transitional or situational process. It's not a destination. Teams that successfully reduce their unplanned work (better monitoring, better on-call processes, better code quality) may find they can return to pure Scrum. Teams that find support work is >50% of their capacity consistently should ask whether they should flip to pure Kanban.
Summary
- A Scrumban board uses swim lanes to separate sprint commitments from continuous flow work
- WIP limits apply across both lanes, forcing visible tradeoffs when unplanned work arrives
- Trigger-based planning refills the backlog based on conditions, not just calendar
- Service classes classify support work by urgency and flow policy
- Flow metrics in retrospectives reveal whether the hybrid is working