Kanban vs Scrum - Every Difference You Need To Know [2020]

Scrum is the most popular Agile framework today (56% of all Agile teams use Scrum).

But is it the most effective one, particularly for your team?

Or is Kanban, one of the trending agile frameworks today, a better fit for your team?

This “Kanban versus Scrum” article will tell you whether you should go with Kanban or Scrum.

But first…

What Is Scrum?

The Scrum Agile terminology and definition was first introduced by Ken Schwaber and Jeff Sutherland in 1993. Jeff actually referenced a 1986 Harvard business study to come up with the idea.

Scrum stands for delivering high-quality software in a minimum amount of time.

The Agile Scrum SDLC Model features timeboxes, or also known as sprints. Throughout the sprint, documentation is created, the scrum software is developed, and work processes are monitored and then improved to ensure future successful projects.

Each sprint lasts between 1 and 4 weeks. The most common sprints last two weeks, give or take.

By the way, the average number of sprints in a scrum project is five.

While the average scrum project length is close to 10 weeks.

Team roles are also vital when utilizing the Scrum framework. You have a product owner, a scrum master, as well as a scrum team. Here’s why they matter:

The product owner communicates with the stakeholders and the customers to figure out the features that the end users would love to have. The product owner then proceeds forward to creating the product backlog. The product backlog is the place where all software features are noted down.

The scrum master then refers to the product backlog in order to create the scrum backlog.

The scrum backlog consists of tasks and user stories needed to be completed in order to bring those features to life.

A user story shows the product you are trying to develop through the eyes of your user. It basically illustrates the steps the user needs to take to finish a task within your software successfully. And then, based on the user’s journey (story), you work on improving that Scrum software.

It’s important to note that the scrum master isn’t acting as a manager. He’s more like an extra hand to the scrum team.

The scrum master’s job is to make sure that the team has the skills required to finish the project successfully. He must also ensure that there’s a pleasant work environment. The team shouldn’t be distracted by external tasks or sources. And also, the scrum master should be able to remove hurdles that the team might be facing to help his team members reach the goal line without much hassle.

Speaking of the scrum team, it’s important to mention that the team should be cross-functional. There’s no manager to manage the team. So, every member of the team should foster accountability and ensure he is meeting all vital deadlines.

When using the Scrum SDLC framework, the team needs to be highly skilled and committed. That’s because the Scrum project management methodology accommodates changes along the way, so every member of the team should be able to adapt to the changing circumstances.

There are also daily Scrum meetings to help the team be on the same page.

During these meetings, everyone shares what they did yesterday, what they are going to work on today, and if there are any challenges along the way.

When using the Scrum model, team communication is on a pedestal. It’s super important for the team to understand clearly the tasks they are working on and the progress that is being made. That will help the team move toward the goal line without stumbling on many roadblocks along the way.

With burndown charts, the scrum master can track the team progress and initiate “speed” encouragement if needed.

Benefits of Using Scrum

One of the biggest advantages of using Scrum is that it allows you to bring everybody on the same page through daily Scrum meetings.

It also enables you to come up with relatively precise time and cost estimates as there is some documentation involved at the start of each sprint.

Another big advantage of the Scrum framework is the empirical process of having quick feedback causing the ability to deliver value.

When it comes to the scrum master… “45% of Scrum Masters surveyed saying they were the people kicking off the agile transition” according to Scrum.org.

Compared to the traditional and rigid Waterfall method (the opposite of agile), Scrum allows you to modify the scrum process along the way (after each sprint). So, your team can stay current with the evolving market and produce the best quality software. And make your end users happy.

The Scrum Alliance survey also shows that “the overall success rate of projects delivered using Scrum is 63%.”

“Silicon Valley Scrum” also enables your team to move faster than other methods because of the time-boxed sprints. It creates a sense of urgency. A sense that can either stimulate your team to become more productive and work faster or stress your team members out and ruin the work process. So, you’ll have to be careful with the pressure your team receives from meeting deadlines.

Disadvantages of Using Scrum

A disadvantage of Scrum is that iterations aren’t recommended during the sprint.

When more tasks are added to the sprint, “Scope creep” happens.

“Scope creep” is basically a symbol of overwhelm. That’s because it can mess up your workflow. It can deprioritize your tasks. And also cause you to miss deadlines, thus leave your customers shockingly disappointed.

Your team members should also be very skilled and held accountable. If there’s a lack of accountability, your team will fall behind seriously as there is no management involved.

Also, your team should avoid working on side tasks. The team should entirely focus on the Scrum project. Due to the evolving environment, your teammates should pretty much be “all in” so that they can adjust the software according to the customers’ desires.

Also, compared to the Waterfall methodology, the Scrum framework lacks a long-term vision of the product. That’s because conducting thorough research isn’t common practice among the Agile models. Scrum only involves planning at the beginning of each sprint.

What Is Kanban?

Kanban board example

Kanban is an Agile methodology, like Scrum is, and it fosters changing environments and constant iteration + agile delivery.

It dates back to the 1940s. A Toyota engineer, named Taiichi Ohno, was the man who first thought of the Kanban definition.

Taiichi noticed the way marketplaces are being restocked.

They have just enough supply to meet the demand. If there are empty shelves in the shop, then more inventory is ordered to meet the demand again.

Taiichi brought this JIT (just-in-time) principle to the Toyota facilities to ramp up the car development process.

Since then, the Kanban (development) methodology has gained quite a noticeable popularity, and Toyota has definitely increased its productions.

We can say that Kanban is perhaps the more natural Agile model to comprehend as there are no sprints and a set of kanban roles to follow.

Also, the Kanban board can be used by any team in the company as opposed to the Scrum sprint dashboard, which is owned by one single team.

The Kanban approach also helps you to visualize your workflow and locate any existing issues clearly. That’s because, within the Kanban board, you typically have three visual columns — “To Do,” “Work in progress,” “Done.”

You can also insert tasks constantly during the work process when the team needs to adapt to the changing desires of the end user.

It’s quite hard to make precise time and cost estimates as there is almost no planning involved in Kanban.

Kanban also fosters the “start with what you have, and change along the way” mantra. Yet, this doesn’t necessarily mean you should hop right into the battlefield. Most teams prefer to huddle together and discuss the project’s goals before the actual development happens.

It’s worth noting that Kanban features WIP (work-in-progress) limits. The WIP sets a limit to your “Work in progress” column allowing you to work only on a few tasks at the same time, say two. This helps the team members avoid multitasking and enables them to focus on a single assignment at a time. It increases productivity as well as agile delivery speed.

The Kanban task board also features the so-called “swimlanes.”

Swimlanes help you prioritize tasks so that your team is working only on essential assignments and not on trivial tasks.

For example, with kanban software development, we typically have three swimlanes available:

Blockers — issues that are slowing down the kanban work process.

Issues and bugs — bugs that should be fixed but aren’t urgent.

Someday — irrelevant issues that can be fixed down the line.

There are also 6 Kanban principles every team should adhere to:

Visualize the workflow — visualization of the Kanban board will help you identify issues easily and fix them.

WIP (work in progress) limits — It sets task limits in order to increase productivity.

Manage the agile workflow — observe what works and what doesn’t. Then optimize the workflow based on what works in order to ramp up kanban software delivery.

Adhere to the process rules — your team needs to adhere to the agile workflow rules and guidelines. This will bring everybody on the same page and enable them to produce quality work.

Feedback loops — typically expressed in daily meetings (similar to the Scrum stand-ups). The team gathers to assess the current situation and makes further work-process improvements.

Continuous improvement and delivery — With constant improvements, the team can speed up the kanban work process and thus continuously deliver pieces of software to the market. Your users will be delighted as you can appeal to their hunger for frequent delivery of software features.

Advantages of Using Kanban

The Kanban approach is quite a straightforward way to produce software.

You can pretty much jump right into the battlefield without creating tons of documentation. In fact, an hour-long discussion about the project’s goals will be enough to set you on the right track.

Also, you can make changes to the Kanban board whenever you want as opposed to the Scrum sprint board. Because Kanban doesn’t primarily focus on speed but on smooth workflow, you shouldn’t worry about missing deadlines.

You can also clearly see what’s on the table and thus notice any major issues that may occur along the work process and prevent that from happening.

Kanban is likewise quite easy to manage as you have three columns on the board (not always tho) — “To Do,” “Work in progress,” and “Done.”

Disadvantages of Using Kanban

Not adhering to the WIP limits will cause your team a lot of frustration.

The biggest issue with the Kanban (development) model is working on more tasks than needed. And focusing on trivial assignments rather than vital tasks. This can reduce your team’s productivity and negatively impact the software that is being delivered to the end user.

There are no specific kanban roles.

Now, some Kanban agile teams have a replacement for the scrum master — an Agile coach. However, that’s not necessary. Most Kanban teams prefer not to have assigned roles. Yet, because of that single reason, your project may fail if there is a lack of skills and accountability.

As you know, there is a deficient level of documentation involved in Kanban. So, the team isn’t able to see clearly the product ahead of time. You might end up developing a completely different software than it was initially planned.

Scrum vs Kanban — Differences

Now, Kanban and Scrum are quite similar in the first place as they are both subsets of the Agile philosophy.

But they also differ in ways that will make you prefer one over the other. Let’s explore their major differences…

Roles

One of the main differences between Scrum and Kanban is in their roles.

As you already know, Scrum comes with a set of roles — product owner, scrum master, and a scrum team. This helps to distribute tasks easily and organize the team. You can thus produce working software quite frequently.

The scrum master’s role is vital to the work process as he obtains a ”50,000-foot” view of the agile workflow. He can see when things go wrong and bring the team back on track.

However, the Kanban model doesn’t necessarily recommend a specific set of roles.

Yet, you can meet the following roles in some teams:

Service Delivery Manager
Service Request Manager

The Service Delivery Manager is pretty similar to the scrum master. He keeps an eye on the Kanban agile board and helps the team when issues occur. He also strives to facilitate the work process and ramp up kanban software delivery.

On the other hand, the Service Request Manager fosters… simple management. He encourages the team to follow the workflow rules and guidelines so that there is a smooth work process going on. And thus he brings the team on the same page and helps them get more stuff done in less amount of time.

Time Delivery and Deadlines

In Scrum, you have the so-called timeboxes, also known as sprints. A timeframe ranging from 1 to 4 weeks during which the team should develop a working piece of software.

With Kanban, you don’t have to adhere to specific timeframes. So, you won’t feel any pressure from missing frequent deadlines.

Planning and Documentation

With the Scrum framework, you have to do some planning at the beginning of every sprint. It helps you to set clear and specific targets that the scrum team should complete during the sprint. It also brings everybody on the same page. So, you’ll be able to ramp up the scrum software delivery process.

Because of Scrum’s detailed documentation, you can also come up with relatively accurate scrum release dates and cost estimates.

With Kanban, there’s close to zero planning involved.

So, if you aren’t very keen on conducting thorough research, the Kanban model would be a good fit for your team as it allows you to jump right into the battlefield. Of course, you can do the same with Scrum. However, changes during the sprint aren’t encouraged and this may hamper the scrum development process. Whereas with Kanban, there aren’t such rules.

KPIs (Key Performance Indicators)

KPIs are used in both Scrum and Kanban to track progress. It helps the team review the work process and make improvements in order to speed up the delivery efforts.

With Scrum, you have two major key performance indicators — Velocity and Capacity.

Velocity — After a set number of sprints, say 10, you’ll be able to assess how many users stories were completed on average after every sprint. And thus you can come up with an accurate assessment on time and cost estimates for the sprint job status.

Capacity depends on the workforce. If some of the scrum team members feel sick or are on vacation, you might want to add fewer user stories to the sprint as you’ll not be able to get everything done.

On the contrary, if you have new people on board, then you might want to add extra tasks in order to get more done.

Burndown and velocity scrum charts are likewise available in Scrum.
Burndown charts give you a visual presentation of the work progress. They tell you how much work has been completed till this particular moment and how much more is left.

The velocity scrum chart illustrates the past performance of the team. So that you can make a more accurate assessment of the work progress in the future.

With Kanban, you have two major KPIs as well — lead time and cycle time.
Lead time tells you how long it took a particular task to go from the “To Do” column to the “Done” column.

And Cycle time shows how long a particular task has stayed in the “Work in progress” tab. This can give you a rough estimate of how long it’ll take your team to complete future tasks.

There is also a Cumulative Flow Diagram (CFD) which shows you how many tasks were completed across a set period of time. With this kanban chart, you can track the team progress and optimize it further so that your teammates can work painlessly and swiftly.

Meetings

In Scrum, you have daily stand-ups. During these meetings, the team goes over what was done yesterday, the tasks for today, and any existing challenges that may hamper the workflow.

Except for the daily stand-ups, you also have three other scrum meeting types:

Sprint planning
Sprint retrospective
Sprint demo
And backlog refinements

Sprint planning is held before each sprint to discuss requirements and goals. It helps the team to work better.

The sprint retrospective is held after each sprint to discuss further optimizations that can ramp up the delivery frequency. And thus enables the team to complete the next sprint without much hassle.

The sprint demo is held occasionally along with the product owner and the stakeholders. It brings everybody on the same page, and suggestions from the stakeholders are being made.

Backlog refinement meetings help the team to get a better understanding of the upcoming sprint items, stories, and tasks. The backlog refinements are important as they help the team estimate the work. It’s recommended that backlog refinement meetings should happen at least once a week.

With Kanban, you don’t necessarily have to hold such daily meetings. Though they are recommended. A lot of Kanban teams incorporate the daily scrum stand-ups in their work environment as these meetings are extremely helpful to the teammates that are falling behind.

And you can also accommodate six other types of Kanban ceremonies (meetings):

Replenishment & Commitment Meeting — this kanban ceremony is held to ensure that the team is working on the tasks of the highest priority.

Delivery Planning Meeting — This kanban meeting ensures the team is well prepared for meeting deadlines.

Service Delivery Review — it stresses the team’s work quality and performance (commits, code reviews, tests, etc.).

Operations Review — this one is pretty similar to the Service Delivery Review. But it covers a larger portion of the project.

Risk Review — This meeting ensures that the team members will be prepared if major issues occur. Like outdated sprint task lists, exceeding WIP limits, and other unexpected issues.

Strategy Review — this is perhaps the most important kanban meeting. It’s based on customer feedback. You should assess clearly what the end user desires and develop a specific plan to build software that meets the customer’s desires.

Kanban Board vs Scrum Board

Scrum boards illustrate the features that need to be developed during the sprint. And they also show the specific tasks to be completed in order to build those features. A scrum board typically consists of the following tabs — “Story,” “To Do,” “In progress,” “Test,” and “Done.” The Scrum task board is also reset after each sprint.

The Kanban board, on the other hand, is reset only after the project is completed successfully which may take a year or more.

Work In Progress (WIP) Limits

Both Kanban and Scrum feature WIP limits in different ways.

With Kanban, you have a WIP only on the “Work In Progress” column. The WIP limit enables you to work only on a few tasks at the same time, say two. Otherwise, working on more tasks can cause frustration and overwhelm.

With Scrum, the WIP limit is set on the entire batch of tasks at the beginning of the sprint. During the sprint, you shouldn’t insert new tasks or user stories to the scrum agile board because this can cause your team to miss deadlines.

Pull Systems

Both Scrum and Kanban use pull systems to pull tasks. However, these pull systems differ.

With Kanban, you can only pull a task after you’ve finished a particular assignment.

With Scrum, you are pulling a whole batch of tasks at the start of each sprint and stick with it until the sprint is over.

All in all, these pull systems are designed to help you focus on a few tasks at a time and avoid multitasking.

Changes

During the Scrum sprint, it’s not recommended to pull new tasks and user stories to work on. It can hamper your work process. It can reduce the team performance. And it can also cause you to miss deadlines and leave the end users unhappy.

Changes in Scrum are allowed only after the sprint is over. This doesn’t necessarily mean a bad thing, though. In fact, it will enable you to focus on your concurrent tasks so that you can deliver working software swiftly.

In Kanban, you are allowed to make changes pretty much whenever you need to. Because there are no time boxes and strict guidelines to adhere to, Kanban enables you to adjust the workflow based on the changing environment. And thus stay on top of the competition.

When To Use Kanban vs Scrum?

Scrum fosters a more structured working environment. It helps your team to be on the same page and work faster.

The daily Scrum ceremonies (meetings) will definitely help your team clearly understand what the main goal is. And know what the next major step is toward the goal line.

Scrum is also suitable for non-mature teams as it follows strict guidelines and rules. Novices on your team need accountability. And Scrum offers exactly that. You can bring every new developer onboard rather swiftly by following rigid guidelines and rules.

Also, Scrum is great when time is of the essence. Because of the timeboxes, there is a sense of urgency developed in the team that keeps the scrum team members on their toes and makes them work zealously.

Kanban, on the other hand, stands for flexibility.

It enables you to make iterations to the workflow along the way without having you to worry about timeboxes and meeting deadlines. Kanban basically doesn’t put as much pressure on your team as Scrum does.

The Kanban methodology is better suited for mature teams. Teams familiar with the organization’s culture. Teams that have been developing for quite a while. And more importantly, teams that are highly skilled and accountable. That’s because experienced teams have already developed reliable working habits and wouldn’t need to adhere to as rigid rules and guidelines as novices need.

Both Kanban and Scrum are better suited for smaller teams. That’s because there’s a lack of documentation. And it’s extremely difficult to manage a big team that must adhere to changes constantly along the way to develop great products.

You can also use both Kanban and Scrum at the same time. There are a lot of Kanban teams that integrate the daily scrum stand-ups in their schedule.

Or you can directly refer to Scrumban. Scrumban, a combination of both Agile frameworks, is based around sprints as well. However, in Scrumban, you don’t have a set of roles to adhere to. Also, you have a WIP limit to help you focus on a few tasks at a time and avoid multitasking.

Sometimes, scrum teams are using the kanban board to make work visually available to all the members of the team.

In fact, over 80% of respondents said that they were using Kanban with Scrum, according to Scrum.org.

Honestly, my recommendation would be to pick the one that your gut tells you to choose. Yes, you might be wrong, but it’s the only way to find out whether Scrum or Kanban is the right pick for you.

I’d personally go with Scrum as my team needs to meet essential deadlines right now and I feel like Scrum is the better option. This doesn’t mean I totally reject Kanban though. On the contrary, I love Kanban’s simplicity and flexibility. Kanban works better for my team when we have a pretty strong momentum of releasing features.

You might also want to pick a Scrum / Kanban tool so that you can manage your workflow easily.

JIRA has been established for quite a while. It’s a super popular and robust tool. Jira kanban and scrum boards are actually quite amazing.
Scrum is also good for Trello. Trello is another super popular tool that stands for simplicity and features kanban boards.

Codegiant is the tool my team has developed, and we primarily stand for simplicity and robustness. And we offer Scrum and Kanban boards as well. Feel free to try the one that suits you best. - https://codegiant.io/

---

Originally published at: https://blog.codegiant.io/kanban-vs-scrum-every-difference-need-to-know-2020-a0afa571524b