Scrumban vs kanban: when a little sprint structure helps a kanban team
A team has been running on a kanban board for a year. Cards move from left to right, work gets done, and nobody wants to go back to long status meetings. Yet something feels loose. Priorities change every other day. The backlog column has grown to ninety cards. Nobody can say with confidence what will be finished by the end of the month, and reviews happen only when someone remembers to call one.
This is usually the moment someone mentions scrumban. The name suggests a compromise between Scrum and kanban, and that is roughly what it is. The useful question is not which label is correct, but which pieces of structure solve the problems the team actually has. This article compares the two, identifies the signals that a kanban team would benefit from some sprint rhythm, and shows how to add that rhythm in small steps.
Kanban in plain terms
Kanban is a method for managing a flow of work. Its core practices are simple.
Visualize the work. Every item is a card, and every stage the work passes through is a column. The board shows the real state of the work, not the intended state.
Limit work in progress. Each column, or the board as a whole, has a cap on how many items can be in it at once. When a column is full, people finish something before starting something new.
Manage flow. The team watches how long items take to move through the board and where they wait. Improvement means removing the causes of waiting.
Make policies explicit. What it takes for a card to move from one column to the next is written down, so everyone applies the same rules.
Kanban does not prescribe roles, fixed iterations, or scheduled ceremonies. Work is pulled when there is capacity. Priorities can change at any moment, as long as the change happens in the backlog and not in the middle of work already started. The Atlassian guide to kanban is a readable reference for the basics.
That flexibility is kanban's main strength. It is also the source of the looseness described at the start. Without any time boundary, there is no natural point to step back, reorder, and review.
Scrumban in plain terms
Scrumban starts from a kanban board and borrows selected practices from Scrum. There is no single official definition, and teams assemble it differently. Most versions include some combination of the following.
A regular planning cadence. The team meets on a fixed schedule, often every one or two weeks, to reorder the backlog and decide what to pull next. Unlike Scrum, the team does not always commit to a fixed set of items for the period.
A ready queue. Between the backlog and active work sits a short, ordered column of items that are refined and ready to start. Planning fills this queue, and people pull from it during the period.
WIP limits from kanban. The limits on work in progress stay. They are what keep the flow healthy between planning sessions.
Periodic review and retrospective. At the end of each cycle, the team looks at what was finished and discusses what to change.
Planning on demand. Some teams skip the fixed schedule and trigger planning when the ready queue drops below a threshold. This keeps planning tied to actual throughput.
What scrumban usually leaves out from Scrum is equally telling: formal roles such as Scrum Master and Product Owner are optional, estimation is often skipped in favor of counting items, and the sprint backlog is not locked. The Atlassian page on scrumban describes a similar mix.
Side by side
The table compares kanban, scrumban, and Scrum on the points that matter most for a small team deciding what to adopt.
| Aspect | Kanban | Scrumban | Scrum |
|---|---|---|---|
| Time boundaries | None required | Regular cycles, often one or two weeks | Fixed sprints of one month or less |
| Planning | Continuous, as capacity frees up | At a set cadence or when the ready queue runs low | At the start of each sprint |
| Commitment | Per item, when pulled | Loose, usually a ready queue rather than a locked list | Sprint goal and selected backlog items |
| WIP limits | Central practice | Kept from kanban | Not a formal practice, sprint scope acts as the limit |
| Roles | No prescribed roles | Usually none, sometimes a person who orders the backlog | Product Owner, Scrum Master, Developers |
| Estimation | Optional, often none | Often item counts rather than points | Common, though not required by the guide |
| Changing priorities | Anytime in the backlog | Anytime in the backlog, ready queue reviewed each cycle | Mostly between sprints |
| Review | When the team chooses | At the end of each cycle | Sprint review and retrospective every sprint |
The table makes one point clear. Scrumban is closer to kanban than to Scrum. It keeps the flow-based board and WIP limits, and adds a clock for planning and review.
Signs a kanban team needs a little sprint structure
Not every kanban team needs to change. The following signs suggest that adding rhythm would help.
The backlog keeps growing and nobody reorders it
When the backlog column is long and its order reflects when things were added rather than what matters, pulling the next item becomes guesswork. A regular planning session gives the team a fixed moment to reorder and prune.
Stakeholders ask for dates the team cannot give
Pure kanban teams can forecast from cycle time, but many small teams do not track it. A cycle of one or two weeks gives stakeholders a simple answer: items in the ready queue are expected within the next cycle or two.
Retrospectives never happen
Without a calendar trigger, reviews tend to occur only after something goes wrong. A fixed cycle end makes improvement routine rather than reactive.
Urgent work constantly interrupts
If the board is full of half-started items because urgent requests jump in, the problem is often WIP discipline rather than lack of sprints. Check WIP limits first. If limits exist and interruptions still dominate, a short cycle with an explicit lane for urgent work can make the trade-off visible.
The team feels no sense of progress
Continuous flow can feel endless. A cycle boundary where the team looks at what was finished is a small thing, but it often improves morale more than any process change.
Signs a team should stay with plain kanban
Some teams would add cost without benefit by moving to scrumban.
Support and operations teams whose work arrives unpredictably usually do better with kanban. Their priorities change by the hour, and a planning cadence adds a meeting that is out of date by the next morning.
Very small teams, such as two or three people who talk constantly, often reorder the backlog informally every day. A formal planning session would repeat what already happens.
Teams whose flow is already healthy, with a short backlog, stable WIP, and regular informal reviews, gain little from adding a cycle. If it is not broken, a label change will not improve it.
Teams that recently left Scrum because of meeting fatigue should be careful. Scrumban can quietly reintroduce the same ceremonies. If the team goes this route, keep sessions short and drop anything that does not change a decision.
Moving from kanban to scrumban in small steps
The safest path is to add one practice at a time and keep it for at least two or three cycles before adding the next.
Step 1: add a ready column
Insert a column between Backlog and In progress called Ready. Give it a limit, for example twice the number of people on the team. Only refined items with clear acceptance go in. People pull from Ready, never directly from Backlog.
This single change often solves the "what to work on next" problem without any new meeting.
Step 2: add a short planning session on a fixed day
Once a week or once every two weeks, spend thirty minutes filling the Ready column from the backlog. The goal is to order work, not to commit to a list. Keep the session short enough that nobody minds attending.
Step 3: close each cycle with a quick review
At the end of each cycle, filter the Done column for items finished in that period. Look at what was completed, what stayed in progress longest, and what one change to try next. Fifteen minutes is often enough.
Step 4: decide whether to track a cycle marker on cards
Some teams add a label or custom field with the cycle name to each card when it is pulled. This makes it easy to see which items span several cycles. Others find the Done column filtered by date sufficient. Choose whichever the team will keep up.
Step 5: review the WIP limits
With a planning rhythm in place, revisit the limits. Many teams find they can lower them slightly, because clearer priorities reduce the temptation to start extra work.
The getting started guide covers the basic board setup these steps build on.
What a tool needs to support scrumban
Scrumban does not require a specialized tool. A board with a few specific capabilities is enough.
Custom columns and limits. The team needs to create a Ready column and ideally see when a column exceeds its limit. If the tool does not enforce limits, writing the number in the column name works as a visible reminder.
Labels or custom fields. These carry the cycle marker, the type of work, and any urgent flag.
Filters by date and field. Reviews depend on filtering finished items by period.
Comments on cards. Refinement discussions belong on the card, so the context is there when the item is pulled.
A calendar or timeline view helps when stakeholders ask for dates. The same cards shown on a timeline let the team give a forecast without maintaining a separate schedule.
Archiving. Finished cards should be archived rather than deleted so past cycles remain searchable.
Most general kanban tools cover these. Teams comparing tools can see how views and limits differ on the features page and in the comparison with Trello.
Common mistakes when adopting scrumban
Locking the cycle scope. Once the team treats the Ready column as a sprint commitment that cannot change, it has moved to Scrum without Scrum's safeguards. Keep the ready queue reorderable.
Dropping WIP limits. Some teams add planning and quietly stop respecting limits, because planning feels like enough control. Without limits, the flow degrades within weeks.
Adding estimation too soon. Counting items finished per cycle is usually a good enough forecast for a small team. Introducing story points at the same time as a new cadence changes two things at once and makes it hard to see what helped.
Holding every Scrum ceremony. Daily standups, planning, review, and retrospective all at full length can take a noticeable share of a small team's week. Scrumban works best when each meeting is short and clearly tied to a decision.
What to change first
Add a Ready column with a limit between Backlog and In progress, and run it for two cycles before adding anything else. If the backlog still feels unmanaged after that, add a thirty minute planning session on a fixed day. For teams that want a board with columns, labels, filters, and a timeline view of the same cards, Pinateca is free for up to five people and ten boards.
Q1. Is scrumban just kanban with sprints?
Not exactly. Scrumban keeps kanban's board and work in progress limits and adds a regular cadence for planning and review. Unlike Scrum sprints, the work selected for a cycle is usually a reorderable ready queue rather than a locked commitment.
Q2. Does scrumban need a Scrum Master or Product Owner?
No formal roles are required. Many small teams simply agree on one person who keeps the backlog in order and another who keeps the planning session short. If those responsibilities are clear, titles are optional.
Q3. How long should a scrumban cycle be?
Most small teams use one or two weeks, because that is long enough to finish meaningful work and short enough to react to changing priorities. Some teams skip fixed cycles and plan whenever the ready queue falls below a set number of items.
Q4. Can a support team use scrumban?
It can, but plain kanban is often a better fit for support and operations work that arrives unpredictably. If a support team also handles planned improvement work, a split board with a kanban lane for tickets and a scrumban lane for planned work can serve both.
Q5. What is the quickest way to tell whether scrumban is helping?
Compare the number of items finished per cycle and the number of items stuck in progress for more than one cycle, before and after the change. If more work finishes and fewer items stall, the structure is helping. If neither moves after three cycles, remove the practice that was added last.
