1 Overview
Scrumban is a hybrid way of working that keeps a regular planning rhythm while running day-to-day work on a pull-based board. It borrows the sprint container, roles, and inspect-and-adapt ceremonies from Scrum, then layers on Kanban's visual workflow, explicit work-in-progress limits, and continuous flow. The result is not a third fixed method with its own rulebook. It is a deliberate blend that teams assemble when pure Scrum feels too rigid and pure Kanban feels too loose.
The method assumes that work arrives at different times and in different sizes, so forcing everything into a single sprint batch can create idle time or overload. Instead, Scrumban uses a cadence to set direction and a board to control daily movement. Planning still happens on a schedule, but the board decides what can actually start. That combination gives teams a predictable heartbeat without pretending that all work is equally plannable.
Because Scrumban is a blend, its identity depends on local choices. One team may keep two-week sprints and a strict sprint review, while another may use a monthly planning cadence and release continuously. The shared thread is a visible workflow with limits, a regular moment to reflect and adjust, and a willingness to change the board when the work changes. That flexibility is the point, and also the main risk.
2 The problem this method was built to solve
Scrum works well when a team can forecast a batch of work, commit to a sprint goal, and finish that batch inside a fixed timebox. But many teams face interrupt-driven work, support requests, urgent defects, or a stream of small items that cannot wait for the next sprint boundary. When those teams force everything into a sprint, they either break the sprint commitment repeatedly or create a large queue of work that ages while waiting. The ceremony remains, but the predictability it promised disappears.
Kanban solves the interrupt problem by letting work flow continuously and by limiting how much is in progress at once. But pure Kanban can leave teams without a shared planning horizon, a clear goal for the next period, or a regular moment to step back from the board and improve the system. Work moves, yet direction can drift. Teams may also struggle to communicate progress to stakeholders who expect a cadence and a review point.
Scrumban was assembled to hold both needs at once. It keeps a cadence so the team can plan, review, and improve together, and it keeps a pull-based board so work can start when capacity allows rather than when a batch begins. The problem is not that Scrum or Kanban is wrong. The problem is that some work is neither fully predictable nor fully interruptible, and a blended approach gives teams a way to manage that reality without abandoning either discipline.
3 How one cycle runs, from ready to done
A cycle begins with a planning or replenishment session. The team reviews the ready queue, confirms the goal for the coming period, and pulls only as many items as the board's limits allow. Unlike a strict sprint plan that assigns every hour, a Scrumban plan sets direction and selects a starting set. The board's columns, such as ready, in progress, review, and done, define the stages that work must pass through. Each column has a work-in-progress limit, so no stage can be flooded.
During the cycle, daily standups focus on flow rather than status reporting. The team asks where work is stuck, which limits are being tested, and whether anything needs to be swarmed or split. When an item finishes and a slot opens, the team pulls the next ready item. If an urgent request arrives, the team can choose to pull it in, but only by respecting the limits and making the trade-off visible. This is the core difference from a sprint backlog that is fixed at the start.
At the end of the cadence, the team holds a review and a retrospective. The review looks at what actually reached done, what is still in progress, and how the flow behaved. The retrospective examines the board itself: were limits too tight, too loose, or ignored? Did work wait too long in one column? The next cycle then adjusts the board, the limits, or the goal. Done means the item meets the team's definition of complete and has left the final column, whether that happens mid-cycle or at the boundary.
4 Roles and how they divide the work
Scrumban usually keeps the product owner role from Scrum. This person owns the ordering of the ready queue, clarifies what done means for each item, and protects the team from a flood of competing priorities. The product owner does not assign daily tasks. Instead, they keep the next few items ready and make trade-offs visible when new work arrives. In a flow-based setting, that means continuously grooming the queue rather than doing all preparation before a sprint.
The Scrum master role often becomes a flow facilitator or service-delivery manager. This person watches the board for bottlenecks, helps the team respect work-in-progress limits, and guides the retrospectives. They also coach the team on when to pull new work and when to stop starting and start finishing. The role is less about enforcing Scrum rules and more about improving the system that delivers work.
The team itself remains cross-functional and self-managing. Members pull work rather than receiving assignments, and they are expected to swarm on items that are close to done or stuck. Some teams define a separate review or quality role, but Scrumban does not require one. The division of labor is by workflow stage and skill, not by job title. A healthy Scrumban team shares ownership of the board, the limits, and the outcomes, which means anyone can raise a concern when flow breaks down.
5 Artifacts worth keeping
The most important artifact is the board itself. A Scrumban board shows the stages work must pass through, the items currently in each stage, and the explicit limits on how many items may occupy a stage at once. The board is not a status report for managers. It is the team's working model of the process, and it should change when the process changes. Columns that no longer reflect reality should be removed or renamed.
A ready queue, sometimes called a backlog, holds items that are prepared enough to pull. Unlike a sprint backlog, it is not a fixed commitment for a timebox. It is a prioritized set of options with enough detail to start. The product owner keeps it ordered and refined. A separate sprint goal or cycle goal can still exist, giving the team a shared direction even when the exact set of finished items is uncertain.
Flow metrics are also worth keeping. A cumulative flow diagram shows how work accumulates in each stage over time, making bottlenecks visible. Cycle time and throughput help the team understand how long items take and how much work completes in a period. These are not performance targets for individuals. They are feedback for the system. Finally, a definition of done and a working agreement about limits and pull rules keep the method honest. Without those, the board becomes decoration and the cadence becomes an empty meeting.
6 Where this method breaks down
Scrumban fails when teams use its flexibility to avoid discipline. If work-in-progress limits are ignored whenever a manager applies pressure, the board stops controlling flow and becomes a picture of overload. If the ready queue is not refined, people pull unclear items and stall in the middle of the workflow. If the cadence is treated as optional, the team loses the regular review and retrospective that would catch these problems. The blend then becomes the worst of both methods: Scrum ceremonies without commitment, and Kanban flow without limits.
Another failure mode is unclear priorities. In Scrum, the sprint goal resolves many conflicts for a fixed period. In Kanban, the queue order and pull rules resolve them continuously. Scrumban needs both, and if the product owner does not actively manage the queue, the team faces competing demands with no clear rule for what comes next. Urgent work can also become a loophole. If every request is treated as an exception, the limits are meaningless and the cycle goal is abandoned.
Finally, Scrumban can struggle with stakeholder expectations. Some organizations want a fixed scope and date, which a pull-based board does not promise. Others want continuous delivery but still demand sprint-style reporting. The method requires honest communication about what is predictable and what is not. It also requires patience, because tuning limits and columns takes several cycles. Teams that expect a ready-made process will be disappointed. Teams that treat the board as an experiment will learn faster.
7 Frequently asked questions
Is Scrumban just Scrum with a Kanban board? Not exactly. A Scrum team can use a board without changing its commitments, but Scrumban changes the commitment model. Work is pulled as capacity opens, not assigned at sprint planning and frozen. The cadence remains, but the scope is expected to change. If your team still commits to a fixed set of items for the whole sprint and refuses to pull new work, you are practicing Scrum with a visual aid, not Scrumban.
Do we still need sprints? You need a cadence, but it does not have to be a traditional sprint. Many teams keep one- to four-week cycles for planning, review, and retrospective. Others use a monthly planning cadence with weekly flow reviews. The important part is a regular moment to inspect the system and adjust. Without a cadence, Scrumban loses the shared direction that distinguishes it from ad hoc Kanban.
How do we choose work-in-progress limits? Start with the team size and the workflow stages, then lower the limits until work starts to queue. If a stage is always full and items wait, the limit may be too high or the stage may need more capacity. If people are idle, the limit may be too low. Treat limits as experiments, not permanent rules. Review them in the retrospective and change them when the data suggests a better setting.
Can Scrumban work for support or operations? Yes, that is one of its common uses. Interrupt-driven work benefits from pull and explicit limits. The main caution is to separate planned improvement work from reactive support work so that urgent items do not permanently starve the former. A visible policy for how urgent work enters the board helps keep the system honest.