Agile Zone is brought to you in partnership with:

I’m passionate in all things Agile, specifically Scrum and Kanban, and like to think beyond what the 'guide' said. I’ve had enterprise and consultancy experience as a Business Analyst & Scrum Master. Gerry has posted 4 posts at DZone. You can read more from them at their website. View Full User Profile

When to dump Scrum for Kanban

  • submit to reddit

So your team has decided to go ‘Agile’ and everyone has read a copy of the Scrum Guide.

You’ve done a few Sprints, things are moving fast and the team generally feels like they are more empowered, until…

The CEO/Manager walks into the room and asks to add X, Y and Z into the Sprint.

As the team at Stormpath quite simply put it, that behaviour causes:

Change Management Soup

Sound familiar? You’re not alone. (Or maybe it’s just my personal experience…)


Image courtesy of jesadaphorn /

These ‘small’ changes to your Sprint Backlog result in a few (negative) outcomes:

  • Invalid team velocity
  • Meaningless Sprint Planning
  • Increased context-switching

These things happen because Scrum works when predictability is high, and if you’re not being predictable, well… you saw what can happen above.

Let me reframe the problem, ask yourself this question:

“If I can’t commit to work in a time box as large as a Sprint, why am I planning for Sprints?”

A major factor in your choice of Agile framework/methodology depends on the ‘Reaction Time’ your team needs in order to change their currently agreed scope of work.

  • For Scrum, the agreed scope is the Sprint Backlog (1, 2, 3 or 4 weeks long)
  • For Kanban, the agreed scope is staying within your WIP limit threshold(s)

In a nutshell:

Go away from Scrum if your Sprint Duration is shorter than the time you need to react

i.e. Sprint Duration < Reaction Time


Image courtesy of jesadaphorn /

If you’re using Scrum and need to react faster either:

  1. Reduce Sprint duration
  2. Educate your Product Owner and stakeholders
  3. Realise Scrum isn’t for you

Numbers 1 and 2 are pretty self explanatory, but what about number 3? I would suggest going down the Kanban route.

Focus over Speed

Kanban is useful when requirements and priorities change quickly and often. This becomes evident in teams who can see that their Sprint Planning doesn’t quite hold up for the entire Sprint duration. Kanban helps you react faster, but…

Contrary to popular belief, in Kanban, it’s not only about reacting faster, it’s about being:

closer to a state of Zen

But how do you get there? Simply prioritise:

focus over speed

To Focus is to Swarm

So how do teams focus? They swarm (refer to this comic for an awesome explanation).

In the agile world, swarming is when “the whole team works together on the same problem“. This means that team’s tasks should be done in their entirety before new ones are taken on-board by the team.

One way that Kanban helps do this is by enforcing WIP limits.

ant swarm

Image courtesy of SweetCrisis /

Urgh, where did all my planning go?

Never fear, cycle time has got you covered.

Cycle time is the time it takes from starting a piece of work until it is done.

By calculating the average cycle time of tasks that share the same estimate for completion, you can get a fairly accurate understanding of how long it takes to deliver a similarly sized task. Therefore, average cycle times take away the guesswork (that velocity uses) when planning for releases, as it does not bundle the measurement of task duration in the context of a sprint, but rather it measures tasks individually.

It’s almost counter-intuitive because:

Less upfront ‘planning’ leads to more accurate ‘release planning’

Pretty cool, right?

React to your situation

If you need to react fast, consider whether you’ll get more out of your development teams when using Kanban to manage their delivery.

You might just find that you can react faster, plan better and get more done.

Published at DZone with permission of its author, Gerry Claps.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Bob Jones replied on Wed, 2014/08/06 - 9:55am

Great write up!

My small team of devs recently switched to Kanban from Sprints. We love it, because our tasks were so volatile and unpredictable. Kanban allows us to switch tasks when we need, without feeling guilty that we will fail at the end of the "timeblock".

I can see how Sprints would work better for many teams, but for us Kanban was the ticket. (Just don't forget to do your cadences on a routine, or disorganization and confusion can set in quickly.)

Gerry Claps replied on Sun, 2014/08/10 - 9:18am in response to: Bob Jones

Thanks Bob!

That's exactly right, Kanban helps you better cope with situations that require you to have the ability to change often.

It's great to hear Kanban is working for you and your teams.

Robert Mead replied on Tue, 2014/08/12 - 9:27am

Excellent advice.

Another time to consider switching to Kanban is when the team has dependencies for information from others outside the team, a lot of them. This sort of situation kills predicitability because often people not on your team have other priorities and will not respond on your timetable even if you start working a sprint ahead. I switched a struggling team from Scrum to Kanban and the results were dramatic. The cycle time did not improve much, but the throughput increased because of a focus on getting work done.

Gerry Claps replied on Tue, 2014/08/12 - 6:34pm in response to: Robert Mead

I really like the dependencies situation, thanks Robert!

It's another great reason to switch, and now that I think about it, it was especially evident in an enterprise agile setting I was previously in.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.