Toggle Menu

Insights > Agile Training > What Is the Difference Between Scrum and Kanban?

What Is the Difference Between Scrum and Kanban?

Both Scrum and Kanban provide principles and practices that you can apply to deliver high-quality solutions faster. They share many similarities, but have distinct differences. Both methods were originally developed for software development, however, can be applied to be more productive in any line of work. Overviews Scrum Scrum is a lightweight Agile framework that […]


February 15, 2023

Both Scrum and Kanban provide principles and practices that you can apply to deliver high-quality solutions faster. They share many similarities, but have distinct differences. Both methods were originally developed for software development, however, can be applied to be more productive in any line of work.



Scrum is a lightweight Agile framework that teams can implement to improve their overall software delivery. Ken Schwaber and Jeff Sutherland created Scrum in the 1990s. They developed and continue to update the Scrum Guide, a short document that explains Scrum. You can download the Scrum Guide for free!

Scrum prescribes three roles and five events (meetings). These three constructs are mandatory if you want to “do Scrum.” The Scrum events and their cadences, timeboxes, roles, and artifacts are all predetermined, making the immediate goal very clear. Typically, organizations and teams implement Scrum in a relatively short time frame.

“The Scrum framework […] is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.” – The Scrum Guide


Kanban is a work management system. Taiichi Ohno, an engineer and key leader at Toyota Automotive Manufacturing originally developed Kanban. In the early 2000s, leaders outside manufacturing began tailoring Kanban to software development work. David J. Anderson created a widely known Kanban training and coaching service called Kanban University. The Kanban University provides guidance for organizations on implementing and leveraging Kanban to increase delivery throughput and decrease cycle time. You can download The Official Guide to the Kanban Method for free!

Kanban does not prescribe roles, meetings, or artifacts. Per Kanban University, roles and meetings generally should emerge. The Kanban method provides suggestions for each and recommends teams evolve them to meet their specific needs and current culture. Kanban University recommends an evolutionary approach to change. They contend this approach lessens resistance and creates a system tailored to each service, which will continue to evolve and improve past the initial implementation of Kanban.

Roles, Meetings, Work Items and Estimates

  Scrum Kanban
Workflow Scrum uses sprints. sprints are fixed length events of one month or less. A new Sprint starts immediately after the previous Sprint ends. All the work necessary to achieve the product goal, including sprint planning, daily Scrums, sprint review, and sprint retrospective, happen within sprints


Kanban uses a system of continuous flow. There aren’t timeboxed iterations in Kanban. The teams take in just the amount of work as their capacity allows. When there is open capacity, they can bring additional items into their workstream
Roles Product Owner

Maximizes the value of the product. They own the backlog and the roadmap. They determine what will be developed and set the priorities from a business perspective.

Service Request Manager

This is similar  to the Product Owner role. They develop a value-add backlog, vet and discard items deemed less worthwhile, and decide the work priorities based on business value and time sensitivity.

Scrum Master

Owns the process. They teach and coach the teams and the organization on Scrum. They remove impediments and facilitate events when needed.

Service Delivery Manager

This is similar to the Scrum Master role. They educate and coach teams in Kanban, establish and share meaningful metrics, and facilitate meetings as needed.



Small team that creates, delivers, and maintains features. They own how the features will be developed and how much work they will commit to in a given timeframe.



Teams aren’t explicitly defined in Kanban. Teams are the people who work on a given delivery service.

Meetings Sprint Planning

Agile Team selects and plans the work they will perform in the given sprint.

Cadence: First day of each sprint

Replenishment Meeting

During this meeting, users select the items to do next from the backlog.

Cadence: Weekly, on-demand


Daily Scrum

Agile Team inspects their progress toward the Sprint Goal and adapts accordingly.

Cadence: Daily

Kanban Meeting

The purpose of this meeting is to observe and track the status and flow of the work (not the workers) to see who the team could deliver the work items in the system quickly. It is held in front of the Kanban Board, “walking” the items on the board from right to left. This can be combined with the Replenish meeting.

Cadence: Daily



The Agile Team plans ways to increase quality and effectiveness in the near future

Cadence: The end of each sprint


Team Retrospective

Teams reflect on how the team manages their work and how they can improve. The team retrospective is in front of the Kanban Board, referring to the recently completed work items.

Cadence: Held regularly


Sprint Review

The team and stakeholders inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the product goal.

Cadence: The end of each sprint


Service Delivery Review

Users examine and improve the effectiveness of the selected service, taking an external customer perspective.

Estimation and Work Items Scrum

The Scrum Guide refers to work items as “product backlog items (PBIs).” Scrum doesn’t prescribe how write or estimate PBIs. However, many Scrum teams use the user story construct from extreme programming for their PBIs. Scrum teams often “estimate” each user story with a “User Story Point.” Story points are an abstract scale used to estimate story size in relation to other. stories. This helps teams determine about how much work they take into each sprint.


Check out my YouTube video for a 90-second example of story pointing.


In Kanban, work items can be called whatever makes the most sense for your team (e.g., tickets, cards, user stories, etc.). It also doesn’t use estimates per work item. Kanban University recommends applying work in progress (WIP) limits to specify how many work items a team takes in. Forecasting is done with recent historical throughput data (how many work items the team completes in a given timeframe +/-85% of the time) and recent historical lead time data (how long it takes the team to complete work (+/-85 percent of the time).

Check out my blog for more info on lead time.


You may be wondering, “should I use Kanban or Scrum?”

While there isn’t a definitive answer for everyone, here are a few guidelines:

For certain types of work, a sprint timebox can add unnecessary overhead. If work requests that are not optional come in frequently, spending the time to plan a sprint’s worth of work could be a waste because new priorities may shift daily. Help desks and maintenance work are classic examples. As customers submit tickets, there’s an agreement that they will all be addressed, unlike new product development. The continuous flow of Kanban works well for this type of work. Work that can’t be split into logical sprint-length chunks, like design, product planning, and data analytics, are also a good fit for Kanban.

Scrum, with its prescriptive framework, can be useful for teams who don’t have the desire or know-how to apply and evolve their process to work in an Agile manner. Scrum’s guardrails, when used effectively, ensure a team is practicing Agile concepts. Kanban is not prescriptive. So, to get the most value from Kanban, teams need to be proactive in evaluating, adjusting, and evolving their processes.

You don’t have to pick only one!

“Various processes, techniques and methods can be employed within the framework.”  – The Scrum Guide 2020.

“There is never a question of using Kanban versus a given methodology or framework. Rather, it is always adding Kanban using an existing methodology, framework, or way of working.” – The Official Kanban Guide – Kanban University

The beauty of both Scrum and Kanban is they both fit well with additional Agile practice techniques! Having a good understanding of both Scrum and Kanban will enable you to strategically apply ideas and practices from either to aid you in meeting your goals. I like to think of all Agile methods, not only Kanban and Scrum, as a collection of tools that organizations can leverage to optimize their delivery of value.

See our upcoming Scrum and Kanban classes here.

You Might Also Like

Agile Training

How Agile Leads to Cost Savings

In the past two decades, Agile methodologies like Scrum and Kanban have exploded in popularity...


Improving Scrum Using Kanban Work-In-Progress Limits

You limit work-in-progress (WIP) in Scrum to the work items in your sprint backlog. Doing...


If You’re Not Using This #1 Kanban Strategy, You’re Losing Time and Money

“Start stopping and start finishing” is the ultimate way to increase efficiency. And yet, none...