The short answer: Scrumban combines kanban with scrum by keeping scrum's planning cadence and roles while replacing rigid sprint commitments with kanban's pull-based flow and WIP limits. Teams get the structure of regular planning and retrospectives without the bottleneck of a frozen two-week scope — which is exactly what AI-accelerated delivery now demands.
Most teams running scrum in 2026 are quietly cheating on it. They keep the standups and the sprint planning theater, but mid-sprint they pull in urgent work, swap stories, and ignore the sprint goal. The framework says one thing; the team does another. That gap has a name, and it's not failure — it's scrumban.
Combining kanban with scrum is no longer a transitional hack for teams moving from one framework to the other. It's the dominant operating model for agile teams that need scrum's rhythm but cannot afford its rigidity, especially as AI tools collapse the time it takes to deliver a feature from days to hours. According to the State of Agile Report, scrumban and kanban-flavored hybrids now rival pure scrum adoption among mature teams, and the gap is widening.
This guide walks through exactly how to implement scrumban — which scrum ceremonies to keep, how to set WIP limits inside a sprint, the board structure that actually works, and why AI-augmented teams are finding scrumban's blend of structure and continuous flow more productive than rigid two-week cycles.
What is scrumban, really
Scrumban is a hybrid agile framework that pairs scrum's planning cadence, roles, and feedback loops with kanban's visual workflow, pull system, and work-in-progress limits. It was originally proposed by Corey Ladas in 2008 as a transition path from scrum to kanban, but it has matured into a standalone operating model used by product, platform, and operations teams that need both predictability and responsiveness.
The simplest way to think about it: scrum gives you the calendar, kanban gives you the flow.
From scrum, you keep: a prioritized backlog, regular planning intervals, sprint reviews, retrospectives, the product owner role, and a facilitator (scrum master, delivery lead, or team lead).
From kanban, you adopt: a visual board with explicit columns, WIP limits per column, pull-based work selection, and flow metrics (cycle time, throughput, flow efficiency).
What you drop is the part of scrum that breaks under pressure: the locked sprint scope. In scrumban, sprints become cadenced planning intervals rather than fixed delivery commitments. Work flows continuously; planning is just when you refill the queue.
Scrumban vs scrum vs kanban at a glance
When to choose scrumban over scrum or kanban
The wrong reason to adopt scrumban is because scrum feels uncomfortable. The right reason is that your work pattern no longer matches what scrum was designed for.
Pick scrumban when:
You ship a mix of planned features and reactive work. Bug fixes, customer escalations, incident response, and ad-hoc requests crash sprint commitments every cycle.
AI tools have collapsed your delivery time. When pair programming with Copilot or Cursor lets a developer ship a feature in hours instead of days, two-week sprints become arbitrary speed bumps.
Sprint planning feels like theatre. This is the most common signal in practitioner communities — teams forecasting work they know will change within 48 hours.
You've outgrown story points but still need a planning rhythm. Mature teams forecast better with cycle-time data than with relative estimation.
Backlogs grow faster than they're cleared. A pull system with WIP limits forces prioritization in a way scrum's sprint backlog does not.
Stick with pure scrum when:
The team is new to agile and needs the discipline of fixed cadence and clear roles.
The product is in early discovery, where time-boxing forces honest learning loops.
Stakeholders need a hard predictability commitment every sprint.
Stick with pure kanban when:
Work is almost entirely reactive (support, ops, SRE).
There is no meaningful planning horizon — work arrives and is processed.
The team has no need for a regular product review with stakeholders.
How to implement scrumban: a step-by-step guide
This is the part most articles skip. Here is the actual sequence to roll scrumban out without breaking your team mid-flight.
Step 1: Map your current workflow as a kanban board
Forget your current Jira board for a minute. Walk through the real lifecycle of a single work item from idea to production. Most teams find 6–9 stages, not the 3 their tool defaults to.
A solid scrumban board for a software team usually looks like this:
Backlog — prioritized but not committed
Ready — refined, sized, meets definition of ready
In progress — actively being worked
Code review / pair review — including AI-assisted review where applicable
Testing / QA
Ready for release
Done
The "ready" column is the single most important addition. It's the buffer between refinement and execution that scrum lacks, and it's where pull-based work selection actually starts.
Step 2: Set WIP limits per column
WIP limits are the heart of scrumban. They are also where most implementations fail because teams set them too generously, defeating the point.
Starting heuristics for a team of 5–7:
In progress: team size minus 1 or 2 (forces pairing or finishing)
Code review: 2–3 (review is the most under-prioritized stage)
Testing: 2–3 (don't let test become a graveyard)
Ready: 1.5× to 2× team size (enough to pull from, not enough to hoard)
The rule is simple: if a column is at its WIP limit, no one pulls a new item into it. Instead, the team swarms whatever is closest to done. This is what stops starting and starts finishing.
Expect resistance. WIP limits feel constraining at first because they expose the multitasking that was hiding inefficiency. Hold the line for at least three planning cadences before adjusting. Cycle time will drop, sometimes dramatically — that's the signal the limits are working.
Step 3: Replace sprint commitment with planning cadence
Keep your two-week (or one-week, or four-week) rhythm. But change what happens at the boundary.
Old model: Plan a fixed sprint backlog. Commit. Freeze scope. Deliver. Review. Retro.
Scrumban model: Refill the "ready" column. Forecast based on recent throughput, not story points. Adjust priorities. Review what shipped during the period, regardless of when it started. Retro.
Planning becomes faster and lighter. Most scrumban teams cut planning from the canonical 2–4 hours down to 30–60 minutes once the ready queue is healthy. The conversation shifts from "what can we commit to" to "what should we work on next, in what order."
Step 4: Adopt on-demand replenishment
This is the practice that most distinguishes scrumban from scrum. Instead of refilling the backlog only at sprint planning, you trigger replenishment whenever the ready column drops below a threshold (say, half its WIP limit).
In practice this means:
The PO and team hold a 15–20 minute refinement session as needed, not just on a fixed schedule.
Items move from backlog → ready when they meet definition of ready.
The team always has 1–2 weeks of refined, prioritized work available without needing a planning meeting.
This is what unlocks responsiveness. Urgent work doesn't break a sprint commitment because there is no commitment — there is only the next-best thing to pull.
Step 5: Switch from velocity to throughput and cycle time
Drop story points. Drop velocity. Both were proxies that broke under AI-augmented delivery anyway.
Track instead:
Throughput: items completed per week (or per planning interval)
Cycle time: the time from "in progress" to "done" for each item
Flow efficiency: active work time ÷ total cycle time (most teams sit at 15–25%; that's where waste hides)
WIP age: how long each item has been in progress (oldest = most at risk)
These metrics are objective, comparable across teams, and don't require the bias-prone group estimation theatre that story points produce. Use them for forecasting with Monte Carlo simulation instead of velocity-based projections — Daniel Vacanti's work on actionable agile metrics is the canonical reference here.
Which scrum ceremonies to keep, modify, or kill in scrumban
Ask any practitioner what they quietly stopped following from scrum, and ceremonies dominate the list. Here's an honest evaluation of which ones earn their time inside scrumban.
Keep, mostly unchanged
Retrospective. Still the most valuable scrum event. Teams that drop retros lose the only structured space for continuous improvement. In scrumban, run retros at the end of each planning interval, focused on flow metrics and one observable improvement for the next cycle.
Sprint review / product review. Keep it, but reframe: it's a review of what shipped during the period and a working session on what should be pulled next, not a demo theater for stakeholders.
Modify
Planning. Cut to 30–60 minutes. Replenishment, not commitment. Forecast with throughput, not story points.
Daily standup. Stop the round-robin status update. Walk the board right-to-left, focused on items closest to done, blockers, and WIP limit breaches. Ten minutes max.
Refinement. Make it on-demand instead of a fixed weekly meeting. Trigger when the ready queue drops below threshold.
Kill or replace
Story-point poker. Replace with right-sizing (will it fit in our cycle-time distribution? yes or no) or skip estimation entirely once throughput data is reliable.
Sprint commitment. Replace with rolling forecast.
Velocity reporting. Replace with throughput and cycle-time charts. Velocity comparisons across teams were always a measurement antipattern; they get worse when AI assistance varies between teams.
How AI-augmented teams use scrumban to ship faster
This is where scrumban stops being a hybrid framework and starts being the only sane option. The pattern is everywhere in practitioner communities right now: developers using AI tools ship features faster than scrum's planning cadence can keep up with, and traditional sprint rituals start to feel like overhead that exists for the framework's sake, not the team's.
The AI-and-agile feedback loop
AI tools — pair-programming assistants, automated test generation, AI code review, AI-driven backlog triage — compress the cycle time of individual work items dramatically. The DORA 2025 report found AI adoption increases throughput while also increasing instability, which means teams need more feedback loops, not fewer. Scrumban delivers exactly that:
Continuous flow lets each work item travel through review, test, and release independently, surfacing AI-introduced regressions earlier than batched sprint releases would.
WIP limits prevent the most common AI-era failure mode — developers spinning up more parallel work than the team can review and integrate, because generating code is now cheap.
On-demand replenishment keeps the backlog healthy when AI tools tear through items 2–3× faster than expected.
What changes for the scrum master and product owner
The scrum master role is not dead in scrumban — it changes shape. The job becomes flow steward, coach, and AI-readiness lead: tuning WIP limits, removing systemic blockers, helping the team integrate AI tools into the workflow without breaking review and quality gates. Pure ceremony facilitation is no longer enough to justify the role.
Product owners gain leverage. Instead of negotiating a fixed sprint scope every two weeks, they shape a constantly-replenished ready queue, with priorities that can shift between any two pulls. AI-powered backlog tools (auto-triage, intelligent prioritization, draft user-story generation from product strategy) make this manageable at a scale that would have been impossible with manual refinement.
A practical AI + scrumban workflow
Backlog triage. AI categorizes incoming work, drafts initial user stories, and flags duplicates and dependencies.
Refinement. PO and a couple of engineers refine the top of the backlog into the ready column. AI generates draft acceptance criteria; humans verify and adjust.
Pull and pair. Developer pulls a ready item, pairs with an AI assistant for implementation. WIP limit prevents starting a second item.
Review. AI does a first-pass code review for style, security, and obvious bugs. A human reviewer focuses on architecture, edge cases, and product fit.
Test and release. Automated tests (often AI-generated) run on every PR; release happens on-demand, not at sprint boundary.
Retro. Team reviews flow metrics, AI-assisted insights from sprint data, and agrees on one improvement.
This is the operating model FixAgile, an Agile training and implementation framework designed for the age of AI, helps teams build. It is not scrum with AI bolted on. It is a scrumban operating model with AI-readiness embedded into every stage — which is the difference between teams that get faster and teams that get faster and more stable.
Common scrumban implementation mistakes (and how to avoid them)
Setting WIP limits too high. If your limits never bind, they're not limits. Start tight and loosen if the team is genuinely starved for work.
Keeping story points out of habit. Story points and a pull-based system actively conflict. Pick one.
Skipping the ready column. Without a refined buffer between backlog and in-progress, you'll keep doing just-in-time refinement under pressure — the original sin of broken scrum.
Treating the planning cadence as optional. Scrumban without cadence is just kanban with scrum vocabulary. Keep the rhythm.
Not retiring velocity. If leadership still demands velocity reports, hold the line. Provide throughput, cycle time, and forecast confidence intervals instead. Educate up.
Adopting WIP limits without fixing the workflow. WIP limits expose problems; they don't solve them. Be ready to address bottlenecks they reveal — usually code review and testing.
Frequently asked questions about combining kanban with scrum
Is scrumban an official framework?
No. Unlike scrum (with the Scrum Guide) or SAFe, scrumban has no governing body or canonical definition. The closest authoritative reference is Corey Ladas's original work and Scrum.org's Kanban Guide for Scrum Teams, which describes how to add kanban practices to scrum without changing the framework.
Can you do scrumban inside SAFe?
Yes, and many organizations do. Team-level kanban inside Agile Release Trains is explicitly supported by SAFe, and the same pull-based, WIP-limited approach scrumban prescribes works inside a PI cadence. The PI replaces the planning cadence; everything else translates.
What's the difference between scrumban and "scrum-but"?
Scrum-but is broken scrum — teams keeping ceremonies they hate and ignoring rules they find inconvenient, with no replacement principle. Scrumban is intentional: it replaces sprint commitment with pull-based flow and adopts kanban's principles wholesale, not piecemeal.
How long does it take to switch from scrum to scrumban?
A team can run a credible scrumban experiment within two planning cycles (4 weeks for two-week sprints). Stable WIP limits, throughput data, and retired story points usually take 8–12 weeks. Cultural shifts — leadership accepting throughput over velocity, stakeholders accepting rolling forecasts — can take longer and are where most transformations stall.
Do we still need a scrum master?
You need someone accountable for flow, coaching, and removing systemic blockers. Whether that person is called scrum master, agile delivery lead, team coach, or flow manager matters less than whether the role actively shapes how the team works. The pure ceremony-facilitator interpretation of the scrum master role is the version that's disappearing.
The bottom line: scrumban is the operating model AI-era teams need
The debate over whether scrum is dead misses the point. Scrum's principles — empiricism, transparency, inspection, adaptation — are more relevant than ever. What's broken is the rigid sprint commitment that AI-accelerated delivery now routinely overruns. Scrumban keeps the principles and replaces the ritual that no longer earns its time.
If your team is quietly cheating on scrum, swapping mid-sprint scope, drowning in stale backlog, or watching AI tools outpace your planning cadence, you're already doing scrumban — badly. Doing it deliberately, with clear WIP limits, a proper pull system, and throughput-based forecasting, is what separates teams that get faster from teams that just get more chaotic.
If your agile transformation has stalled, your sprints feel like theater, or your teams are struggling to integrate AI into a workflow that scrum was never designed for, this is exactly what FixAgile's training programs and embedded coaching are built to solve. We help teams move from broken scrum to deliberate scrumban — and from there to the AI-augmented operating model that makes speed and stability compatible again.
