Scrum vs Kanban

By 3rd September 2015 Agile

Which would you choose: a fork and knife, a spoon, or chopsticks?

Which one utensil would you choose?

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

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

  • 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

ScrumKanban
Time-boxed iterations are an essential partTime-boxed iterations are optional
Team commits to a specific amount of work for each iterationNo such commitment is required
Velocity is the default metric for planning and managing the projectLead time is default metric for planning and managing the project
Cross-functional teams prescribedSpecialist teams allowed
Items must be broken down so they can be completed within a single sprintNo particular item size is required
Burn-down chart usedOnly the board is used
Implicit WIP limits in a sprintExplicit WIP limits per workflow
Estimation necessaryEstimation optional
Cannot add items to ongoing iterationCan add new items whenever capacity is available
The sprint backlog is owned by the teamThe Kanban board may be shared by multiple teams or individuals
Has definite rolesDoesn’t have any roles
Uses a prioritized product backlogPrioritization 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:

  1. 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.
  2. 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.
  3. Versatility: Scrum has a much wider scope than Kanban and offers more of functionalities.
  4. Ease of use: Scrum has a lot more moving parts to keep track of, whilst Kanban revolves almost entirely around managing the board.
  5. 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”!)

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.

 

 

Join the discussion One Comment

  • Hi, I very much liked the cutlery analogies.
    We had to make a choice of scrum or kanban awhile ago in my team, and first we were doing Scrumban (as seen here: http://kanbantool.com/scrumban-kanban-and-scrum) and that kinda worked at first, but then we found we’re lacking some clarity, in mental ways anyway. They guys were not sure which idea to adapt to. Of course, it’s not dead or alive kind of problem, but they were getting confused.
    For over 8 months now we’ve been sticking to Kanban alone. We do prescribe ourselves some time frames, but they are nowhere near as strict as the ones we used to keep in scrum.
    My favorite part is that the kanban process keeps evolving and changes many times during “an iteration”. Whenever we see a potential for improvement, we just go ahead and bring them in. I do feel we are making progress and getting somewhere better with every week. It’s a good position to be in, especially for a fairly new business like mine.
    What have you settled for?

Leave a Reply