Kanban vs Scrum: Which One is Better?

Kanban has been pitted against Scrum and vice-versa for the longest time. The debate is still on and each camp is ready to face the arguments. While we don’t aim to arrive at a winner in this article, we want to help you understand more about Kanban and Scrum. We’ve outlined the key areas that will guide you in deriving which is a better methodology for you and your team.

What are Kanban and Scrum?

Kanban and Scrum are different methodologies that embrace the values and principles of the Agile manifesto. Kanban is an approach to establish a steady flow of work through a visualized process. Scrum is a framework that uses specific roles, ceremonies, and artifacts for Agile development. Both Kanban and Scrum are also Lean in nature. They both encourage teams to work towards continuous improvement and delivery.

Some people mistake Kanban and Scrum to be the same thing. Once you get to know them a little better, you may even think they are. There’s even a methodology called Scrumban, which is basically scrum and kanban used at the same time. But these two are not the same (there we’ve said it!).

Let’s discover the key differences of Scrum and Kanban.

Roles and Responsibilities

In traditional project management, a project manager is a prominent role. In Scrum, there is no project manager. It has its own set of roles to be filled. This includes the Scrum Master who oversees the work done by the team and ensures they abide by the Scrum rules. It also includes the Product Owner who defines the team’s work and ensures they are working on what has the highest business value. They are both joined by the development team in making up the Scrum team.

Kanban, on the other hand, does not require any roles to be performed. In most cases though, there will be a project manager that ensures the team is working towards their goals and deadlines. Although times have evolved and there are some roles that have emerged in Kanban. In the book Essential Kanban Condensed, David J Anderson and Andy Carmichael discuss the responsibilities of these two roles: the Service Request Manager and the Service Delivery Manager.

Cadence

Performing work in Kanban is done continuously. As soon as a team member is ready to pull work, they can start working on a new task card. In Scrum, work is performed during a time-box called sprints. A sprint is a defined time-frame where a team can perform the work they have committed to. The aim is to complete the work within the given timeframe. In Scrum, work stops when the time-box is reached. In Kanban, time restrictions are optional. The main focus is to achieve a steady flow of work.

This is not to say that tasks can go for as long as they can in Kanban. Teams need to work towards getting things done as fast as they can with a high level of quality. Otherwise, their tasks would pile up and there will be a bottleneck. As for Scrum, it is not to say that incomplete work will be left unfinished. Teams can and would normally work on them again on their next sprint. The level of effort though would most likely be lesser since they have done some work on it already.

Commitments and Work Limits

Scrum teams use a meeting called Sprint Planning to determine the tasks they can do on a given sprint. They often use story points as a guide to measure the amount of work they can commit to. These story points are arbitrary values. It is a form of estimation of how complex a task is. If the team has been doing work for some time, they would use past sprint data to determine how many story points they can work on. This is called velocity. The tasks committed during sprint planning are locked. The Product Owner cannot add more tasks during the sprint. Only the Scrum team can pull more work only if their capacity allows them to.

In Kanban, the commitment is to deliver the task at hand. A fundamental principle of Kanban is the use of Work In Progress (WIP) Limits. Ideally, team members only work on one task at a time before moving to another one. Commitment is based on team capacity. Each workflow state has a WIP limit. Anything more than that is not acceptable. In terms of task or requirement modifications, Kanban is more flexible. Changes in requirements can be accommodated midstream.

Metrics and Reporting

The key metric in Scrum is velocity. This is the total number of story points that the team was able to complete at the end of a sprint. As the team works sprint-by-sprint, they are able to gauge the velocity that is reflective of their capacity. They can then use this to plan for future sprints.

The velocity of the team is not meant to be static. It can and will fluctuate due to a number of reasons. Fluctuations can be caused by changes in team composition, the complexity of requirements, or team members upskilling. But the trend would normally go upward sprint-by-sprint. Then it may reach a plateau. If your velocity is going down sprint-by-sprint, then you need to know why.

Velocity also drives the reports being used in Scrum, which are burndown charts and velocity charts.

Cycle time, on the other hand, is the key metric in Kanban. This tells the amount of time it takes for one task to be completed. As for reports, Kanban makes use of a Cumulative Flow Diagram. This allows teams to better understand how work is flowing from one step in the workstream to another in a given period of time.

Meetings

Scrum is very popular for its ceremonies. These are required meetings that the team conducts sprint-by-sprint. Scrum has the following ceremonies:

• Daily Scrum or Daily Stand-Up
• Sprint Planning
• Sprint Review
• Sprint Retrospective

Kanban does not have required meetings. Teams can collaborate and discuss as they see necessary. Although this is the case, Kanban as a project management methodology has evolved with times. To provide some structure on planning and feedback generation, David J Anderson introduced the 7 cadences of Kanban. These seven cyclical meetings are designed to heighten information flow, communication, and collaboration in teams. Anderson clarifies that teams don’t need to introduce 7 new meetings to execute their project. Instead, they are encouraged to inspect if there are existing discussions that can be adapted to the 7 cadences to improve their efficacy.

Tools

We all know that a Kanban board is used for Kanban. But have you noticed that the Scrum board uses a Kanban board too? Essentially, the Scrum board is fed by stories from the Sprint Backlog. As work is done through the sprint, the stories go from To Do to In Progress to Done.

A key difference though between the two is that Kanban boards are used continuously whereas Scrum boards reset during sprint planning.

Final Verdict

Now that we’ve come to know Kanban and Scrum compared with each other, you may think “which one is better?” The answer is…

It depends.

You need to assess your business requirements and determine which methodology is more applicable to you. If your requirements are stable or your product has not been released, Scrum may be more suited for you. If your requirements change or your product is already out in the market, you might find Kanban more applicable. This is because the market has a greater influence on the tasks that you will be taking on at this stage. If a production issue comes up, you need a flexible system to accommodate the task of resolving it.

You also need to consider the responsiveness of your team to change. Are you up for taking on a radical shift? Then go with Scrum. Are you more inclined to take on gradual changes? Then go with Kanban. Either way, the methodology you choose should be agreed for by the team. This ensures that everyone will work together towards adoption and continuous improvement.