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:
Visualize the workflow
Limit work in progress
Make process policies explicit
Establish feedback loops
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
Scrum has a set of mandatory roles that you must implement:
- Product Owner
- Scrum Master
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 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
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.
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
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
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 has two specific KPIs that you should focus on:
- 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.
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.
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:
- Sprint planning
- Daily Scrum
- Sprint review
- 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
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.
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 – ScrumAlliance.com
State of Agile 2018 – Versionone.com
State of Agile Marketing 2018 – AgileSherpas
Developers Survey 2018 – Stackoverflow.com