Scrumban

Scrumban blends Scrum and Kanban into one flexible approach. Teams keep the roles and rhythm they like from Scrum and add the visual flow and work limits of Kanban. The method began as a way to move teams from Scrum to Kanban and grew into a lasting choice for teams with unpredictable work.

Why Scrumban Exists

Scrum works well when a team can plan a fixed amount of work for two weeks. Some teams cannot. A support team receives urgent tickets all day. A maintenance team fixes bugs that arrive without warning. Fixed Sprints frustrate these teams because plans break within hours. Scrumban removes the fixed Sprint commitment and keeps the helpful structure around the work.

What Scrumban Borrows

A Scrumban Board

The board resembles a Kanban board with extra planning signals. A buffer column holds items that the team has refined and is ready to pull. A trigger rule tells the team when to plan again.

 Backlog | Ready (max 5) | Doing (max 3) | Review (max 2) | Done
 --------+---------------+---------------+----------------+------
  [ H ]  |    [ A ]      |     [ D ]     |     [ F ]      | [ I ]
  [ I ]  |    [ B ]      |     [ E ]     |                | [ J ]
  [ J ]  |    [ C ]      |               |                |
  ...    |               |               |                |

 Planning trigger: when Ready drops to 2 items, refill to 5

On-Demand Planning

Scrum plans once per Sprint. Scrumban plans whenever a trigger fires. A common trigger fires when the Ready column falls below a set number. The Product Owner and team meet briefly, pick the next items, and fill the column. Planning takes minutes instead of hours because the team works in small portions.

Example: Online Store Support Team

A five-person team supports an online store. Tickets range from password resets to payment failures. The team sets a limit of three active tickets per person pair and creates a fast lane for urgent issues. The Ready column holds five tickets. Every Monday the team reviews the oldest tickets and archives stale ones. Every two weeks the team runs a Retrospective. After two months, average ticket time drops from six days to three because limits prevent overload and the board exposes slow steps.

Key Rules to Start

1. Draw the current workflow as board columns.
2. Set a limit for every active column.
3. Choose a planning trigger.
4. Pick a regular review cadence, such as every two weeks.
5. Track cycle time for each item.
6. Inspect the data in every Retrospective and adjust limits.

Roles in Scrumban

Scrumban does not require new roles. Many teams keep a Product Owner who orders the backlog and a Scrum Master or coach who helps with flow. Other teams share these duties among members. The team chooses what fits.

Metrics Worth Watching

• Cycle time shows how long an item takes from start to finish.
• Throughput shows how many items finish per week.
• Blocked time shows where delays occur.
• Age of work in progress highlights items at risk.

When Scrumban Fits

• Work arrives unpredictably.
• Priorities shift within days.
• The team maintains a live product.
• Fixed Sprints cause constant plan changes.

When to Stay With Scrum

Teams that build new products with clear goals benefit from Sprint Goals and a firm time-box. The shared deadline creates focus and a natural moment to inspect results. A team that senses its Sprints work well gains little from switching.

Common Pitfalls

Some teams adopt Scrumban and drop all discipline. Missing limits lead to overloaded boards. Skipped Retrospectives stop improvement. Keep the few rules that matter and review them regularly. Scrumban rewards teams that measure honestly and adapt.