Scrum vs Kanban: Defining Key Differences

Two popular developing methodologies, Scrum and Kanban, are often used interchangeably that is incorrectly for sure. They are not two sides of the same coin but not everyone understands that the significant differences do exist between these famous Agile methodologies.

If you realize this difference, you’ll choose the best option and find the appropriate way to implement one of them. If not, this post may be helpful. So, how to identify the leader in the “Scrum vs Kanban” opposition?

First, let’s define why these Agile project management methodologies are often put together in one row and often confused with each other.

Agile family representatives

As the Agile methodologies, Scrum and Kanban are both considered flexible and iterative. What unites them?

First of all, it’s about the famous Agile Manifesto that was formulated more than 18 years ago by the group of professional IT development leaders. The key postulates of the manifesto are illustrated in this pic:

All four points of the manifesto look convincing and fair. And that’s why:

1. Tools are not so important as people who unite together and committee to the common goal.
2. MVP approach in development (Minimum viable product) means that we strive to release product minimum viable version to the market asap and all out of the box features are left for later.
3. It’s relevant to change the word “customer” to “user” (of the product) here. I’d say, requirements should be collected from future users not from a customer. Usually, a project is a startup, where such things as customer development and JBTB (Jobs to Be Done) come to mind. During this development, we check our theories even before a prototype development. We try to make sure that all challenges we are solving do exist in the users’ life, that these challenges and issues are really considerable, that our users will pay, that there are enough channels to attracting users.
4. The point about flexibility is needed when a product manager or UX designer changes the task’s requirements and a developer feels annoyed by regular changes. It is true when you refer to that point of flexibility. What is this willingness for updates? We need it to react to feedback.

For example, you add a new feature, get behavioral data, and realize that you need to change some features and start working on them. Then you upgrade the version of the feature. To do that you need to be open for changes and have the ability to catch those changes, concerning data and analytics.

These main ideas from the manifesto are supported by 12 principles:

The Agile concept is worth to be described and discussed for a long time, but I’m going to return to the comparison of Scrum and Kanban. (If you want to know more about Agile, dive into the article What is Agile Methodology and How to Choose Its Right Type for Your Project?)

Now let’s get back to Scrum and Kanban.

Scrum vs Kanban: what is the best option?

What is Scrum?

If say briefly, Scrum project management is a method to organize work into small, manageable pieces that can be completed within prescribed time periods called sprints by cross-functional teams.

There are at least 3 prescribed roles to plan, organize, manage and optimize this process:

• Product Owner (initial planning, prioritizing, and communication with the rest of the company)
• Scrum Master (overseeing the process during each sprint)
• All team members (carry out the purpose of each sprint, such as producing software code.)

Sprints usually last 2–3 weeks. As a rule, features that are being worked on during a sprint don’t change.

A Scrum board is a visual representation of the workflow. It is broken down into manageable chunks (stories) with each story moved along the board from a backlog into work-in-progress and on to completion.

What is Kanban?

Again, saying briefly, Kanban is a tool to organize work for the sake of efficiency. It also encourages your work to be broken down into manageable chunks. A Kanban board is the means to visualize it as it progresses through the workflow.

Scrum limits the amount of time allowed to accomplish particular works (sprints), while Kanban limits the amount of work allowed in any one condition.

Do you want an example?

Let’s look at Kanban where it originated. Imagine a conveyor on which Toyota cars’ parts are made. There is a machine that makes mirrors for cars. It produces left and right mirrors, rear mirrors, and sun visor ones. The principle is quite simple: click on the button, change the mode and get a new product.

So you order a new Toyota Camry with the “maximum option” in New York and you already have mirrors in your visor (you’ve chosen the maximum option just because of the mirrors in the visor). The important point here is that we can change priorities at any time. We can quickly switch the machine to another mode.

The key difference between Scrum and Kanban lies in iteration length. It’s about two weeks in Scrum. Kanban allows you to provide developers with tasks every day.

Kanban looks more flexible, meaning the frequency of changes. Some days ago, you realized a new feature and now you got info on how it works in real life. You learned that thing doesn’t work as it was planned.

According to Scrum realities, you estimate tasks with story points or hours. You’ll not form a sprint without estimation. You have to know if you finish all the tasks in 2 weeks. The valuable statistics (after these weeks) will show how many story points or hours your team managed to complete during a sprint. This will help the Scrum Manager to predict where the team will be in 2 weeks.

It’s not common to make estimates in Kanban. The team decides on their own whether they do it or not.

You take into account only an average time for task completion, as there’s no team velocity. This time is counted by the Cycle Time Report.

Task Cycle Time = Time spent working on a task — Time when the task was started

Let’s say, Scrum is a regular bus that stops only at certain stop places where people leave. Kanban is like a minibus: passengers ask the driver to get out and leave it where they need.

What Kanban opportunities allow to successfully use it in sprints? Let’s illustrate it with the example of a project management tool, Hygger.io.

WIP power

Work in progress option (WIP) allows setting a limit for the number of tasks that a particular specialist can work on at the same time. Do not let people burn out and let them work only on one task at one unit of time. Actually, there were researchers that shown it takes 15 minutes for a developer to switch from one task to another one.

It takes some time to read requirements for a new task and to remember where you’ve paused and found that spot in the code. Quick switching from one task to another means leaving from a stream of thought to another one. It’s not always easy to get back to that stream.

One task per person is quite a good rule. We control it like this:

Horizontal Swimlanes

If you have some unexpected problems with your website, you assign an urgent task to fix it to your team leader or developers. However, they are doing another task and are planning to finish it by a specific time tomorrow. What should you do? Swimlanes help to solve this problem.

Developers can use these horizontal columns that can be visualized as Blockers (the most urgent issues), current Tasks and Bugs and Someday Swimlane (tasks that will likely never be implemented).

To sum it up

In fact, this topic is quite discussable and requires more attention, but I’d highlight the main thing here: Scrum is a flexible development methodology but Kanban looks even more flexible.

Each methodology has its own purpose. Scrum seems better for the beginning of product development as it’s easier to manage deadlines with it. Let’s also remind that there is a lot of communication in the team. Team members discuss all backlog sprint before the start, they have an opportunity to ask questions to tasks creators.

They estimate tasks together with the help of a planning poker system, and finally, Scrum helps everyone in the team to understand the core of the product.

However, after the product launch, you have another story. You get feedback from users and need to react quickly. You have to check different theories since sometimes even a small detail matters. You apply popular product metrics, such as AARRR — Pirate metrics, and so on and so forth.

Your development cycle strives to be broken down into the smaller units and you start doing many small tasks in an unpredictable order. Here I should glorify Kanban.

What is your experience of working with Scrum and Kanban? What are your preferences? It’d be great to receive your thoughts.