What Is Scrumban? Kanban vs Scrumban vs Scrum

Scrumban is a way of working that keeps Scrum’s regular rhythm of planning, review and retrospective and runs the work inside it as a Kanban pull system: a visible board, limits on how much is in progress, and new work started only when there is capacity. The difference between Kanban and Scrumban is mostly that rhythm. Kanban asks for no fixed cadence at all; Scrumban keeps a regular planning and review cycle, usually without the full set of Scrum roles, commitments and sprint-sized estimates. Unlike its parents, Scrumban has no single official guide, so usage varies, and two teams calling themselves Scrumban may work quite differently.

The broader choice between the two parent methods is covered in Kanban vs Scrum. This page is about the hybrid.

Where the name comes from

The term is credited to Corey Ladas, who described it in an essay written in 2008 and included in his book Scrumban, published the same year. The Agile Alliance glossary reprints it as its Scrumban entry↗ (opens in a new tab), with his permission. His argument was aimed at Scrum teams: a task board with sticky notes looks like kanban but is not a pull system, because nothing stops work piling up in progress, and timeboxed iteration planning is not pull either.

He proposed adding pull features to Scrum step by step. First, limit how much each person has in progress. Then turn that into a limit on the whole board, so the cards themselves become the signal to start new work. Then split “in progress” into clearer states with a limit on each. At that point, he wrote, the team still has its timeboxed iteration and planning cycle, “so perhaps we might call such a thing a Scrumban system”. Later stages replace estimating every item with a fixed-size iteration backlog, and eventually let planning be triggered when that queue runs low rather than by the calendar. So Scrumban started as a path from Scrum towards Kanban, not a fixed destination.

What Scrumban keeps from each

From Scrum

• A regular cadence. Planning, review and retrospective on a fixed rhythm, often every one or two weeks, so there is a predictable time to decide what is next and to look back.
• An ordered backlog with someone accountable for the order, usually a product owner in role if not in name.
• The habit of inspecting and adapting: a review with stakeholders and a retrospective for the team.

From Kanban

• Work-in-progress limits, per column or for the whole board, which are what make it a pull system.
• Pull rather than push: people start an item when a slot frees up, not because it was assigned at planning.
• A persistent board that does not reset at the end of each iteration, with explicit policies for when an item may move.
• Flow measures, such as cycle time and throughput, used for forecasting in place of story points and velocity.

What it usually drops: the Sprint as a commitment boundary, sprint-sized estimation, and often the Scrum Master as a separate accountability. That is where the arguments start, because the 2020 Scrum Guide↗ (opens in a new tab) is explicit that implementing only parts of Scrum is possible, but the result is not Scrum. It also says Scrum works well as a container for other techniques, so a Scrum team that adds WIP limits and flow metrics inside its Sprints is still doing Scrum.

Typical Scrumban practices

1. A board with a ready column. Work waits in an ordered backlog, and a small “ready” column holds the next few items that have been refined and can be started.
2. Limits on in-progress columns, written on the board, and a rule that you help finish something before starting something new.
3. Planning on demand or on a short cadence. Planning fills the ready column back up; many teams trigger it when the column drops below a set number of items.
4. A fixed rhythm for review and retrospective, even when planning happens on demand.
5. Forecasting from history. How long items usually take, and how many finish a week, replace velocity.

Kanban itself asks for surprisingly little. The Kanban Guide↗ (opens in a new tab) requires a definition of workflow that says how work in progress is controlled and sets a service level expectation, a forecast of how long an item should take, plus four flow metrics: work in progress, throughput, work item age and cycle time. Its 2025 revision renamed the section on measures to flow metrics. It also says Kanban can and should be used to augment other delivery approaches, which is Scrumban’s whole premise.

Kanban vs Scrumban vs Scrum

• Cadence. Scrum: fixed Sprints of one month or less, with every event inside them. Scrumban: a regular planning and review rhythm, with work flowing continuously in between. Kanban: no cadence required; reviews happen when useful.
• Roles. Scrum: Product Owner, Scrum Master and Developers. Scrumban: usually whoever orders the backlog plus the team; no roles are required. Kanban: none required.
• Limiting work. Scrum: the Sprint Backlog limits what is taken on for the Sprint. Scrumban and Kanban: explicit limits on work in progress.
• Commitment. Scrum: a Sprint Goal for each Sprint. Scrumban: often a short goal per cycle, but not required. Kanban: a service level expectation per item.
• Estimation and forecasting. Scrum: left to the team; many use story points. Scrumban and Kanban: flow measures from past work.
• Change mid-cycle. Scrum: nothing that endangers the Sprint Goal. Scrumban and Kanban: the next item can change until someone starts it.

When it helps

• A Scrum team whose Sprints keep getting interrupted by urgent work, such as support or production fixes, but whose stakeholders still want a regular review.
• A maintenance team that has finished a product’s first build: most work is now small and unplanned, but the team wants to keep its retrospectives.
• A Kanban team that has drifted: nobody stops to look at the whole, and a fixed fortnightly review would restore that.
• A team with stuck work. If many items are in progress and few are finishing, adding WIP limits is the single most useful change, and Scrumban is a familiar name for it.

When it is an excuse

Scrumban is sometimes the name a team gives to having dropped the uncomfortable parts of both methods: no Sprint Goal, because commitments were awkward, and no WIP limits, because limits were awkward too. What is left is a board with columns and some meetings. A quick test:

• Is there a written limit on work in progress, and does anyone stop to finish something when it is reached? If not, it is not Kanban’s half.
• Does the team stop at a regular interval to review the product with stakeholders and its own process? If not, it is not Scrum’s half.
• Can the team say how long an item usually takes from start to finish? If not, it has dropped estimation without replacing it.
• Did the team choose the hybrid on purpose, and can it say what problem each practice solves? “We do a bit of both” is not an answer.

If a team fails all four, it is better to pick one of the parent methods and follow its guide as written for a few months. Both guides are short.

Running Scrumban on a fenbs board

fenbs is a kanban-style board with four fixed lanes: To Do, Next Up, In Progress and Completed. It has no sprints, no story points, no velocity chart and no work-in-progress limit setting, so some of Scrumban has to live in written policy rather than in the tool.

• To Do is the ordered backlog. Priority runs 1 to 10, with 1 the most urgent, and the Shared order on a team board is the exact order everyone sees.
• Next Up plays the ready column. Keep it to a number you agree, and refill it at your planning cadence or when it runs low.
• WIP limits are a written rule, not a setting. Put the rule in the board’s AI context so every connected AI assistant reads it before it starts, and tell your team the same thing.
• Cycle time comes from History, which records every move with the lane it left, the lane it entered, the time and who made it, person or assistant.
• Size is optional, from XS to XL, where XL means split it. That is as close to estimation as the board goes.
• Review and retrospective happen wherever your team talks. Decisions from either go on the Decisions page, with who decided and why.

If you need a board that enforces column limits for you, or reports that chart cumulative flow automatically, a dedicated Kanban tool will serve you better.