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.”.
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 –
| Accountabilities | Developers Product Owner Scrum Master |
| Events | The Sprint Sprint Planning Daily Scrum Sprint Review Sprint Retrospective |
| Artifacts | Product Backlog Sprint Backlog Increment |
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 defines some minimum elements as well.
| Practices | Defining and visualizing a workflow Actively managing items in a workflow Improving a workflow |
| Measures | Work In Progress Throughput Work Item Age Cycle Time |
| Work Item Management | Controlling 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 Myth | Fact |
| You need to use story points | Scrum does not require any particular estimation method |
| You can only release at the end of a Sprint | Scrum 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 Myth | Fact |
| There is no commitment in Kanban | The 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 board | A board needs to have six elements of workflow represented in order to be considered a Kanban board |
| Kanban is for maintenance and operational work | Kanban 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?
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.
