Agile League - Scrum vs Kanban, Part I

15 Dec 2017

Kanban vs Scrum illustration

IT world needed their own Justice League. Superheroes who would save the world of software development. This is how Agile League was formed and how Scrum and Kanban became Superman and Batman in the software development process. But before we go into detail about both of them, let's just take a step back and see how it all began...

Back in the late 80s and 90s, the whole IT community realized that they needed a different way to organize software development process. Perhaps the most significant trigger for agile transformation was the book The New New Product Development Game published by Hirotaka Takeuchi and Ikujiro Nonaka in 1986.

The book mentioned a new way of working to build new products. It was based on concepts like self-organizing project teams and transfer of learning. This system is a foundation of agile methodologies and frameworks today. Though words Kanban or Scrum were not yet mentioned, many of the practices like waste management, process optimization, and many others were. From then on other companies had rapidly adopted an agile way of working and started a transformational journey.


How does “being agile” look today?

Today, we can witness and compare the results in the software industry. We can see the number of failed projects is significantly reduced, while the number of successful ones is increased. Interestingly, we also see that even with the use of Agile, the number of challenging projects is still significant. This means that neither Scrum nor Kanban (or any other methodology or framework) should be understood as a silver bullet that will solve all your problems.

Scrum and Kanban are used as tools for organizing the software development process. Scrum is based on predefined events, roles, and artifacts that should guide the software teams and business owners to organize the process of software development and delivery. Kanban is a simple visualization method based on JIT (“Just in time”) philosophy used in Toyota Production System (as a matter of fact, this later became known as Lean Manufacturing in the U.S.).


Which of the two is “better”?

First, both are based on the same agile principles. The 12 agile principles are well described in Agile Manifesto and will not be elaborated here.

To compare the two, let’s set up a framework for comparison. We will compare the two across the intersecting points given in the table below:





Structure and rules

Scrum (being a framework) prescribes 3 roles, 4 artifacts and 4 events with specific goals. Scrum also facilitates specific values, and specific rules like the allowed team, length, and frequency of meetings, etc.

Kanban (being a method) leaves almost all processes for the team to define. Visualization of workflow and optimization of team’s throughput is emphasized by Kanban.

Process control

Based on Empirical Process Control theory, meaning that due to complex inputs and process, outputs cannot be reliably determined. Scrum relies on the team’s experience and Scrum Master’s guidance to tweak the process and optimize the workflow and delivery in a sprint.

Based on the Little’s Law (or Queueing theory). The idea is that following and tweaking basic parameters (like the number of items that are in “work in progress”) should optimize the output of the team and visualize the bottlenecks (or impediments in Scrum).

Iterations and Release management

Scrum has predefined iterations called Sprints, during which the project is being developed and eventually delivered. Therefore, planning is done on a Sprint level, meaning that that user stories need to be prepared up front for the team to commit to. The release is planned for the whole increment.

Kanban is iterating on user story level. As soon as there is an available slot in the “work in progress” column, the team pulls another story from the backlog and starts working on it. Each user story should be releasable as soon as it goes through the whole workflow.

Metrics and productivity

Scrum metrics include burndown charts and velocity. The first one is used to inspect the progress of the current sprint, while the velocity is used as a trend to inspect how Scrum team is progressing.

Kanban metrics are based on cumulative flow chart and control chart. What should be tracked is, the arrival time (how fast requirements are coming), the cycle time (how fast ready user stories are built), and the average arrival and departure rate (also known as throughput).


This is the first part of our Scrum vs. Kanban series. In the meantime, check out and join our Facebook group where you can share your experience about using Kanban and Scrum.