Skip to main content
Scrumban is what happens when a team has been doing Scrum for a while, found the bits that work, dropped the bits that don’t, and borrowed some flow-based thinking from Kanban. It’s less a formal framework and more an honest description of how many experienced teams actually operate 🔀

​
Where it came from

Corey Ladas coined the term in 2008 as a transition path from Scrum to Kanban. Teams could keep the Scrum structure while introducing Kanban’s WIP limits and flow thinking, then adjust the balance over time. In practice, most teams using Scrumban didn’t consciously adopt it - they just evolved toward it.

​
What it typically looks like

  • Sprints or cycles - some cadence for planning and review, but not necessarily rigid two-week sprints. Some teams use three-week cycles, some use rolling planning.
  • WIP limits - borrowed from Kanban. Work in progress is capped so flow stays healthy and bottlenecks surface quickly.
  • On-demand planning - rather than planning a full sprint upfront, work is pulled into progress when capacity exists and there’s clear, ready work to pick up.
  • Retros kept, some ceremonies dropped - most Scrumban teams keep retrospectives and reviews because they’re genuinely useful. Daily standups may be shortened or made async.

​
When it makes sense

Scrumban suits teams where the work mix is unpredictable - a combination of planned feature work, reactive bug fixes, and support requests. Pure Scrum struggles when unplanned work consistently disrupts sprint commitments. Pure Kanban can lose the regular alignment points that keep teams connected to product goals 💡 It also suits mature teams that have internalised agile principles and don’t need the scaffolding of strict Scrum to stay organised.

​
The honest version

Most “Scrum teams” are quietly doing Scrumban already - skipping ceremonies that feel wasteful, setting informal WIP limits, doing rolling planning when sprints don’t fit the work. Naming it just makes it intentional rather than accidental 🙌 Lesson learned: I’ve never worked on a team that stayed in pure Scrum forever. The ones that evolved deliberately - talking openly about what wasn’t working and adjusting - ended up in much better places than the ones that just silently stopped following the process.