What Is Scrumban? Scrum and Kanban Combined

The short answer

Scrumban is a way of working that combines scrum and kanban. The team keeps some scrum habits, such as regular planning and retrospectives, but runs the work on a kanban board with work-in-progress (WIP) limits. Instead of committing to a fixed list of tasks for a sprint, people pull the next card whenever there is room.

Where scrumban comes from

The name was coined by Corey Ladas, who described scrumban in 2008 as a way to move a scrum team towards kanban. Today the word is used more loosely for any team that blends the two methods.

How scrumban works

• The work lives on a board, with a column for each stage, from Backlog to Done.
• Columns such as In progress and Review have WIP limits, so the team finishes work before starting more.
• Work is pulled: when someone has capacity, they take the top card from the Ready column.
• Planning happens on demand: when the Ready column drops below an agreed number of cards, the team meets to refill it.
• Many teams keep a short review and retrospective every one or two weeks.
• Roles are optional. Teams keep the ones they already have.
• Priorities can change at any time for cards that have not been started.

Scrumban vs scrum vs kanban

• Planning: scrum plans a whole sprint up front; scrumban plans when the Ready column runs low; kanban plans continuously.
• Commitment: scrum commits to a sprint goal; scrumban and kanban do not fix the scope in advance.
• Limits: scrum limits work to what fits in a sprint; scrumban and kanban use WIP limits per column.
• Meetings: scrum has four set events; scrumban usually keeps a planning trigger, a review and a retrospective; kanban requires none.
• Roles: scrum has a Product Owner, a Scrum Master and Developers; scrumban and kanban require none.

For the two parent methods side by side, read kanban vs scrum.

When scrumban is a good fit

• Product teams that also handle support requests, so part of the work cannot be planned two weeks ahead.
• Scrum teams whose sprint commitments keep breaking because priorities change mid-sprint.
• Maintenance and operations teams that want some planning rhythm without the full scrum framework.
• Teams moving from scrum to kanban step by step.

How to set up a scrumban board

1. Create five columns: Backlog, Ready, In progress, Review and Done.
2. Put a WIP limit on In progress and Review, for example one or two cards per person.
3. Agree a planning trigger, such as "when Ready has fewer than five cards, we plan".
4. Keep Ready in priority order, so whoever is free takes the top card.
5. Hold a short review and retrospective every one or two weeks.
6. Watch how long cards take from In progress to Done, and adjust the limits if work piles up.

Common mistakes

• Keeping every scrum meeting and adding kanban rules on top: scrumban should mean less process, not more.
• WIP limits nobody respects: if a limit is always broken, lower the work coming in or change the limit together.
• A Ready column with no order: without priorities, people pick the easiest card instead of the most important one.
• Cards that are too big: split anything that would sit in In progress for more than a few days.

How to run scrumban in Glidely

Start a free kanban board or the Sprint board template, then rename the lists to Backlog, Ready, In progress, Review and Done. Give In progress and Review a card limit: Glidely shows the count against the limit and flags the list when it goes over. Add story-point estimates if your team uses them, and switch to Timeline or Calendar to see what is due. New to boards? Read what a kanban board is.

Frequently asked questions