What is Scrumban?

We know Scrum and Kanban as flavors of Agile. Scrum is best-suited for products and development projects. Kanban is best for production support. We use Scrumban – which combines the best features of both – for maintenance projects. Scrumban is becoming very popular these days in service industries, where we have both development and maintenance projects.

Scrum in a nutshell:

Kanban in a nutshell:

The workflow

A direct consequence of this difference in rules is the way the work items are handled across time.

In Scrum, you select the work you’ll be doing for the next sprint beforehand. You then lock the sprint, do all the work, and after a couple of weeks – the usual sprint duration – your queue is empty.


In Kanban, all that’s limited is the size of the queues, called the WIP limit. This means that you can change the items in the queues at any time, and that there’s no “sprint end”. The work just keeps flowing.


Scrumban = Scrum + Kanban

With the Kanban’s pull system in place, our flow will become smoother as our process capability improves. We can use our inter-process buffers and flow diagrams to show us our process weaknesses and opportunities for kaizen. As we get closer to level production, we will start to become less concerned with burndown and more concerned with cycle time, as one is the effect and the other is the cause. Average lead time and cycle time will become the primary focus of performance. If cycle time is under control and the team capacity is balanced against demand, then lead time will also be under control. If cycle time is under control, then burndowns are predictable and uninteresting.

Since the team now pulls work into a small, ready queue before pulling it into WIP, the team’s perspective of the iteration backlog’s utility is that it always contains something that is worth doing next. Therefore, we should use the least wasteful mechanism that will satisfy that simple condition.


A simple mechanism that fits the bill is a size limit for the iteration backlog. Rather than going through the trouble of estimating a scope of work for every iteration, just make the backlog a fixed size that will occasionally run to zero before the planning interval ends. That’s a simple calculation.

In Scrumban, we can do iteration planning at regular intervals, synchronized with review and retrospective, but the goal of planning is to fill the slots available – not fill all of the slots, and certainly not determine the number of slots. This greatly reduces the overhead and ceremony of iteration planning. Time spent batch-processing for iteration planning estimation can be replaced with a quality control inspection at the time that work is promoted to the ready queue. If a work item is ill-formed, then it gets bounced and repeat offenders get a root cause analysis.


When to consider Scrumban

Scrumban Backlog

Scrumban Board


Kanban vs. Scrumban


Scrum vs. Scrumban



Kanban is compatible with Scrum, the project management method. Adding WIP and visualization to Scrum, i.e. Scrumban, helps improve Sprint Commitment effectiveness. However, it is also introduces the WIP limit as a mechanism to catalyze incremental changes. The WIP limit obviates the need for commitment to drive change, reduces any dysfunctional reliance on heroic effort, and improves overall systems thinking when considering potential improvements. It looks somewhat like Scrum at the practice level, but at the cultural level it will look like Kanban – soft evolution rather than shock treatment and revolution.