The same, even though they're different.

The same, even though they’re different.

I got into a discussion recently about what make Scrumban, Scrumban.  I was discussing the concept with two other Scrum Masters whose teams were using Scrumban.  The problem?  The two implementations looked nothing like each other.  One had two week sprints and the other had no sprints, but rather featured continuous delivery.  Both of my friends are convinced they are doing Scrumban.  And they both are correct.

Scrumban is a hybrid creation that combines Scrum and Kanban.  There are very few rules that say that which attributes of each technique must be present to be one or the other.  Any combination of the two techniques can be called Scrumban.

Kanban to Scrum
Kanban to Scrum

Here are some the of similarities and differences between Scrum and Kanban:




Partial Visualization (Input, Output and In Process)

Full visualization

Full Visualization (Granular Process)




Time boxed Iterations

Depends on Iteration Decision

Continuous Flow

Sprint Planning

Depends on Iteration Decision

Dynamic Planning

Work Sized To Sprint

Depends on Iteration Decision

Work Minimally Size
(Sized for Flow)

Board Reset After Sprint

Depends on Iteration Decision

Board Persistent

Burn-down (Burn-up) Charts

Depends on Iteration Decision

Cumulative Flow

Management As Outsiders

Depends on Iteration Decision

Management As Insiders

The one (huge) requirement for any Scrumban implementation is the need to fully visualize the steps in the workflow.  The biggest hybridization decision is reflected in the decision of whether to leverage sprints or continuous flow as the central mechanism to control work.  A decision to use iterations will cause the team to leverage a number of other techniques from Scrum – making the version of Scrumban more Scrum like.  For example, if you choose iterations, then some form of sprint planning will be required and work will need to be sized so that it can be completed within the sprint. On the other hand, focusing on a continuous flow of sprints will require the team plan dynamically so that work can be added as capacity dictates and to use cumulative flow diagrams to monitor progress rather than burn-down charts.  The choice of sprints or continuous flow becomes a decision of how you are using process to influence behavior.

Scrum has an expectation of bounded, well-formed teams.  Scrum teams are cross-functional with members playing many roles depending on the need.  Teams are also expected to be self-organizing and self-managing.  Some organizations either can’t commit to this this type of structure or need time to transition.  Hybridizing Scrum by de-empathizing use of well-formed, cross-functional teams for specialists may make it easier to begin the transition towards a more Agile structure.  Is this an optimal solution? No. However it isn’t an equilibrium solution; left to its own devices no organization be able to hold this solution for long. In my experience, as teams learn how to interact within an Agile environment they will find innovative ways to embrace the Agile values and principles. Embracing these ALWAYS leads to an environment with stronger teams.