Scrumban Explained: How to Combine Scrum and Kanban

Scrumban is a hybrid approach that combines ideas from Scrum and Kanban. Some teams use it as a stepping stone from one to the other; others use it permanently because it suits their mix of planned and unplanned work. Because there is no official Scrumban guide, the word means different things to different teams. This article explains where Scrumban comes from, what it usually includes, when it works well and how to adopt it without losing the discipline that makes Scrum and Kanban effective.

Key takeaways

• The term Scrumban was popularised by Corey Ladas in his 2009 book on Kanban systems for software development.
• There is no official Scrumban guide, so practices vary widely between teams.
• Scrumban typically combines Scrum-style planning, review and retrospectives with Kanban-style WIP limits, pull and flow metrics.
• It suits teams with a mix of planned work and unpredictable requests, such as product development plus support.
• If a team drops parts of Scrum, it is no longer doing Scrum as the Scrum Guide defines it; clarity about what you actually do matters.

Where Scrumban comes from

Corey Ladas introduced the idea in writing in the late 2000s, and his 2009 book Scrumban: Essays on Kanban Systems for Lean Software Development popularised the term. He originally described Scrumban as a way for Scrum teams to evolve towards a Kanban system by gradually adding Lean ideas such as pull, WIP limits and flow.

Over time, the word has come to describe a wider range of hybrids. Some teams use it for Scrum with added Kanban practices; others for Kanban with some Scrum events. Neither Scrum nor Kanban has an official Scrumban definition, so it is worth being explicit about what your team means by it.

For background on the two approaches, see our complete Kanban guide and Kanban vs Scrum.

What Scrumban usually includes

Because practices vary, the following is a description of common patterns rather than rules:

• A Kanban board with WIP limits. Work is visualised and limited, as in Kanban.
• Pull instead of push. Team members pull new work when they have capacity.
• Planning on demand. Instead of planning a fixed amount at the start of a Sprint, some teams refill the "Ready" column whenever it drops below an agreed level.
• Optional or flexible iterations. Some Scrumban teams keep regular iterations for reviews and retrospectives; others work continuously.
• Regular reviews and retrospectives. Borrowed from Scrum, these keep inspection and improvement regular.
• A short daily meeting. Often focused on the board and flow rather than individual updates.
• Flow metrics. Cycle time and throughput, rather than or alongside velocity.
• Roles kept as needed. Some teams keep a Product Owner and Scrum Master; others keep existing roles.

Bucket-size planning

Ladas also described a longer-term planning approach often called bucket-size planning. Ideas sit in "buckets" by horizon, for example one year, six months and three months, and move into nearer buckets as they are refined and approved, until they are ready to be pulled into work. It gives a lightweight way to connect long-term ideas with day-to-day flow.

Scrum vs Kanban vs Scrumban

	Scrum	Kanban	Scrumban (typical)
Defined by	The Scrum Guide	The Kanban Method and the Kanban Guide	No official definition
Iterations	Sprints of one month or less	None; continuous flow	Optional; often used for reviews and retrospectives
Roles	Scrum Master, Product Owner, Developers	None required	Kept as needed
Limiting work	Through Sprint selection	Explicit WIP limits	Explicit WIP limits
Planning	Sprint Planning each Sprint	Replenishment when capacity allows	Often planning on demand
Changes during work	No changes that endanger the Sprint Goal	New work can start when capacity allows	Usually flexible, within WIP limits
Key metrics	Sprint Goal, Increments, often velocity	Cycle time, throughput, WIP, work item age	Usually flow metrics

When Scrumban works well

• Mixed work: teams that build new features and also handle support or maintenance requests.
• Frequently changing priorities: where waiting for the next Sprint to start new work is too slow.
• Teams moving between approaches: a Scrum team adopting flow practices, or a Kanban team adding regular reviews.
• Maintenance phases: products with fewer large features and more small, steady changes.

When it may not be the right choice

• When a team is new to Agile and needs the clear structure of a defined framework.
• When "Scrumban" is used to avoid the discipline of either approach, such as dropping retrospectives or ignoring WIP limits.
• When stakeholders need the predictable rhythm of Sprint Reviews and the team has no alternative way to provide it.

A note on Scrum and hybrids

The Scrum Guide states that the Scrum framework is immutable: while implementing only parts of Scrum is possible, the result is not Scrum. Many Scrum Teams add Kanban practices, such as WIP limits and flow metrics, while keeping all of Scrum's accountabilities, events and artifacts; that is still Scrum. If a team removes Sprints, accountabilities or events, it is doing something else, which may well be effective, but should be described honestly. Clear language helps everyone, including stakeholders and new team members, understand how the team actually works.

How to adopt Scrumban, step by step

1. Start with what you do now. Describe your current process honestly, whether it is Scrum, Kanban or something informal.
2. Make the work visible. Put all work, planned and unplanned, on one board.
3. Add WIP limits. Start near today's level and lower them gradually. See WIP limits explained.
4. Decide how planning works. Keep regular planning, move to planning on demand, or combine both. Write the rule down.
5. Keep regular inspection. Hold reviews with stakeholders and retrospectives at a steady rhythm, even if you work continuously.
6. Measure flow. Track cycle time and throughput. See Kanban metrics explained.
7. Agree roles. Decide who orders the work and who helps the team improve. Many teams keep a Product Owner and Scrum Master for this.
8. Review and evolve. Treat your process as something to inspect and adapt, one change at a time.

An example Scrumban setup

As an illustration, a product team that also handles customer issues might work like this:

• One board with columns Ready, In progress, Review, Testing and Done, with WIP limits on each in-progress column.
• An expedite lane for urgent customer issues, limited to one item.
• The Product Owner keeps the Ready column ordered and refills it whenever it drops below five items.
• A 15-minute daily meeting at the board, walking from right to left.
• A review with stakeholders and a retrospective every two weeks.
• Cycle time and throughput reviewed at each retrospective.

A worked example: from Scrum to Scrumban

As an illustration, imagine a Scrum Team that builds a product and also receives a steady stream of customer issues. Urgent issues keep disrupting the Sprint, and the team often ends Sprints with many items almost done. Over a few months, it might evolve like this:

• Month 1: the team keeps Scrum as it is but adds WIP limits to its Sprint board and starts recording cycle times. Fewer items are left half-finished at the end of Sprints.
• Month 2: the team adds an expedite lane for urgent customer issues, limited to one item, and agrees a clear policy for what counts as urgent.
• Month 3: planning a full Sprint up front keeps being overtaken by customer issues, so the team agrees to plan a smaller commitment and refill the Ready column when it drops below a set level. It keeps its two-weekly review and retrospective.
• Month 4: the team reviews its data. Cycle times are shorter and more predictable, and stakeholders still get regular reviews. The team documents its process and calls it Scrumban, making clear that it is no longer following Scrum exactly as the Scrum Guide describes.

Moving from Scrum towards Scrumban

Corey Ladas described Scrumban as an evolutionary path, and that remains the safest way to adopt it. For a Scrum Team, typical steps are:

1. Visualise the Sprint Backlog on a board that shows every stage of work, including waiting.
2. Add WIP limits and start pulling work.
3. Measure cycle time and throughput alongside, or instead of, velocity.
4. Experiment with planning: smaller commitments, or refilling a Ready column on demand.
5. Keep regular reviews and retrospectives so inspection and adaptation continue.

Many teams stop at step three, keeping Scrum intact while benefiting from flow practices. That is a perfectly good outcome.

Moving from Kanban towards Scrumban

Some Kanban teams move in the other direction. They keep continuous flow and WIP limits but add structure borrowed from Scrum:

• A regular review with stakeholders to show results and gather feedback
• A regular retrospective to improve how the team works
• A clear owner for ordering the work, often called a Product Owner
• A short-term goal for each period, similar to a Sprint Goal, to give focus

This can help Kanban teams that feel they lack direction or regular stakeholder contact.

Roles and meetings in Scrumban

Because Scrumban has no official definition, roles and meetings are decisions each team makes. Common choices:

Element	Common Scrumban choice
Ordering the work	A Product Owner or equivalent keeps the Ready column ordered
Improving the process	A Scrum Master, agile coach or team member facilitates improvement
Daily meeting	Around 15 minutes at the board, focused on flow and blocked items
Planning	On demand, or a short regular planning session
Review	Regular, often every one to four weeks, with stakeholders
Retrospective	Regular, often at the same rhythm as the review

Scrum, Kanban or Scrumban? Questions to decide

• How predictable is your work? Mostly planned work suits Scrum; mostly unpredictable work suits Kanban; a mix may suit Scrumban.
• How often do priorities change? If waiting for the next Sprint is too slow, flow-based approaches help.
• How experienced is the team? Newer teams often benefit from the clear structure of Scrum first.
• What do stakeholders need? Regular reviews can be kept in any approach, but must be planned.
• Is the team building a product or providing a service? Products often suit Scrum; services often suit Kanban.
• Are you willing to measure? Kanban and Scrumban rely heavily on flow data.

Scrumban in remote teams

Remote Scrumban teams rely on a single digital board as the source of truth. Clear WIP limits, visible policies and automatic recording of start and finish dates matter even more when people cannot see a physical board. A short daily video call at the board, walking it from right to left, keeps the focus on finishing. Regular online reviews with stakeholders stop feedback from drying up when work flows continuously.

Common mistakes

• Using Scrumban as an excuse. Dropping retrospectives or planning without replacing them with something better usually makes things worse.
• No WIP limits. Without them, Scrumban is just Scrum without Sprints.
• Nobody ordering the work. Pull only works if the most valuable work is at the top.
• Losing stakeholder contact. Without regular reviews, feedback dries up.
• Unclear definitions. If team members describe the process differently, confusion follows. Write it down.

Learn more

For the Scrum side, see our complete Scrum Master guide and the five Scrum events explained. For the Kanban side, see how to set up a Kanban board. If you want to build and demonstrate Kanban skills, Kanban Management in Systems Plus covers flow, WIP limits and flow metrics; the exam is taken online on ExamVault by CertExpert with three attempts included, and the certificate and digital badge are valid for two years.