Get certified - Transform your world of work today


Bringing Order to a world of Chaos – Scrumban Style

2 October 2017

Krishna Sagar B V

Have you or your customers or business partners ever made these complaints?
  • My change requests or features are usually urgent and cannot wait for the next sprint to start.
  • My business scenario is quite volatile, and I might change my direction in one to two weeks’ time; I need flexibility to accommodate the change immediately.
  • I have a high-profile, critical application whereby people report several problems that need to be solved and deployed quickly, and the time I reserve in a sprint is not sufficient to address most of them.
  • My platform supports several groups of stakeholders who have their own cadence and working habits and provide requests at varying priority and urgency. Fitting everything into a sprint sometimes is not feasible.
  • I have a high number of changes coming my way at any point in time, and I must meet a strict service level agreement (SLA) to service them.
If you have heard any of these complaints or can relate to any of them, read on!

Although in several enterprise scenarios you can work with your customers to educate and guide them through the Scrum development process, not all customers can do this owing to their business environment. Force-fitting Scrum into these kinds of scenarios drives one toward a general perception that Scrum doesn’t work, when the truth is that Scrum was not designed to work in such scenarios.

For all the complaints mentioned, the team needs to broadly meet the following two objectives:
  1. Business expectation of a quicker turnaround time for high-priority user stories and bugs for an existing product/platform in the market.
    • Develop a faster go-to-market process for small changes.
    • Resolve bugs/issues within a defined SLA.
    • Support ad-hoc urgent requests coming in during a sprint.
    • Support multiple businesses and stakeholders, each having their own cadence.
  2. Add a significant feature set to the existing product/platform or develop the next version of your product/platform while you support an existing one, both of which require significant commitment from the team, a sense of purpose, and a timeline.

Why Scrum and Kanban will not work

Scrum prescribes no changes to scope while the sprint is underway. As a result, the team defers the implementation of any new changes and ad hoc requests that require quick turnaround to subsequent sprints. This leads to customer dissatisfaction.

While Kanban can solve the problem of reacting to frequent changes and bugs, substantial delays can exist for new or existing product development, as the team usually loses sight of specific targets and milestones. The loss of focus is attributable to the lack of timeboxing against which the team usually works, which Scrum provides.

Scrumban as the solution

Scrum lends itself very well to incorporate nuggets from other Agile and Lean methods, which is where Scrumban originates as a method. Scrumban is a management framework that leverages Scrum as a preferred way of working and uses Kanban to continuously improve on how the team works and delivers. Scrumban as a process takes the best of both Agile (Scrum) and Lean (Kanban) methods and becomes the middle ground between Scrum and Kanban approaches.

Some of the teams I have worked with adopted one of the flavors of Scrumban by 1) combining the boundaries of the sprint from Scrum to enable the standard product development work to proceed as planned, and 2) by applying the work-in-progress resource limits of Kanban to handle frequent changes, and high-priority work items and bugs. This allowed the teams to take on ad hoc, unplanned, frequent work without having to adjust for sprint boundaries.

The team composition that was adopted was 60–40 for Scrum and Kanban work respectively, and had weekly planned releases when any completed/signed-off work items from either the Scrum or Kanban track were deployed. The team further matured to be flexible on the composition as well as the release on a need-only basis outside of the weekly production cadence.

This capability to deploy at will was achieved through an excellent, rigorous engineering process and adopting best practices, such as continuous improvement, automated regression, and automated deployment.


The Scrum aspect of Scrumban provides the following benefits:
  • Use of Scrum to complete all new product development work
  • High-quality product development and delivery
  • Engineering excellence and best practices, leading to product stability
  • Continuous improvement through retrospectives and sprint reviews
  • Continuous sustainable pace for the team to churn out work
The "ban" aspect of Scrumban provides the following benefits:
  • Quicker feedback loops, leading to customer satisfaction
  • Waste minimization
  • Lead-time reduction and accelerated go-to-market by improving efficiency
  • Greater flexibility for picking up ad-hoc work items

When to apply Scrumban

Below are some of the scenarios when you would apply Scrumban:
  • A project has many unexpected ad hoc changes that are time sensitive and usually urgent.
  • Priorities are constantly changing.
  • The work is event-driven, such as help desk support, whereby priorities shift constantly.
  • The team is focused on building a new product from the ground up while also supporting an existing product.
  • Some of the rigidness of Scrum is limiting your team’s ability to adapt to change.
  • You want to limit large-scale disruption to your ways of working, so you require an intermediate step to your transition to Kanban.
  • You have a heavy in-flow of support or production tickets with an expectation of quick turnaround time along with the usual heavy new feature building.
Comparison of Scrum vs. Kanban vs. Scrumban
  Scrum Kanban Scrumban
Iterations/Timeboxes Required None Optional
Team Roles Defined None As needed
Visualization Burn-down charts Kanban boards As needed
Ceremonies All Scrum ceremonies As needed Stand-up, on-demand planning
Estimating Required (story points) Optional As needed
WIP Sprint boundaries Resource limits Both
Change Welcomed, next sprint Instantaneous based on resource availability Instantaneous based on resource availability
Commitment Required None Optional
Scope Limits Velocity/sprint limits WIP limits WIP limits
Rules Constrained & descriptive Least constrained & least descriptive Moderately constrained & moderately descriptive
Applicability Product development Support, maintenance Fast-paced projects, multiple stakeholders and expectations.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4 (4 ratings)


Shane Billings, CSP,CSM,CSPO, 10/5/2017 7:23:00 AM
Scrumban, to me, can be a dangerous thing for a team. I may not be popular by saying this, but my experience shows that Scrumban hides problems for the team.

I once had a team that wanted to do Scrumban. Why? Because it took them so long to integrate that they could not predict what would happen. Why? Because they had so many bugs. Why? Because they were using waterfall methods to integrate at the end.

This team used Scrumban to ignore proper principles of Agile. Often, the primary argument of Scrumban is unpredictability. If we analyzed why we are unpredictable, we might be able to fix the interruptions and bad practices that lead to it.

To be fair, there are times that we cannot become predictable. Scrumban works in those cases. But my experience, more often than not, is that it is used as a crutch.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up