Which would you choose: a fork and knife, a spoon, or chopsticks?
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
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 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
- 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
|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”!)
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.
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.