Scrum vs Kanban : Understand the Difference Between Kanban vs Scrum

The Scrum vs Kanban debate is similar to: Which would you choose: a fork and knife, a spoon, or chopsticks?

Which one utensil would you choose?

It depends on the meal you’re about to eat, of course!

The same argument applies to deciding whether Scrum or Kanban is the methodology that’s most suitable for your project. Each process tool gives you all you require to complete a task effectively, however, any which tool you pick will also have certain limitations that make it less appropriate under certain circumstances.

Undoubtedly, the best way to settle the Scrum vs Kanban debate is to make sure the professionals who use them are knowledgeable about both, and are able to choose the methodology that fits with the project requirements.

In this article, I present an overview of how Scrum and Kanban compare with each other: in which ways they are similar and also how they differ.

Introducing the two methodologies: Kanban vs Scrum

Scrum

In a nutshell, Scrum is an agile framework used to complete complex software projects by splitting the work into a list of smaller tasks that are listed onto a product backlog and then implemented incrementally in a series of short, fixed-duration iterations called sprints.

The people working on these sprints are also split into small, cross-functional, and self-organising teams, with clear-defined roles, such as Product Owner, Scrum Master and Team Members.

As a framework, Scrum is very flexible and encourages team collaboration throughout the development process with the aim of optimising the process by collecting feedback and holding regular meetings, e.g. daily stand-ups, sprint demos, and retrospectives where stakeholders can freely discuss their work.

Kanban

Kanban relies heavily on visualising work through the aid of a board, which is divided into various columns that represent varying levels of completeness of a task (e.g. to do, doing, done). Each task is written on a card which is placed in the column that matches with its status in the workflow.

Kanban places a lot of emphasis on limiting the amount of incomplete tasks in queue by using work in progress (WIP) limits that explicitly limits (?) how many tasks can be in progress at any time. This system is designed to optimise workflow by making it smoother and shortening the lead time as much as possible.

Round #1 – Scrum vs Kanban: the similarities

Before diving into Kanban vs Scrum, we look at the similarities between the two:

Both methods are agile
Both use metrics to determine the optimum amount of work in progress
Both encourage continuous improvement through transparency and collaboration
Both focus on delivering frequent releases
Both are centred around self-organizing teams
Both require splitting the work into smaller tasks

Round #2 – Scrum vs Kanban: the differences

We have discussed about the similarities of Kanban vs Scrum and now we get directly to Kanban vs Scrum:

Scrum	Kanban
Time-boxed iterations are an essential part	Time-boxed iterations are optional
Team commits to a specific amount of work for each iteration	No such commitment is required
Velocity is the default metric for planning and managing the project	Lead time is default metric for planning and managing the project
Cross-functional teams prescribed	Specialist teams allowed
Items must be broken down so they can be completed within a single sprint	No particular item size is required
Burn-down chart used	Only the board is used
Implicit WIP limits in a sprint	Explicit WIP limits per workflow
Estimation necessary	Estimation optional
Cannot add items to ongoing iteration	Can add new items whenever capacity is available
The sprint backlog is owned by the team	The Kanban board may be shared by multiple teams or individuals
Has definite roles	Doesn’t have any roles
Uses a prioritized product backlog	Prioritization of tasks is optional

Deciding which one to use

Given the benefits and drawbacks of both methodologies, it is entirely by to the team to decide—on a case-by-case basis—which framework they think will work best for the situation at hand.

As such, the central question isn’t whether to choose Scrum or Kanban, but rather, which aspects of these two methodologies would serve us best in developing this particular product more effectively.

Phrased in this manner, the choice becomes more of an empirical exercise which the team can do together by studying the requirements and the resources available, rather than basing it on subjective preference.

Indeed, there are some simple criteria which a team should keep in mind in order to help them take a decision:

Start-up time: With Kanban all you need is a table/board and the relevant columns where you can map the statuses of your tasks. Unlike Scrum, Kanban is pretty much an out-of-the-box project management solution.
Level of detail: Scrum comes with an assortment of tools that lets you analyse a project at different levels and from different perspectives. Kanban does not share this level of sophistication.
Versatility: Scrum has a much wider scope than Kanban and offers more of functionalities.
Ease of use: Scrum has a lot more moving parts to keep track of, whilst Kanban revolves almost entirely around managing the board.
Size of the project: Kanban is more suitable when working on a smaller scale, whereas Scrum can tolerate more complexity.

Scrumban: combining both frameworks

Given the benefits inherent in both Scrum and Kanban, it should come as no surprise that people tried to combine the two together into a single framework called Scrumban. (To extend the cutlery analogy at the beginning of this article, think of Scrumban as the agile equivalent of a “spork”!)

What if you could have the best of both worlds?

By using best practices from each methodology, teams can improve their productivity and work together more effectively. The most common way to achieve this is by blending together the fixed length sprints and roles from Scrum with the focus on working in progress limits and cycle time present in Kanban.

I suggest that teams who are still building experience in working agile should stick to only one methodology, and eventually experiment with another one once they’ve mastered the first. Combining the two will then be much easier for such “cross-trained” teams.

Wrap Up

There’s no question that both Scrum and Kanban are fantastic tools for requirements people, testers and developers. Both have been developed to very high levels of complexity throughout the years and you can find a lot of resources that synthesise and summarise the very best practices in both to help you get started quickly. It has never been easier to teach teams how to use both methods and give them the tools to tuck in whichever way they want in the agile buffet. And speaking of tools – a tool such as ReQtest helps you manage requirements, development tasks and testing regardless of your choice of development model.