How many times have you heard people arguing about which one is better – Kanban or Scrum? Probably a lot, especially if you are in the product development business. This argument is not new and you can hear it at pretty much every business summit that puts together people who are managing projects.

Objectively speaking, you can benefit from both. So to answer the question for yourself, you need to understand the difference between Scrum and Kanban. To do so, we have prepared an in-depth comparison that we hope will come useful.

Difference Between Scrum and Kanban

Kanban is a Lean method that contains 6 core practices designed to help you achieve continuous process improvement:

  1. Visualize the workflow

  2. Limit work in progress

  3. Manage flow

  4. Make process policies explicit

  5. Establish feedback loops

  6. Improve collaboratively

Implemented together, they allow you to reduce wasteful activities in your process and improve the overall efficiency of your workflow.

Scrum is part of the Agile framework. When developing products with it, work is managed through an iterative process called a Sprint. Each Sprint lasts from 1 to 4 weeks and can be considered a separate project.

Kanban vs Scrum – Roles

Kanban vs Scrum Roles

Scrum has a set of mandatory roles that you must implement:

  • Product Owner
  • Scrum Master
  • Team

The Product Owner is in charge of the backlog and gives direction to the team. The Scrum Master dictates the timelines, and the team processes the work that is agreed on during the Sprint planning.

Kanban allows you to keep your current structure without making drastic changes. Still, there are two Kanban roles that you can implement, but are in no way mandatory:

  • Service Delivery Manager
  • Service Request Manager

The Service Delivery Manager is responsible for making sure that work items pass efficiently through the process by keeping an eye on the board and assisting team members when there’s a problem. In addition, the person in this role has to facilitate continuous improvement within the team and suggest improvement activities.

The Service Request Manager is usually a secondary role of the team manager. This stakeholder is responsible for managing the process policies and consistency, improving corporate governance and reducing the risk associated with a single individual.

Process Cadences in Scrum and Kanban

Cadences in Scrum and Kanban

Cadences are part of both Scrum and Kanban. Yet the way they are implemented is different.

In Scrum, they are defined by the length of each Sprint. A typical Sprint lasts 2 weeks. If every item that was chosen is completed, the Sprint is considered successful, and vice versa. After one iteration ends, the cycle is restarted immediately.

In Kanban, cadences are related mostly to meetings and are optional. As your goal is to maintain a continuous flow of work, cadences are a suggested network of meetings fostering proper bi-directional communication happening at all necessary levels of your organization.

Scrum vs Kanban Planning

Kanban vs Scrum Planning

Planning in Scrum happens iteratively at the beginning of each Sprint. It is facilitated by a dedicated meeting for the purpose. There, the team, Product Owner and Scrum Master gather to break down user stories into tasks.

Then, they estimate how much time would be required to finish everything on the list. When there’s an agreement, the team commits to finishing all items in the upcoming Sprint and starts working. If there’s a change of priorities mid-sprint, the current Sprint must be aborted and the planning process is restarted.

Although there’s a common misunderstanding that there’s no such thing as Kanban planning, the reality is completely different. The method relies on a probabilistic approach to planning, which is basically a prognosis based on past workflow data. It must be based on work types, size, classes of service and various other factors related to the work itself and not so much on the team that processes it.

In Kanban, your workflow is continuous. Therefore, it is a common practice to extend the Requested section of a Kanban board by adding roadmap columns like “This month”, “Next Month”, etc. to visualize planned work.

Try Kanbanize for Free

As a result, when there’s available capacity, your team just pulls a new work item towards “In Progress” according to its priority. Finally, when you know what’s the average time required to finish a task of a given type and size, and how many work items your team finishes per week, for example, you can plan the start and end dates of each task.

Commitment in Kanban and Scrum

Commitment in Kanban and Scrum

Kanban preaches deferring commitment as long as possible, to ensure agility and delivering value frequently, and at the right time. As WIP limits prevent team members to work on multiple tasks at once, everybody commits to finishing what they have started before engaging in new work.

In Scrum, the commitment for a Sprint is in the form of forecasting. When the team doesn’t anticipate their capacity accurately or unexpected problems arise, either the sprint fails or personal heroics are required to finish everything on time.

Core Key Performance Indicators

Kanban and Scrum KPI

When looking at the argument Kanban vs Scrum, you can’t ignore the key performance indicators (KPI) that are going to become part of your work life when you make a choice.

Scrum KPI

Scrum has two specific KPIs that you should focus on:

  • Velocity
  • Planned capacity

Velocity is based on actual story points completed, which is typically an average of all previous sprints. It is used to plan how many product backlog items the team should bring into the next sprint.

Capacity is how much availability the team has for the sprint. This may vary based on team members being on vacation, ill, etc. The team should consider capacity in determining how many product backlog items to plan for a sprint. If capacity is expected to be less for the sprint, the team has to consider taking on fewer items from the product backlog. Likewise, if more team members are recently added, the team may want to take on more product backlog items.

To keep a check on them, usually Scrum teams implement a couple of charts:

  • Burndown chart
  • Velocity chart

The Burndown chart is a visual representation of how much work remains to be completed versus the remaining amount of time in the Sprint. On the other hand, Velocity charts are usually in the form of histograms showing the past performance of the Scrum team.

Kanban KPI

In Kanban, the most important metrics are:

  • Lead time
  • Cycle time

Shortly explained, Lead time is the period between a new task’s appearance in your workflow and its final departure from the system. Think of it this way, Lead time starts ticking as soon as you commit to working on a task or customer order.

On the other hand, Cycle time begins at the moment when the new arrival enters the “in progress” stage and somebody is actually working on it.

Your goal is to reduce the values of each metric (which are usually measured in days) over time and keep your process efficient all the time. To keep a close eye on them there are two primary charts that you can implement:

The CFD will show you how stable your flow is and help you understand where you need to focus in order to make your process more predictable.

On the other hand, the cycle time histogram is a simple way to monitor your process performance over time.


Kanban vs Scrum Meetings

As we already stated, in Kanban meetings are optional. Still, if you decide to implement them, you can choose between 7 different types that will keep your team aligned:

  • Daily Meeting
  • Replenishment & Commitment Meeting
  • Delivery Planning Meeting
  • Service Delivery Review
  • Operations Review
  • Risk Review
  • Strategy Review

You can learn more about each of them from our dedicated article on the topic, but what’s important to understand is that you can combine them or skip those that you don’t find necessary. For example, we are doing the Service Delivery Review and the Replenishment & Commitment meeting together on a weekly basis. So as long as it works for your team, you’ve got the liberty to improvise.

Each Sprint cycle consists of 4 mandatory types of meetings:

  1. Sprint planning
  2. Daily Scrum
  3. Sprint review
  4. Sprint retrospective

Sprint planning is held at the beginning of each Sprint. If the Sprint cycle is 1 month, it is not unusual for these meetings to last up to 8 hours. After everything is delegated and committed, the team meets every day to discuss progress and shares any problems that occurred. At the end of each Sprint, the team and any relevant stakeholder meet to review what was achieved.  At last, the Retrospective is dedicated to analyzing what worked and what could be improved during the next iteration.

Kanban Board vs Scrum Board

Kanban board vs Scrum board

Visual management boards are applied in both Kanban and Scrum. However, there are some fundamental differences between them.

The Scrum board is an extension of the product backlog. When the team commits to a given amount of work, it is added to the Scrum backlog on the board, then the team starts putting work in progress at their will. The goal is to get everything in Done by the end of the Sprint. Logically, the board is reset after each iteration.

On the other hand, the Kanban board is a continuous map of the team’s process. When building it, your goal is to create a sustainable Kanban system that could stand the test of time. A proper Kanban board has WIP limits visualized on it. The goal is to control the amount of work that enters and leaves the process so that you can improve delivery speed.

What Is the Bottom Line?

We hope that now you are one step closer to understanding what Kanban and Scrum are about and how you can use them. Both methods may look very similar, but as seen above they have some major differences indeed.

Check out the following infographic to understand the basics and stay to the end for a more detailed comparison.

Kanban vs Scrum 2019

Try Kanbanize for Free

Share this Image On Your Site

Whatever method you pick, make sure it fits your company’s culture. This is the only way to get all the value they can bring.

Still, have in mind that Scrum is more difficult to scale across your whole organization. On the other hand, with the latest technological advancements, Kanban is becoming more suitable for managing complex projects on all company levels.


State of Scrum 2018 –
State of Agile 2018 –
State of Agile Marketing 2018 – AgileSherpas
Developers Survey 2018 –

Subscribe to our blog. Get each new piece of content straight into your mailbox.

Read insightful articles from top Agile/Lean thought leaders and our experienced team.

5 thoughts on “Kanban vs. Scrum: What Are the Differences Between Scrum and Kanban

  1. David Sabine


    I challenge you to create an infographic called “Scrum & Kanban” (rather than “Scrum vs. Kanban”) and I challenge you to list only good things about each framework.

    Your preference for Kanban is clear and therefore your infographic shows extreme bias — as well as being factually inaccurate! (Example: you claim the most important metric in Scrum is velocity — but “velocity”, the word, doesn’t even appear in the Scrum Guide.

      1. David Sabine


        The most important metric in Scrum is the ‘value’ delivered by the team. That’s not my opinion; rather it is expressed in a variety of ways throughout the Scrum Guide.

  2. Robert Falkowitz

    I am puzzled by two of the “cons” of kanban:
    “Often mistaken for simplistic visualization…” Surely this is not a problem of kanban itself, but rather a problem fostered by simplistic bloggers and by simplistic tool vendors trying to capitalize on the kanban wave (I do not include Kanbanize in that group!)

    “It is highly methodical by focusing on results, not people”
    As part of the lean approach to management, avoiding muri is extremely important for Kanban. I believe that it focuses on the people issues in the context of the various management loops. So I do not agree that Kanban focuses on results rather than people.

    1. Pavel N.

      Hi Robert,
      First, thanks for your feedback. Appreciate it.

      “Often mistaken for simplistic visualization…” – The point here is that people often look for easy wins and Kanban can appear as an easy win at first sight. And because of this people often don’t explore things in depth. Actually, I agree that this is not a problem of Kanban, but it is still a barrier.

      “It is highly methodical by focusing on results, not people” – You are absolutely right, avoiding Muri is extremely important for Kanban. The real power of Kanban for preventing overburden comes with the application of flow metrics and analytics, which are directly related to workflow performance. However, I acknowledge that the word “results” may sound misleading. What do you think if we change it for “process”, like “…focusing on process, not people”?

      Last, of course, it is all about improving people’s performance, but as Lean says we need to do it by focusing on processes. This is more in the context of “Don’t blame the people, blame the process”.

      Once again, thanks for being involved in the discussion.


Leave a Reply

Your email address will not be published. Required fields are marked *