Kanban and Scrum boards are usually associated with whiteboards and To Do – In Progress – Done categories. But how do you distinguish one from another? In this article, we collected 11 points showing the key Kanban vs. Scrum board differences.
Also make sure you check our visual guide to Agile, Lean, Scrum, and Kanban which goes a bit deeper into the theory and covers practical aspects of these concepts.
This article is not aimed at judging which one is the best, but to visualize the differences.
Scrum board vs Kanban: Basic definitions
Both Scrum and Kanban boards use Agile methodology to track project status from ideation to completion: setting specific goals, delegating tasks, and plotting workflow.
Scrum boards are more methodical but require more prep time and organization; Kanban boards give team members more leeway but don’t provide the same level of organizational structure. So, which is the best project management methodology for you?
We’ll get into the detailed Kanban vs. Scrum board comparison shortly, but let’s first lay the basic ground for discussion and look at it from a software development perspective. Here’s a very well-done video that will lay the ground for our discussion in this article.https://www.youtube.com/embed/rIaz-l1Kf8w Scrum vs Kanban – What’s the Difference? + FREE CHEAT SHEET
Now that we’ve gone over some basic Kanban vs. Scrum distinctions, let’s dive into some methodology, and terminology and actually compare key elements of Kanban vs. Scrum.
Both Kanban and Scrum boards use sticky notes to communicate the status of the development progress. There are several categories of sticky notes that may appear on the board:
- New Features
- Tasks
- Bugs
- Change Requests
- Technical Requirements (to get work done)
- Knowledge Acquisition (to get work done)
“To Do”, “In Progress”, and “Done” columns are not canonic, and usually, teams expand “In Progress” section according to their needs (e.g., development, testing, etc.).
Since many companies use remote teams virtual whiteboards have become handy tools to facilitate remote collaboration. Various online Kanban and Scrum tools allow the whole team to be present on the board: JIRA, Trello, Miro, Leankit, and other.
Kanban vs Scrum side-by-side comparison
In Miro you are allowed to mark each category with a pre-selected color, shape, or label.
What is a Kanban board?
The Kanban board is a board tracking the process flow while maintaining the number of work-in-progress activities. The number of work-in-progress is small enough to avoid unworthy tasks but big enough to reduce idle personnel. Kanban is like a basketball match, where a completed task equals one point and a team is trying to minimize the time between shots.
Let’s zoom in and see the differences in more detail.
What is a Scrum board?
A scrum board is a Task board tracking work in Sprints. A Sprint is a short, consistent and repetitive period of time. The length of the Sprint is short enough to keep the team focused but long enough to deliver a shippable increment of work. Scrum is like a school test: you have to complete a set of backlog items in a certain period of time. Creating a Scrum board is like studying for the test: it’s a sprint planning tool that allows you to identify what needs to be done and organize your team and schedule.
11 major differences between scrum and kanban boards
1. Work-in-progress limits
Scrum limits work in progress per iteration. The development team has to commit to the number of tasks that they are ready to accomplish during the Sprint. Nothing prevents us from having all items in the In Progress section simultaneously.
Kanban limits work in progress per workflow state. For example, the number five in the pink section means that there shouldn’t be more than 5 items in the In Progress column.
2. Kanban vs. Scrum board: Owners
Scrum board is always owned by one Scrum team (and typically run by a leader called a Scrum Master). A Scrum team is a cross-functional group of employees whose background contains all the skills required for the successful completion of all the tasks during this Sprint.
Kanban board doesn’t need to be owned by a specific team since it’s mostly devoted to a workflow.
3. Rights to make changes for the Product Owner
A Product Owner can’t edit the Scrum board if the team has committed to a number of items for the Sprint. Although the Scrum board is visible to whoever is interested, only the Scrum team (board owners) may edit it.
Kanban can be edited by a Product Owner. According to the Essential Kanban Condensed Guide, Kanban has evolutionarily defined two “hats” that the team members can wear: Service Request Manager and Service Delivery Manager. The “hat” of the Service Request Manager is an alternative to the Product Owner.
4. Task devotion
On Kanban, a team is not originally responsible for all the tasks. Each person is responsible for his/her step on the task flow (coding, testing, reviewing, etc.). However, Kanban has a culture of slack resources to help resolve bottlenecks, when needed. Slack resources are any non-bottleneck resource. So if a person has completed his task while there’s something complicated in testing, he can choose what to do: help the tester to complete the task or take another activity from the queue.
5. Updates within iterations
The Scrum team should not add any new item during the Sprint to the board. The number of items is set during the planning session before the iteration starts.
There are no timeframes for updating a Kanban board (the team estimates the flow using historical data), because it limits the work-in-progress activities. So as soon as any task moves from the In Progress column to the complete section, and the capacity is released, the new item goes under development.
6. Urgencies
Thanks to prior analytical, planning, sizing and prioritization sessions, a Scrum Team shall rarely be faced with unexpected urgencies. One of the main aims of this methodology is to make the product adaptive and the team – predictive.
Some teams add an Urgency section on the Kanban represented as a swim lane where it’s supposed to get maximum speed. It can be an unpredicted urgent task from the Backlog or a bottleneck task from the board. In this case, Urgency tasks receive the first priority for the team so some team members should be sent to accomplish it faster.
7. Backlog
On the Scrum taskboard, the team moves items from the Product Backlog to the Sprint Backlog, which is the list of items they are committed to building in a dedicated period of time.
Scrum considers User Stories as the best practice to decompose big items from a Product Backlog to Sprint Backlog. According to the Agile Guide, features and tasks should be accompanied by details such as acceptance tests, UI sketches, etc.
Kanban is also using a Backlog practice which is generally (BUT not necessarily) equated with a User Story.
8. From backlog to to-do section
If the Scrum team commits to items, then they estimate them as achievable within the Sprint timeframe. If the task is too big for the Sprint it should be split by steps until each step suits the Sprint timeframes.
Despite the tasks moving from the Backlog to To Do section through Proposals and the Commitment Point, there is no specific rule regarding the volume of the task in Kanban.
9. Prioritization
In Scrum, prioritization is a must. Usually, it includes sorting and grooming the Product backlog for the current sprint, setting priorities, and resource estimation during the daily Scrum meetings. During prioritization, it’s important to predict what will be important for the NEXT (not the current) Sprint.
Kanban does not use a prioritization or estimation scheme but considers project planning using probabilistic forecasting.
10. Reports
Scrum uses Velocity as the primary metric, accompanied by a range of charts and reports:
Sprint Burndown Chart, Sprint Report, Epic Burndown, Epic Report, Release Burndown, Velocity Chart, Version Report etc.
In Kanban, particular charts are not prescribed. However, the following reports are better to be pinned to Kanban since its primary metric is a Lead Time: Control Chart that measures the cycle time for issues and a Cumulative Flow Diagram that shows the various statuses of work items for a particular time interval.
11. Resetting periods
In Scrum all the stickers should be in the final Done section at the end of each Sprint, otherwise, the Sprint is considered as unsuccessful. After the Sprint retrospective, all the stickers are removed to clear the board for the next Sprint. The process of resetting the board can give a nice sense of accomplishment and closure.
Kanban is a persistent tool with no timeframes so it is not necessary to reset it and start over. The flow continues with the project life cycle and the new items (stickers) are added as soon as the need arises.
Sidenote
All images for this article are from the map built in Miro.
As you can see both Kanban and Scrum boards are not isolated. Having the whole process of creating and updating the two most popular visual management tools on one page is quite useful.
Also, let me remind you that this article was not aimed to define which tool is better since there is no competition between them. Many coaches advise you to define what works better for your particular team in order to implement customized Scrumban (Scrum + Kanban) and achieve better results.
Virtual boards provide a significant advantage over physical boards: if you want to try Miro for Agile planning with your remote team, check out:
— Pre-ready visual planning templates;
— Our case study with a focus on story sizing in Miro;
— Our case study with nice retrospective examples;
— An article comparing Agile and Lean, Scrum and Kanban.
Learn more about Agile workflows and what your team can do with Miro
