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:
- Kanban makes work flow; Scrum puts it in cycles
- Kanban teams pull work continuously; Scrum teams push towards a fixed goal
- Kanban and Scrum teams use boards differently
- Kanban teams forecast; Scrum teams estimates
- Kanban complements existing systems; Scrum replaces them
What are Kanban and Scrum?
Kanban and Scrum are both Agile approaches that help teams manage their work and projects. Here’s a quick overview of each.
What is Kanban?
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.
What is Scrum?
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.
What do Kanban and Scrum have in common?
Before we get into their differences, here’s an overview of the similarities between Kanban vs. Scrum:
- 📜 Kanban and Scrum both follow Agile principles, like delivering value to customers often, empowering team members, continuous improvement of the work process, and minimizing waste.
- 👨💻 Kanban and Scrum both aim to keep the team focused by limiting the amount of work assigned to them (though each approach does so differently, as we’ll see shortly).
- 📋 Kanban and Scrum teams both use a shared board to organize work. These include columns that represent the status of items in the work process and individual task cards showing what is on the backlog or in progress.
- 🔨 Kanban and Scrum both aim to make work items as small as possible. This helps the team deliver finished, usable product updates to customers often.
- 🏃 Kanban and Scrum both focus on maintaining a sustainable pace. Both frameworks value finding and maintaining a sustainable and predictable pace for teams and stakeholders.
What are Kanban and Scrum’s differences
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.
1. Kanban makes work flow; Scrum puts it in cycles
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.
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.
2. Kanban teams pull work continuously; Scrum teams push towards a fixed goal
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.
3. Kanban and Scrum teams use boards differently
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:
- 📋 One Kanban board may serve multiple teams, but in Scrum there’s usually one board per team.
- ✅ The Scrum Board includes a Sprint Backlog in addition to a standard (product) Backlog.
- 👷 Kanban boards have WIP limits, either for the entire board, specific columns, or both.
- 🌀 Kanban boards usually have a more detailed visualization of the team’s workflow, with more columns to reflect each process step. This process may be heavily tailored to the stages of creating a product.
- ➕ New items are added to the Scrum board at the start of every Sprint, whereas tasks flow infinitely through a Kanban Board. Kanban teams sometimes find the framework dull and repetitive with its ever-looping work process without a clear start or beginning.
4. Kanban teams forecast; Scrum teams estimate
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.
5. Kanban complements existing systems; Scrum replaces them
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.
Kanban or Scrum: Which one is right for your 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.
Choose Scrum when:
- 😖 Defining a consistent workflow for your tasks is hard, but you can build a cross-functional team to tackle varied types of work.
- 🐣 You’re just starting with Agile. The Scrum process provides more structure than Kanban and clearly defined roles for team members.
- 📅 You prefer a well-defined rhythm of Sprints with scheduled events for planning, execution, and reflection. Note that following the Scrum Sprint cycle also requires customers and stakeholders who are ok with such a rhythm.
- 👾 You work on emergent and complex products. Scrum shines when you want to learn fast and experiment because it gives teams a timeframe to commit to new experiments and reflect on learnings. Its iterative approach helps teams change tack and adapt.
Choose Kanban when:
- 😳 You constantly end up with more work than you can complete, especially if that happens because people outside of the team – say, managers 👨💼 – keep piling on more work. Alternatively, if you’re a Scrum team, try imposing WIP limits for your team.
- 🧘You want to be more flexible in which work to take on or release without waiting for the next Sprint Planning or Review event.
- 🧊 You don’t want to or can’t change much about existing processes and roles in your team and organization.
- ♻️ You work on repetitive and predictable tasks. Kanban shines when your tasks are repetitive, because it’s easier to spot blockages and optimize your workflow if you know that different parts of production typically take a fixed amount of time.
🤯 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.