Kanban - Scrum

In this chapter, we will learn the similarities and differences between Kanban and Scrum. These similarities and differences will help you in choosing the correct method for your project.

Kanban and Scrum - Similarities

Similarities between Kanban and Scrum are −

Both are Agile.
Both use pull scheduling.
Both limit WIP, Kanban at task level and Scrum at sprint level.
Both use transparency across the development.
Both focus on delivering releasable software early.
Both are based on self-organizing teams.
Both require breaking the work into pieces.
In both the methods, the release plan is continuously optimized based on empirical data (Scrum – Velocity, Kanban - Lead Time/Cycle Time).

Kanban and Scrum - Differences

The differences between Kanban and Scrum are as follows −

S.No	Scrum	Kanban
1	Scrum prescribes roles.	In Kanban, roles are optional.
2	Product backlog is to be prioritized.	Prioritization is optional.
3	Sprints are to be time-boxed. You can choose the length of the sprint, but once chosen, the same length is to be maintained for all the sprints.	Time-boxed iterations are optional.
4	Scrum team needs to commit to a particular amount of work for the sprint.	Commitment is optional.
5	Cross-functional teams are prescribed.	Cross-functional teams are optional. Specialist teams are allowed.
6	Uses velocity as default metric for planning and process improvement.	Uses lead time (cycle time) as default metric for planning and process improvement.
7	Items such as stories, tests must be broken down so that they can be completed within one sprint.	No particular item size is prescribed.
8	Sprint backlog shows what tasks are to be executed during the current sprint. These tasks are displayed on Scrum board. Scope of the sprint is fixed. WIP is limited per unit of time (WIP limit is the velocity).	Tasks are defined at workflow level. WIP is limited per workflow state.
9	Additions/Changes cannot be done within a sprint.	Additions /changes can be done if WIP limit is not crossed.
10	New Scrum board is set at the beginning of every sprint.	Kanban board is persistent.
11	Daily meetings need to be conducted.	Daily meetings are optional.
12	Burn-down charts are prescribed.	No particular chart is prescribed.

Kanban vs. Scrum

The following advantages can help you choose between Kanban and Scrum −

You need to choose Kanban if you already have working processes and you want to improve without disturbing the whole system whereas you need to choose Scrum if you want to introduce a new process in the organization.
You can use Kanban in the product development with Feature Driven Development to track the workflows in the value stream whereas you can use Scrum for the development in each iteration.
You need to define the WIP Limits in Kanban explicitly whereas you need to define the sprint length in scrum that imposes WIP limits implicitly.
Both Kanban and Scrum are adaptive but Scrum is more prescriptive than Kanban.
Kanban imposes only two Rules: Visualize workflow and limit WIP whereas Scrum imposes more constraints such as time-boxed Sprints.
Kanban leads to organizational process improvements, both in management and development. Kanban also supports maintenance activities. Scrum leads to high throughput in small development teams. It does not contribute to product development and maintenance workflows that are longer in duration with unpredictability on the size of work units and changes. Scrum does not emphasize on optimizing management activities.
In Kanban, you can choose when to do planning, process improvement, and release. You can choose to do these activities on a regular basis or on-demand. Scrum iteration is one single time-boxed Sprint combining three different activities: planning, process improvement, and release (if required).

Thus, Kanban and Scrum are effective tools in their specific contexts. You can combine Kanban and Scrum to derive maximum benefits from both.

Adapting Kanban and Scrum Together

You can use Kanban and Scrum together by implementing those characteristics that will suit your needs. The constraints of both need to be considered before adapting them. For instance, Scrum requires Time-boxed Sprints and if you do away with those, you cannot say that you have implemented Scrum. Both give you a basic set of constraints to drive your own process improvement.