Scrum vs Kanban: 5 Differences Between Sprints and Flow

If you’re part of a Scrum team, chances are you’ve heard something about another Agile approach called “Kanban.”

Someone might have claimed your Scrum Board is actually a Kanban Board. Perhaps your Scrum Master mentioned managing Work In Progress. Maybe you even heard rumors that switching to Kanban can make story point estimation obsolete. 🤯

We’ve put together the five fundamental differences between Kanban vs. Scrum, so you can pick which one is best for your team:

👻 Psst! If you’re new to Agile or need a refresher on specific terms, pull up this handy Agile glossary in another tab, and refer to it as needed.

Kanban and Scrum are both Agile approaches that help teams manage their work and projects. Here’s a quick overview of each.

Kanban’s fundamental principle is to create a steady flow of work through a system. It does this by enabling focus, continuous improvement, and removal of bottlenecks.

The Kanban approach originated in Toyota in 1940. It was originally a framework for optimizing the process of manufacturing cars. Now, it has many broader applications.

In modern lingo, the process of Kanban often gets confused with the process’ main artefact – Kanban boards. Kanban boards were popularized by Trello. Teams around the world – from manufacturing to software development – now use boards with columns that visualize their workflow.

In its most basic implementation, a Kanban board contains three columns: “Backlog,” “Work In Progress (WIP),” and “Done.”

In Kanban, cards representing deliverables move through a Kanban board’s columns as their status changes.

Scrum is by far the most commonly used Agile framework, with recent data indicating that 66% of Agile teams practise it. Within Scrum, teams work in cycles called Sprints.

The goal of each Sprint is to work at a sustainable pace to release a small, valuable increment of work – often in the form of a working piece of software. Scrum includes specific events geared towards helping teams reflect and adapt their work. These include Sprint Retrospectives and Sprint Reviews among other events, which help teams chart their progress and practice continuous improvement.

Scrum teams organize their members according to three accountabilities – developers who build the product, a Product Owner who prioritizes the work, and a Scrum Master who helps the team understand and practise Scrum.

Before we get into their differences, here’s an overview of the similarities between Kanban vs. Scrum:

Now, let’s get into the differences between Kanban and Scrum so you can decide which one is most suitable for your team’s situation.

Kanban emphasizes flow. Flow is like water in a river: work moves downstream, uninterrupted, continuously. Whereas Scrum organizes work around Sprints. Sprinting involves running but also pausing to reflect on work and prepare for the next Sprint.

The key difference is that Kanban is continuous, whereas Scrum is iterative.

In Kanban, there is no end to the process, just a stream of work items flowing to completion, ever more fluidly. In Scrum, there’s a clear start and end to each 2-4 week Sprint cycle and every Sprint should become more efficient based on discoveries from earlier cycles.

The most visible manifestation of this difference is the artefact or commitment Kanban and Scrum teams use to guide their work. In Kanban, the Kanban board represents the continuous process of work and visualizes bottlenecks that break the flow. In Scrum, the Sprint Goal sets the destination the team is headed to and influences whether a Sprint was successful or not.

Kanban creates focus for the team by setting a Work In Progress (WIP) limit. This means the team only pulls new items into the process when it has the capacity to do so.

Scrum protects the team from too many to-do’s with a focused Sprint Goal and Sprint Planning. This prevents new work being added to a team’s task list – the Sprint Backlog – once a Sprint has started. Instead, the team push ahead to the Sprint Goal with the tasks they have assigned themselves.

Kanban operates as a pull system. Instead of someone pushing tasks onto a team’s plate regardless of capacity, Kanban teams only pull in new work from the backlog when they have completed items already in progress. This pull approach might sound logical, but most workplaces operate as push systems. In such a contexts, one or more managers keep pushing more and more work to a team regardless of what work is already in progress.

In Scrum, the team has the final say in committing to the Sprint Goal and the items they’ll work on during a Sprint. Scrum teams plan their tasks ahead of time in Sprint Planning and then push to meet the Sprint Goal. This can result in stress and overwork in cases where the goal turns out to be too ambitious, but the team doesn’t want to abandon the overall objective.

Essentially, Scrum teams make a bigger – and therefore riskier – commitment. They aspire towards an entire Sprint goal, encompassing multiple work items. A Kanban team only commits itself to one individual work item each time it pulls one into the work process. That is the reason why Kanban is so applicable to repeatable processes like manufacturing.

One approach isn’t necessarily better than the other. Scrum’s Sprint Goal creates vision and purpose at the risk of task-gluttony. Whereas Kanban teams may end up surfing a lean and repetitive workflow to nowhere.

The official Scrum Guide doesn’t mandate using a task board, but most Scrum teams do. The 15th State of Agile Report found that Kanban practitioners and many Scrum teams use task boards that look similar from afar, but are different when we look closer.

81% of respondents for the 15th State of Agile Report use a form of Scrum (Scrum, Scrumban or a Scrum/XP hybrid). Since 77% of all respondents use Kanban boards, and 67% use task boards, you may conclude that most Scrum teams use a kind of Kanban board – which they might refer to as a task board, Scrum board, or Sprint Board.

Differences between Kanban boards and Scrum boards:

Kanban teams make a probabilistic forecast of when and how much work the team can complete. That’s if they make projections at all. For example, they might use historical data to calculate that there’s an 85% chance an individual work item gets completed within eight days.

Scrum also uses historical data but mixes it with the team’s experience to give an estimate, which is more like a mix of judgment and calculation. They’ll use regular events like Backlog Refinement and Planning Poker to estimate the size of work items by comparing them to each other. They’ll then check how much work they got done during previous Sprints – their sprint velocity – and use that number to limit the work they plan for future Sprints.

Since Kanban helps teams optimize their workflow at the level of individual tasks, anyone can use it in their work. It is easily applied to parts of existing systems, methods, and organizational structures. Whether you’re making Toyotas, writing articles, or building software, Kanban can slot in and visualize your workflow.

Scrum on the other hand prescribes team roles and recurring events that need to be followed for it to work. It’s more of a commitment that often replaces parts of existing systems, methods, and organizational structures. This distinction means it takes more effort for a team to adopt Scrum.

This difference between the two approaches doesn’t necessarily mean one is easier than the other to implement. Since Scrum is more prescriptive and offers more guidance, it can actually be more manageable for teams new to Agile because they know what the “rules” are.

📌 Note: Kanban teams do sometimes add specific roles, like a Service Delivery Manager in charge of improving workflow efficiency – akin to the Scrum Master role – or a Service Request Manager in charge of customer satisfaction, similar to a Product Owner in Scrum. But these roles are not mandatory, and often these responsibilities can be spread across the entire Kanban team.

Whether Kanban or Scrum is suitable for your team depends on your existing experience with agile frameworks, the type of projects you work on, and your appetite for organizational change.

If you’re trying to figure out which one’s right for you, we’ve made this Kanban vs Scrum showdown as simple as we can.

🤯 Still not sure which one to pick after weighing these options? Head over to our article on Agile frameworks and learn about the other Agile approaches you could try.