scrumban

Scrumban – Do we still need Sprints?

The buzz about Kanban has been picking up good pace lately, mostly owing to challenges faced by new Agile teams in their Scrum adoption journey. The same is equally true about Scrumban. In my Kanban training sessions, whether they last one hour or two days, the question almost always pops up – What exactly is Scrumban?

Before one delves into Scrumban, it is important to understand the key essence of Scrum and Kanban both. If I were to share my understanding of Scrum and Kanban in a single phrase, I would say Scrum is about "building self-organizing teams" and Kanban helps you implement "smooth flow of work". While some may see them as competing process frameworks, it is common and quite practical to combine them both - and the result is Scrumban (sometimes also spelled as Scrum-ban).

But, how much of Scrum and how much of Kanban? Is there a secret recipe for Scrumban?

While complete books have been written to explain in detail the idea of Scrumban, I feel Scrumban is not really complicated once you understand Scrum and Kanban, Kanban Method to be more precise.

Below is one basic combination many teams start with:

=> What comes from Scrum?

  • Roles – Product Owner, Scrum Master, and Dev Team
  • Requirements management – Capturing requirements using user stories, and possibly using story points for estimation.

=> What comes from Kanban – Flow of work

  • Stories move across the board as a unit. No need to break them down into tasks as the columns represent tasks, though at a higher level of granularity.
  • WIP limits may be defined to limit the number of stories in progress at a given time.

But, the key question still remains – Do we use a strict time-box (Sprints) in Scrumban, or not? And, what about Scrum ceremonies?

Some experts (and books) have suggested continuing with the time-box and keeping the ceremonies intact. While there may not be anything wrong with that approach if it works for you, I feel continuing with a strict time-box does not allow one to utilize the real power of Kanban.

Personal preferences aside, whether one should use a strict time-box in Scrumban or not would depend on what has been your pain point with Scrum. If dynamic requirements are known to cause scope creep during your sprints or your new Agile team often finishes sprint with hanging/unfinished user stories, or you feel team members are not optimally utilized during your Sprint, it may be time to explore Agility outside the time-box.

While Roles and requirement management may still come from Scrum, here is how the Kanban flow gets refined in a Scrumban implementation without Sprints:

=> Kanban Flow of work:

  • Stories still move across the board as a unit. No change here.
  • Continuous Flow – Since there is no batching of requirements, work keeps coming into the system and keeps leaving the system.
  • WIP limits – defined at activity level (column) to control the flow of work which in turn reduces multitasking and improves lead time.

What about the Scrum Ceremonies? Do we still need them?

While the team may use Daily Standup from day one, other ceremonies may be adopted by the team slowly – in line with Kanban’s idea of evolutionary change. Below is how the ceremonies might shape up in due course of time:

  • Sprint Planning – The first part of Sprint planning gets morphed into Replenishment Meeting. The second part of Sprint Planning is redundant as there is no need to break a story into tasks.
  • Daily Scrum – Gets transformed into Daily Kanban. Still under fifteen minutes, but will run quite different than each member answering three standard questions.
  • Sprint Review – Of course, we still believe in faster feedback cycle and want our customer to review the product sooner than later, but let’s call it “Product Demo” since there is no Sprint. And, you may use a cadence that works with the team and the customer – weekly, fortnightly or completely on demand.
  • Retrospective – Scrum or not, Agile or not, the idea of continuous improvement is always useful. Since there is no Sprint, how often we retrospect is entirely up to us. If once in two weeks feels too much, you are free to try once a month.

Now, some may argue Scrumban without Sprints is more of Kanban and less of Scrum. Well, what difference does it make? As a team member (or Agile Coach) all I want is a work discipline that helps the team create and deliver business value to the customer in a cost-effective manner, without compromising quality!

And, if one is still worried about the use of words, they are free to call it “Scru-nban”, “Scr-anban” or “Flow-Scrum”.

Leave a Reply