Scrumban: How the Method Works (and Where It Breaks)
Scrumban gets misread the moment it shows up on a team. Most adopters describe it as "Scrum without the rituals," which is the laziest possible reading. The framework was designed as a transition path from Scrum to Kanban, with structural elements (WIP limits, pull-based work, on-demand planning) that the lazy reading drops first.
This guide covers what Scrumban actually is, who created it, the six core practices that distinguish real Scrumban from abandoned Scrum, when it works, and when it is just an excuse to skip ceremonies. The widget below diagnoses which framework actually fits your team's context, since most teams that say they use Scrumban would benefit from picking Scrum or Kanban directly.
Quick answer: what Scrumban is
Scrumban is an agile framework that combines Scrum's structure (short iterations, prioritization, retrospectives) with Kanban's flow practices (WIP limits, pull-based work, continuous flow). Software development consultant Corey Ladas coined the method in his 2009 book Scrumban: Essays on Kanban Systems for Lean Software Development, originally designing it as a transition path for Scrum teams adopting Kanban concepts.
The name is a portmanteau, not a marketing choice. Most popular Scrumban explainers skip the Ladas attribution and describe the method as "the best of both worlds," which obscures the original intent and produces the most common failure mode: teams calling themselves Scrumban after dropping every Scrum ceremony without adopting any Kanban discipline.
If the quiz pointed away from Scrumban, that is a useful result. The framework has a real, narrow zone where it outperforms Scrum and Kanban. Outside that zone, picking one of the parent frameworks directly usually beats hybrid by default.
Origin: Corey Ladas, 2009
Ladas published Scrumban: Essays on Kanban Systems for Lean Software Development through Modus Cooperandi Press in 2009. The book was a collection of essays, not a single methodology specification, and it was written for an audience already running Scrum that wanted to understand Lean and Kanban concepts more easily.
The original framing matters because it changes what counts as the Scrumban methodology. Ladas treated the method as a bridge: Scrum teams keep the iteration rhythm and prioritization discipline they have built, then incrementally adopt Kanban's flow controls (WIP limits, pull-based work, on-demand planning) as the team matures.
The endpoint Ladas had in mind was often pure Kanban, with Scrumban as the intermediate state. Many teams stop on the bridge and stay there, which is fine if it is deliberate but a problem if the team has stalled because nobody noticed.
The Lean software development tradition that Ladas built on captures the underlying logic:
"Reducing batch sizes is the most powerful approach to reducing cycle time, increasing flow, and producing predictable delivery." - Don Reinertsen, in The Principles of Product Development Flow (2009), the Lean reference Ladas cites
The 6 core practices
Scrumban inherits practices from both parents. The structural elements that distinguish real Scrumban from abandoned Scrum or unstructured Kanban are six.
| Practice | What it means in Scrumban |
|---|---|
| Visual board | To Do, Doing, Done columns at minimum, often refined into Ready, In Progress, Review, Done. Same idea as a Kanban board with WIP limits per column. |
| WIP limits | The non-negotiable. A team without WIP limits per column is not running Scrumban. Limits force pull, prevent multitasking, and surface bottlenecks. |
| Pull-based work | Team members pull the next task from Ready when their slot opens, instead of being assigned. Replaces sprint-level commitment with column-level commitment. |
| On-demand planning | Planning is triggered when the Ready column drops below a threshold, not on a fixed cadence. Replaces sprint planning's "every two weeks no matter what" with "when we need it." |
| Short iterations (optional) | Many Scrumban teams keep 1 to 2 week iterations as a soft cadence for review and retrospective; pure Scrumban does not require them. |
| Bucket-size planning | Long-term planning happens in three buckets: 1-year, 6-month, 3-month. Items move between buckets as priorities evolve. Replaces sprint backlog with rolling horizon. |
The non-negotiable element is WIP limits. A team without per-column WIP limits is not running Scrumban; it is running a to-do list with columns. The other five practices vary in how strictly they apply (some teams keep iterations, others drop them; planning triggers vary), but the WIP limits are the load-bearing piece. Drop them and the framework collapses into either ceremony-light Scrum or unmanaged flow.
Scrum vs Kanban vs Scrumban
The clearest way to see what Scrumban actually is and is not: side-by-side against its parent frameworks. Most articles describe these differences narratively; the structural shape is easier to read in a table.
| Dimension | Scrum | Kanban | Scrumban |
|---|---|---|---|
| Iteration | Fixed sprints, 1 to 4 weeks | No iterations, continuous flow | Short iterations, often under 2 weeks, optional |
| Planning | Sprint planning at start of each sprint | On-demand, when capacity opens | On-demand, triggered when WIP drops below a threshold |
| Roles | Scrum Master, Product Owner, Developers | No prescribed roles | Existing roles preserved; Scrum Master often becomes part-time |
| Work limits | Sprint backlog scope (commitment) | Strict WIP limits per column | WIP limits + bucket-size planning for longer-term work |
| Ceremonies | Standup, planning, review, retrospective | Optional cadence reviews; standups common | Standup retained; planning and retro often kept; review optional |
| Best for | Predictable feature work, newer agile teams, projects with clear sprints | Continuous flow work, support, ops, mature self-organizing teams | Mixed work, teams transitioning from Scrum to Kanban, or maturing Scrum teams |
| Common failure | Ceremony drift; standups become status meetings | WIP limits not enforced; Kanban becomes a glorified to-do list | Calling it Scrumban while abandoning all structure; "we do hybrid" as ceremony excuse |
The "best for" row is the most important. Scrum is best for predictable feature work and newer agile teams. Kanban is best for continuous flow work and mature self-organizing teams.
The Scrumban methodology sits in a narrow zone: mixed work types, teams transitioning between the two, or maturing Scrum teams that have outgrown sprint commitment but still want some cadence. If your team does not fit that zone, picking Scrum or Kanban directly produces better outcomes than hybrid.
"In Kanban, we make policies explicit, then evolve them. The change is gradual, not revolutionary; this is what allows Scrumban to work as a transition framework rather than a methodology rupture." - David J. Anderson, in Kanban: Successful Evolutionary Change for Your Technology Business (2010), the Kanban reference Ladas built on
When Scrumban actually works
Three contexts where Scrumban is the genuinely better choice over Scrum or Kanban alone.
A Scrum team running mixed work. The most common honest fit. The team has feature work that fits sprints, but also a steady stream of support tickets, ops requests, or bug fixes that do not. Sprint commitment becomes unrealistic because half the work is unplanned. Scrumban's WIP-limit-based pull handles the unplanned stream without abandoning the sprint cadence the team uses for features.
A Scrum-to-Kanban transition. The original Ladas use case. The team is moving from Scrum toward continuous flow but does not want to drop the iteration rhythm overnight. Scrumban serves as the bridge for 6 to 12 months, then the team either lands on Kanban or finds Scrumban itself stable enough to keep.
A maturing Scrum team where ceremony is producing more theater than value. The team has run Scrum for 2+ years, the rituals are auto-pilot, retrospectives produce the same action items repeatedly, and the team self-organizes more than the framework formally allows. Loosening to Scrumban (keeping retros and standup, dropping fixed sprint commitment, adding WIP limits) often produces more genuine agility than enforcing Scrum more strictly would.
When it is just sloppy Scrum
The honest editorial point most Scrumban explainers avoid. Many teams that say "we use Scrumban" mean "we have stopped doing Scrum properly and have not picked up Kanban discipline either." That is not a framework; it is no framework with a borrowed name.
The diagnostic is simple. A team running real Scrumban has at least three of these structural elements: WIP limits per column, pull-based work selection, on-demand planning triggered by a Ready threshold, short iterations as a soft cadence, retrospectives, and bucket-size planning for longer-term work. A team running sloppy Scrum has none of these. The team has dropped sprints, planning, retros, has no WIP limits, and pulls work ad hoc with no flow controls.
Both modes can ship software for a while. The sloppy mode produces declining cycle time, accumulating work-in-progress, and gradual erosion of delivery predictability. The real mode produces steady flow with fewer ceremonies. The names are the same; the outcomes are not. Calling abandoned Scrum "Scrumban" is not a naming convenience; it makes the underlying problem invisible.
The Scrumban board
The board is the central artifact, and it is where most Scrumban implementations stand or fall. Done well, the board makes the work visible, the WIP limits enforceable, and the flow inspectable. Done poorly, it is a Trello with extra columns.
The minimum columns: To Do (or Ready), In Progress, Done. WIP limits go on at least In Progress, ideally on Review or QA columns if those exist. Many Scrumban teams add a Backlog column to the left of Ready, where prioritized but not-yet-pulled items live.
For tools, any decent task management tool will support the board structure. The constraint is not the tool; it is the discipline to actually enforce the WIP limits when the team wants to take on one more thing. Most board failures are discipline failures, not tool failures.
What we recommend
For most teams considering Scrumban, the practical answer is "diagnose your context first, do not adopt the hybrid by default." The decision quiz above is calibrated to the real fit zone. If the quiz pointed at Scrum or Kanban, picking that directly is usually the better move than reaching for hybrid.
If Scrumban is genuinely the right fit, the practical setup is straightforward: keep your existing Scrum board, add WIP limits per column, switch from sprint commitment to on-demand planning, keep the retrospective. After 90 days, audit honestly: are the WIP limits being held, is delivery still predictable, has someone said "we should just go back to Scrum"? The answers tell you whether the framework is fitting or whether the team is masking a different problem.
What we do at Rock: chat, tasks, and notes live in one workspace, so the Scrumban board, the conversations about flow, and the documentation of decisions all sit together. For a small team or agency running Scrumban with a part-time facilitator, this consolidation matters more than tool sophistication; the framework's leverage depends on visibility, not on a dedicated agile tool.
Common pitfalls
The predictable failure modes when teams adopt Scrumban.
- Calling it Scrumban after dropping every ceremony Most "we do Scrumban" teams have stopped doing standups, planning, retros, AND have no WIP limits. That is not Scrumban. That is no framework with a borrowed name. Pick at least three structural elements (WIP limits, pull-based work, on-demand planning) and hold them deliberately, or admit the team has reverted to ad hoc.
- No WIP limits WIP limits are the load-bearing element of Scrumban inherited from Kanban. Without them you do not have flow control, the In Progress column accumulates, and the team's actual cycle time stays invisible. If you fix only one thing in a struggling Scrumban setup, fix this.
- Treating it as "Scrum without the rituals" Scrumban is not Scrum minus discipline. Corey Ladas designed it as a transition framework that pulls toward Kanban discipline (flow, WIP, pull) while keeping useful Scrum elements (short iterations, prioritization, retrospective). Drop the Kanban half and you keep all the rigidity of Scrum without the structure that makes the rigidity productive.
- Skipping retrospectives because "we are Scrumban now" Retrospectives are one of the most-kept practices when Scrumban is done well. They are also one of the first to drop when teams use the framework as ceremony cover. The bi-weekly retro is the cheapest agile practice in terms of time-to-value; abandoning it is rarely a good trade.
- Permanent transition Ladas wrote Scrumban as a transition path from Scrum to Kanban. Some teams stop on the bridge for years, never reaching the Kanban side, never going back to Scrum. That is fine if it is a deliberate choice; it is a problem if the team has stalled because nobody noticed. Audit the framework yearly: is this still where the team should be?
"The right method depends on the work, not on the framework. A team that thrives in continuous flow is not a worse team because it dropped sprints; a team that needs sprint structure is not behind because it kept it. Match the method to the problem." - Nicolaas Spijker, growth and operations lead at Rock
Frequently asked questions
What is Scrumban?
Scrumban is an agile framework that combines Scrum's structure (short iterations, prioritization, retrospectives) with Kanban's flow practices (WIP limits, pull-based work, continuous flow). Corey Ladas created and named it in 2009 in his book "Scrumban: Essays on Kanban Systems for Lean Software Development," originally designing it as a transition path for Scrum teams adopting Kanban concepts.
Who created Scrumban?
Corey Ladas, a software development consultant, coined and described the method in his 2009 book published by Modus Cooperandi Press. The framework was developed for teams running Scrum who wanted to incorporate Lean and Kanban principles without abandoning Scrum's iterative structure entirely. Most popular Scrumban explainers skip the attribution; the original source is the better read for anyone serious about applying the method.
What is the difference between Scrumban and Kanban?
Kanban has no iterations, no prescribed roles, and no required ceremonies; flow is continuous and managed by WIP limits and pull. Scrumban keeps WIP limits and pull-based work but typically retains short iterations (1 to 2 weeks) and core ceremonies like standup and retrospective. Teams choosing Kanban are usually further along; teams choosing Scrumban are typically transitioning from Scrum or running mixed work types.
What is the difference between Scrumban and Scrum?
Scrum has fixed sprints, sprint commitment, sprint planning every cycle, and prescribed roles (Scrum Master, Product Owner, Developers). Scrumban replaces sprint commitment with WIP-limit-based pull, makes sprint planning on-demand (triggered when Ready column drops below a threshold), and treats roles more flexibly. The structure is lighter and the flow is more continuous, while keeping the cadence Scrum teams are used to.
When should a team use Scrumban?
Three contexts make Scrumban a defensible choice. First, a Scrum team that is finding sprint commitments unrealistic because work types are mixed (planned features plus support tickets). Second, a team transitioning from Scrum to Kanban that wants intermediate structure during the change. Third, a maturing Scrum team where strict ceremony cadence has started producing more theater than value. Outside those contexts, picking Scrum or Kanban directly usually beats hybrid by default.
Is Scrumban just an excuse to skip Scrum ceremonies?
It can be, and frequently is. The honest version of Scrumban preserves at least three structural elements: WIP limits, pull-based work, and either short iterations or on-demand planning triggers. A team that has dropped sprints, planning, retros, AND has no WIP limits is not running Scrumban; it is running no framework with a borrowed name. The pitfalls section above covers this in detail.
Do you need a Scrum Master to run Scrumban?
Not formally. Many Scrumban teams keep a part-time Scrum Master or shift to a facilitator who handles flow management and the surviving ceremonies. The role becomes lighter than in traditional Scrum (no sprint planning every two weeks, less ceremony orchestration) but the work of removing impediments and coaching the team in the framework still exists. The role profile shifts; the work does not disappear.
How to start with Scrumban this week
For teams that ran the diagnostic and landed on Scrumban, the practical setup steps below take roughly two weeks of light effort to land. Start with the existing Scrum board; do not redesign from scratch.
- Start with your existing Scrum board Most teams adopting Scrumban already have a sprint board. Keep it. Rename "Sprint Backlog" to "Ready" and "Done" to "Done This Iteration" if you want; the visual continuity helps the team adopt the change without feeling thrown into a new system. The board is the starting artifact, not a clean redesign.
- Set WIP limits per column For a team of 5 to 7 developers, In Progress = 3 to 4 is a typical starting point. Review = 2. Numbers are deliberately tight; the discomfort the limits create is the signal you are doing it right. Adjust after two weeks based on observed flow, not on team complaints.
- Switch from sprint commitment to on-demand planning Stop committing to a fixed sprint scope. Instead, pick a threshold (Ready column below 5 items) that triggers a short planning conversation to refill it. Planning becomes 30 minutes when needed, not 2 hours every sprint. Review after one month to see if the trigger threshold is right.
- Keep the retrospective; consider keeping the standup The retrospective is the cheapest agile practice in time-to-value and the easiest to drop accidentally. Keep it bi-weekly. The daily standup is more debated; many Scrumban teams keep a 10-minute version focused on flow blockers, not status. Test both with and without for two weeks each.
- Audit the framework after 90 days Three questions: are WIP limits being held; are deliverables actually shipping; has anyone said "we should just go back to Scrum"? If the answer to all three is yes, no, or yes, the framework is not working for the context. Scrumban is a means, not a destination; revisit deliberately every quarter.
Whichever framework fits your team, the work happens better when chat, tasks, and notes share a workspace. Rock combines them at one flat price, unlimited users. Get started for free.
