Scrum and Kanban are teamwork methods that share many similarities. However, there are also differences that we would like to discuss today. Kanban boards are also often adopted by Scrum Teams. This is because they are very practical in visualizing teamwork and its progress. By combining the best of both methodologies, there appeared a technique called Scrumban. It is popular in projects that combine Product development with service delivery, where long Sprints and relatively formalized Scrum meetings are not always suitable.

Scrumban and Kanban boards in Scrum – table of contents:

  1. Introduction
  2. Kanban vs Scrum
  3. Kanban Boards in Scrum
  4. Scrumban
  5. Summary

Introduction

Kanban is a method pioneered in Japan. It originated in the 1950s and was primarily a tool for managing continuous production in such a way as to not create inventories and surpluses, but to process resources on an ongoing basis. In the early 21st century Kanban was adapted to the needs of software development by David J. Anderson.

Kanban vs Scrum

The overall way of working in Kanban differs from Scrum primarily by bringing about a less formal approach. In Kanban, there are not so detailed guidelines on, for example, working in Sprints, roles of Product Owner, Scrum Master and Development Team. This is possible because Kanban focuses on the continuity of tasks such as providing a specific type of service, which are more repeatable and does not require such complex planning.

However, the purpose and ways of working are similar. The goal of Kanban is to deliver the highest quality product to the customer on time. The principles concerning the ways of working common to both methods can be formulated as follows:

  1. The work should be smooth and without any downtime – in Scrum, this is achieved by the continuous succession of Sprints, while in Kanban the work is continuous due to the smooth flow of tasks. They form a queue, from which the developers choose (pull) a few tasks to complete.
  2. The team should focus only on selected tasks – using Kanban terminology, the team should “reduce work in progress”. In Scrum, the equivalent of this is User Stories chosen from the Product Backlog to put into the Sprint Backlog
  3. Progress of tasks should be visible for all people involved – in Kanban they are visualized by boards, which are also often featured in Scrum Teams.

Kanban Boards in Scrum

A Kanban board is a widely used tool for visualizing teamwork. It is a table with several columns. In each of them, there are tasks with a certain status. Categorization of tasks is based on a simple rule: a card with a description of the task – or its virtual equivalent – is placed in one of the columns. The minimum version of Kanban boards contains three columns:

  • To do
  • In progress
  • Completed – to the last column go the tasks that meet the Definition of Completion, about which we wrote here.

Below you can find an example of a kanban board from an all-in-one project management systemFirmbee.com

Kanban boards in Scrum and Scrumban

Commonly, there are more columns. If there are more tasks to complete, there is usually an additional column titled “selected for completion” between the “to be completed” and “in progress” columns. While the “to-do” column serves as the Product Backlog, which we wrote about here, the “selected for completion” column serves as the Sprint Backlog, which we describe in detail in this article.

The second common addition is an “under review” column or “for approval”. It is usually inserted between the columns containing the “in progress” tasks and the “completed” ones. It contains tasks completed by the Development Team that is waiting for approval from the Product Owner. The Product Owner’s task is to check their compliance with the acceptance criteria and get their final approval from the Customer. In this situation, only the finally accepted tasks are moved to the last column.

Scrumban

Due to the huge popularity of Scrum and Kanban, their hybrid appeared, combining the best of both ways of working. Scrumban works best in organizations that connect the creation of Products with the provision of services, often involving the implementation of the Product at the Customer. Because of the reduction in meetings and communication, the Team can be larger.

Scrumban places less emphasis on metrics commonly used in Scrum, such as the Burndown Chart. However, it uses the Scrum pillars of the need for continuous improvement of the work process and adapting them to the customer’s conditions and needs.

When working in Scrumban, however, the work is not divided into Sprints. Scrum meetings are held every 3, 6, or 12 months.

Scheduling of work follows the “On-Demand” principle, i.e. as it occurs. User Stories are placed directly in the first column of the Kanban board containing “to-do” tasks. Thus, it serves as the Sprint Backlog, which we wrote about in more detail in this article. As in the Sprint Backlog, the most urgent tasks are placed at the top of the to-do list. However, for more complex projects, the Project Manager can maintain a separate to-do list corresponding to the Product Backlog, from which he or she selects which tasks to place in the first column.

When moving tasks from the first to the second column, the “Pull” rule applies. It means that tasks are not delegated to a particular Developer. Each person chooses a task from the queue and executes it independently.

The number of tasks placed in the middle column, “to complete” is usually limited depending on the size of the team, so that, if possible, everyone deals with only one task at a time.

kanban

Summary

Scrum and Kanban, although used for similar purposes, are different ways of working. Scrum works best in creative, innovative projects done by small Scrum Teams. Kanban, on the other hand, was created to operate in a continuous and downtime-free environment to provide similar services. Scrum often uses Kanban boards as a method to visualize the work being done. The combination of both resulted in Scrumban, which works best as a framework for organizations that sell their products and provide services based on them to the customer.

If you like our content, join our busy bees community on Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Scrum Guide | 33. Scrumban and Kanban boards in Scrum caroline becker avatar 1background

Author: Caroline Becker

As a Project Manager, Caroline is an expert in finding new methods to design the best workflows and optimize processes. Her organizational skills and ability to work under time pressure make her the best person to turn complicated projects into reality.

Scrum Guide:

  1. Glossary of basic terms, roles and notions
  2. What is Scrum?
  3. Scrum values
  4. How to implement Scrum in your company?
  5. Scrum Team - what is it and how does it work?
  6. Who is a Product Owner?
  7. The most common mistakes of Product Owner
  8. Who is the Scrum Master?
  9. Characteristics of a good Scrum Master
  10. The most common mistakes of Scrum Master
  11. What statistics and metrics should the Scrum Master track?
  12. Cooperation between Product Owner and Scrum Master
  13. Development Team in Scrum
  14. The most common mistakes of Developers
  15. Scrum artifacts
  16. Scaling Scrum
  17. Sprint Backlog
  18. What is the Product Backlog?
  19. What are User Stories?
  20. Creating the best User Story with INVEST
  21. The most common User Story mistakes
  22. User Story Acceptance Criteria
  23. Estimation and Story Points in Scrum
  24. Planning Poker
  25. Team Estimation Game
  26. Defining Increment
  27. Scrum events
  28. What is Sprint in Scrum?
  29. Scrum Team Commitments - Product Goal, Sprint Goal and Definition of Completion
  30. What is a Burndown Chart?
  31. How to create and interpret a burndown chart?
  32. Advantages and disadvantages of the burndown chart
  33. Kanban boards in Scrum and Scrumban
  34. Velocity in Scrum - Speed of the Development Team
  35. Daily Scrum
  36. Sprint Planning
  37. Sprint Review
  38. What is a Sprint Retrospective?
  39. Common mistakes during a Sprint Retrospective
  40. Product Backlog nurturing