Scrum and Kanban

Agile implementations take many forms. The two most common forms are Scrum and Kanban. Navigating through the noise around these two can be hard. Type “Kanban vs” into google and it will autocomplete it with “Scrum”. Here, we try to clear up the confusion and answer the question of which one should you choose.

You probably ended up on this page for one of the following reasons –

  • You are currently using either one of Scrum or Kanban and want to explore the other one
  • You are newly introduced to Agile and are exploring options
  • You got into some heated Social Media argument about Agile (or Scrum or Kanban)

Whatever your journey to this page (especially if it is the last one), hopefully, we can help clear the fog around these approaches to Agile.

Definitions of Kanban and Scrum

Let us start with a base understanding of Scrum and Kanban.

Scrum definition

The definition of Scrum is contained in the Scrum Guide. Per the guide, “Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.”. 

Scrum Definition

There are some elements that are required by Scrum. Per the Scrum guide, if you are not incorporating the following in your process, you are not doing Scrum – 

Product Owner
Scrum Master
EventsThe Sprint
Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospective
ArtifactsProduct Backlog
Sprint Backlog

Kanban definition

The minimum requirements to implement and operate a Kanban system are described in the Kanban Guide. Per the guide, “Kanban is a strategy for optimizing the flow of value through a process that uses a visual, pull-based system.”

Kanban Definition

Kanban defines some minimum elements as well.

PracticesDefining and visualizing a workflow
Actively managing items in a workflow
Improving a workflow
MeasuresWork In Progress
Work Item Age
Cycle Time
Work Item ManagementControlling Work In Progress
Service Level Expectation

The elements described for both these process management techniques are the minimum requirements. Both guides are intentionally incomplete. 

Most teams will need more than the elements described in each guide in order to effectively operate their processes. This is both an opportunity to adapt these Agile techniques to your context and to unintentionally misuse them. The repeated misunderstanding and misuse of these have given rise to multiple myths about the two.

Myths about Kanban and Scrum

To answer the question of “Which one is better for me?” becomes clearer once we start debunking the common myths that have gotten attached to both Scrum and Kanban. 

There are many practices that over time have come to be associated with both of these, which are neither required nor (most of the times) helpful.

Scrum MythFact
You need to use story pointsScrum does not require any particular estimation method
You can only release at the end of a SprintScrum supports the ability to deliver multiple times in a Sprint
Standups have to use the “3 questions”Standups can be run in any way the team wants as long as it helps with progress toward the Sprint Goal
Kanban MythFact
There is no commitment in KanbanThe Service Level Expectation is an explicit commitment for each work item in a Kanban system
Putting stickies on a board with stages marked out is a Kanban boardA  board needs to have six elements of workflow represented in order to be considered a Kanban board
Kanban is for maintenance and operational workKanban can be used for any type of knowledge work. Many teams use Kanban for greenfield product development

Final Myth – It is not Scrum vs Kanban, it is Scrum and Kanban

The final and biggest myth out there about Scrum and Kanban is that they are incompatible. A careful reading of the Scrum Guide and the Kanban Guide might help us find out how compatible they are. The Scrum Guide is more involved, it lays out the roles, the events, and the artifacts for operating a Scrum team. It also specifies that the guide itself is intentionally incomplete. The Kanban Guide lays out the three practices that are needed to operate a Kanban system

  • Defining and visualizing a workflow
  • Actively managing items in a workflow
  • Improving a workflow

These practices laid out by the Kanban Guide and the roles, events, and artifacts laid out in the Scrum Guide do not contradict each other in any way. On the other hand, they are complementary. The intentionally incomplete Scrum Guide and intentionally non-prescriptive nature of Kanban can easily be combined to great effect. These two are not at odds with each other, instead, they improve each other.

So, Which One Should You Choose?

Scrum or Kanban
Photo by Karolina Grabowska on

We have good news and bad news. The bad news is no one can really tell you which system will work better for you. Every context and team makeup demands a deeper investigation to find out what would work best. The good news is you don’t have to choose. The two work very well together. Pick one of the two to start with, whichever feels easier to implement, and then augment it with the other. The most successful Agile teams borrow elements from both systems.

You can use the metrics and analytics commonly used in Kanban to enhance Scrum implementations. Similarly, you can use the roles and events recommended by Scrum to enhance your Kanban implementation. Pick one of the two systems (we are biased towards Kanban) and if it does not get you all the results you were looking for, enhance it by adding the other. 

Interested in learning more about Kanban – Check out our Learning Resources and the Courses available.