Agile League - Scrum vs Kanban, Part II

21 Dec 2017

Scrum vs Kanban illustration

Last time, we introduced our superheroes - Scrum and Kanban. They took the software development world by storm and improved it significantly. However, there is one catch - Scrum is better suited for some projects while Kanban is better suited for the other ones. So the main question is: when should you use Scrum and when should you use Kanban?

Are Scrum and Kanban defined in the same way?

There are several differences regarding Scrum and Kanban. Let’s first mention all aspects covered by Scrum that are not explicitly defined in Kanban:

  • Refinement process
  • Continuous improvement process (Sprint retrospective)
  • Estimation and planning (Sprint planning, Daily standup)
  • Review of results (Sprint review)

Though Kanban does not deal with the process of getting from the concept to the Kanban board, the board itself can be modified in such a way to include different columns for user stories preparation phase. Collaboration with stakeholders is not emphasized, as opposed to Scrum through Scrum pillars, values and events. No special focus is given to team learning, work process or product improvements.

Even though estimation and planning are not required for a team to use in Kanban (or even specified), these can be highly valuable tools, especially if Kanban is applied to the development (not just maintenance). 


Do impediments exist both in Scrum and Kanban?

Impediments are also are slightly differently handled. In Scrum, Daily scrum is used to formally share the impediments. Afterwards, the team and/or scrum master needs to solve it according to the assigned priority. Retrospectives are used to discuss how to avoid a specific impediment next time.

In Kanban, a team should pay attention to the bottlenecks (impediments) in the process which limit their productivity. When a bottleneck is spotted, a team is usually swarming to resolve it as soon as possible so the normal workflow can be restored. To put it briefly, Scrum deals with impediments in a structural and long-term way, while Kanban tends to be a bit short-sighted.

So, there is no review of results, estimation or planning in Kanban?

It is important to understand that all the aspects mentioned above are not forbidden in Kanban, they are just not clearly specified, and a team has the freedom to implement them as they see fit.

While in Kanban none of the meetings are mandatory, it does not mean that team should not define regular time slots and do required activities such as discussing impediments, agreeing on improvements, or simply sharing the status of a certain user story.

Can a new team use Kanban?

If you are a new team, start off with Scrum and follow the rules until you feel more comfortable to improvise and adapt the process to your specific domain.


If you are already an experienced team, there is a good chance that you are quite familiar with the domain of the project, usual risks and challenges and that you have your internal team processes defined. In this situation, Kanban is a better choice since it will give you insights into your efficiency and bottlenecks.

Furthermore, Kanban offers much more modularity when it comes to the release process. If there is a need to release features to production as frequently as possible (every day for example), Kanban should be the right tool for you. If the release is less frequent and releasing a bundle of new features is preferred, Scrum suits your needs more. 

And if the priority changes?

Both are agile approaches and should be adaptable to change. However, if the environment is indeed very turbulent, Kanban teams will have more flexibility to adapt to change since Scrum does assume some level of stability during an iteration (otherwise planning and refinement process are useless).

For applications that are in maintenance and support mode, Kanban is also preferred since the majority of work will be around the investigation, troubleshooting and fixing. Also, work may come in an unpredictable fashion (e.g., production incidents). Scrum may be an overkill in such environments. 

What about scaled and complex projects?

Scrum really thrives in scaled environments, where the process becomes a must, and topics like alignment between multiple teams are crucial. For complex projects, requiring multiple teams to deliver functionalities simultaneously, Scrum may be a better choice. While Kanban can be scaled, it does not have well-defined guidelines and frameworks on how to do that successfully as Scrum does (e.g., LeSS, SAFe, etc.). 

Can I benefit from using both approaches?

Yes, you can! Kanban that is focused on waste management and bottlenecks fits perfectly as a tool to use within a single Scrum iteration. Also, the idea of Kanban can be applied to other processes in Scrum such as refinement process, continuous improvements, etc. To read more about this approach, you can check the agile method called Scrumban, which focuses on utilizing strengths from both approaches. 

What are your experiences with Scrum, Kanban, or Scrumban? We would like to hear your thoughts so don’t forget to join our Scrum Ninjas Facebook group and share your views with us.