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:
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:
- 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.
- 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
- 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 system – Firmbee.com
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.
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.
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.
- Glossary of basic terms, roles and notions
- What is Scrum?
- Scrum values
- How to implement Scrum in your company?
- Scrum Team - what is it and how does it work?
- Who is a Product Owner?
- The most common mistakes of Product Owner
- Who is the Scrum Master?
- Characteristics of a good Scrum Master
- The most common mistakes of Scrum Master
- What statistics and metrics should the Scrum Master track?
- Cooperation between Product Owner and Scrum Master
- Development Team in Scrum
- The most common mistakes of Developers
- Scrum artifacts
- Scaling Scrum
- Sprint Backlog
- What is the Product Backlog?
- What are User Stories?
- Creating the best User Story with INVEST
- The most common User Story mistakes
- User Story Acceptance Criteria
- Estimation and Story Points in Scrum
- Planning Poker
- Team Estimation Game
- Defining Increment
- Scrum events
- What is Sprint in Scrum?
- Scrum Team Commitments - Product Goal, Sprint Goal and Definition of Completion
- What is a Burndown Chart?
- How to create and interpret a burndown chart?
- Advantages and disadvantages of the burndown chart
- Kanban boards in Scrum and Scrumban
- Velocity in Scrum - Speed of the Development Team
- Daily Scrum
- Sprint Planning
- Sprint Review
- What is a Sprint Retrospective?
- Common mistakes during a Sprint Retrospective
- Product Backlog nurturing