Kanban vs Scrum boards

11 major 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.

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 – Done columns are not canonic, and usually, teams expand In Process section according to their needs (f. ex. 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 be present on the board: JIRA, Trello, Miro, Leankit, and others.

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 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 the Scrum board, the whole team is devoted to each task

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

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 a 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 build 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 resources 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

Sprint Burndown Chart, Sprint Report, Epic Burndown, Epic Report, Release Burndown, Velocity Chart, Version Report etc.

In KANBAN, particular charts are not prescribed. Although 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 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 being 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.