Scrum vs Kanban boards: 11 major differences

Kanban board and Scrum board are usually associated with whiteboards and To Do – In Progress – Done categories. But how do you distinguish one from another? In this article, we have collected 11 points showing the major differences between Kanban and Scrum boards: two popular visual management tools.

This article is not aimed at judging which one is the best, but to visualize the differences.

Basic definition of Kanban board and Scrum board

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;



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 are equipped with a remote workforce, they use not only physical whiteboards. Various online Kanban and Scrum tools allow the whole team be virtually present on the board: JIRA, Trello, RealtimeBoard, Leankit and other.

In RealtimeBoard you are allowed to mark each category with pre-selected color, shape or label.

Kanban board

Kanban boards step by step from Giulio Roggero

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 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 details.

Scrum board

Scrum Board Step by Step

Scrum board is a 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 shippable increment of work. Scrum is like a school test: you have to complete a set of tasks in a certain period of time. And no other activities allowed

Work in progress limits

Scrum limits work in progress per iteration. The team has to commit to the number of tasks that they are ready to accomplish during the Sprint. Nothing prevents from having all items in the In Progress section simultaneously.

Kanban limits work in progress per workflow state. For example, number five in the pink section means that there shouldn’t be more than 5 items in the In Progress column.

Kanban board vs. Scrum board: owners

Scrum board is always owned by one Scrum team. A Scrum team is a cross-functional group of employees whose background contains all the skills required for 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.

Changes rights 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 Scrum board is visible to whoever is interested, only Scrum team (board owners) may edit it.

Kanban board can be edited by a Product Owner. According to Essential Kanban Condensed Guide, Kanban has evolutionary defined two “hats” that the team members can wear: Service Request Manager and Service Delivery Manager. The “hat” of Service Request Manager is an alternative to the Product Owner.

Task devotion

On Scrum board, the whole team is devoted to each task

On Kanban board, 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 a something complicated in testing, he can choose what to do: help the tester to complete the task or take another activity from the queue.

Updates within an iteration

Scrum team should not add any new item during the Sprint to the board. The number of items is set during 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 completed section, and the capacity is released, the new item goes under development.

Get a 30-day Free Trial

Try Realtimeboard to stay focused and informed

No credit card required


Thanks to prior analytical, planning, sizing and prioritization sessions, a Scrum Team shall rarely be faced with unexpected urgencies. One of the main aim of this methodology is to make the product adaptive and the team – predictive.

Some teams add an Urgency section on Kanban board 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 task receives the first priority for the team so some team members should be sent to accomplish it faster.


On the Scrum board, 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 with 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.

From backlog to to do section

If 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 the each step suits the Sprint timeframes.

Despite the tasks move 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.


In Scrum, prioritization is a must. Usually, it includes sorting and grooming the Product backlog, setting priorities and resources estimation. During prioritization, it’s important to predict what will be important for the NEXT (not the current) Sprint.

Kanban do not use prioritization or estimation scheme, but considers project planning using probabilistic forecasting.


Sources of the charts pictures, used on the board: Wikipedia, Targetprocess, Atlassian.

Scrum is using a Velocity as the primary metric, accompanied with 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. Although the following reports are better to be pinned to Kanban board 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.

Resetting periods

At the end of each Sprint all the stickers should be in the final Done section, otherwise the Sprint is considered as unsuccessful. After the quick 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 board 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.


All images for this article are from the map built in RealtimeBoard.

As you can see both boards are not isolated. Having the whole process of creating and updating two most popular visual management tools on one page is quite useful.

Also let me remind that this article was not aimed to define which tool is the best since there is no competition between them. Many coaches advise to define what works better for your particular team in order to implement customized Scrumban (Scrum+Kanban) and achieve better results.

If you want to try RealtimeBoard for Agile planning with your remote team, check out:

— pre-ready Visual planning templates;

— our recent case study with a focus on story sizing in RealtimeBoard;

— our recent case study with nice retrospective examples;

— an article comparing Agile and Lean, Scrum and Kanban.

If you know of additional differences between Scrum board and Kanban board that are not mentioned in this article feel free to share them in the comments field! We would love to discuss and update the article.

  • hengels

    Great article. It helped me a lot to make a decision what to use in JIRA. Thank you.

  • Awesome post, Natalie! Good overview and some cool examples using the the tool.

  • Justyna Pindel

    Good to read! Thank you 🙂 I use Kanbanery and literally, I love it! Your post will help me to make it even more productive!

What to read next:
Over 1,000,000 project leaders, marketers, designers, developers and creatives trust us worldwide.
49D45371-3741-47B6-A405-E7F59FC490F8 Created with sketchtool. CBF1CF60-720A-4C6C-9EAF-AAB7DCF790B3 Created with sketchtool. 8284589B-8B7E-4A34-B044-B30C6E0413E4 Created with sketchtool. pdf Created with Sketch. 9758F27C-DEBF-4E3B-A60D-64FC34F0846A Created with sketchtool. FE695667-7811-47C2-A48F-232F5268CA04 Created with sketchtool. BC8C23D0-913C-4B78-A357-47DD3050A246 Created with sketchtool. 3F252687-0750-4634-B414-6E1FCF7080FB Created with sketchtool. 91908614-38FB-46A0-B6F0-DF62FA1A7127 Created with sketchtool.

Product Management Today