What is a Scrum Board? 7 best examples you can use today!

The fundamentals of Scrum is simple: build features in smaller increments while getting consistent feedback from customers. That way, you can quickly course correct and build features that delivers value.

Getting it right, however, isn’t easy.

You need to prioritize user stories, plan your sprint, collaborate cross-functionally, and get a clear picture of the progress at multiple levels — user story, team, sprint, and the feature as a whole. This is where a Scrum Board comes into a play.

Without a scrum board, it can get hard to organize your sprint plan and get a quick pulse of what’s happening.

Luckily, we’ve talked to several teams who use Scrum Boards and we’re going to share with you 7 examples of scrum board, how to use them, and when to use them.

Before I get into it, let’s take a look at the fundamentals of the scrum board first.

What is a Scrum Board?

A scrum board, also called as a sprint board or scrum task board, is a tool that helps a scrum team visualize the sprint backlog items and its progress. It can be either a physical or a virtual board with different structures, with all of them solving the same purpose — helping teams visualize the sprint.

Naturally, it is ideal for teams who plan their work in sprints. It is updated and maintained by the scrum team.

Once a prioritized set of user stories are added to the sprint, at a minimum, a scrum board contains three columns:

1. Todo: The todo column consists of all the prioritized user stories, tasks, subtasks, and bugs. They appear on the board as a card with details such as who it is assigned to, an estimate of how long it’ll take to complete, and a due date.
2. In progress: The in progress column consists of all the items the team has begun working on.
3. Done: The done column consists of all the items that are completed.

Here’s how it looks:

How does a Scrum Board work?

Using any scrum board involves three steps.

The first step is called the product backlog prioritization. The product owner plans all the features by writing a series of user stories, acceptance criteria, tasks, subtasks, enhancements, and bugs. They add a description to each of these items. Perhaps adds a couple of snippets of text from conversations they had with the user.

The second step involves coming up with a sprint backlog. The scrum team collectively discusses the product backlog in a sprint planning meeting and adds the most important items based on a theme into the sprint. Once finalized, these items are added to the first column of the Scrum Board, so everyone in the team can see them.

Next, when the sprint begins, each member of the team picks up the item assigned to them and begins moving the item from one column to another. Once an item has fully progressed to the last column — the done state — the team member returns to the first column and repeats this step until they don’t have any more items assigned to them.

The goal is to move all the items from the first column to the last before the sprint ends.

As your team matures and becomes more experienced, you’d want to track three extra details:

1. Sprint goal: Having a clear understanding of the sprint goal helps the team to keep their plans tightly focussed.
2. Burn up and Burn down charts: The burnup and burndown charts is a great way to see how your team is making progress over time. It helps identify roadblocks and understand your team’s efficiency.
3. Sprint overview: Getting a quick overview of what’s happening is crucial in the middle of the sprint. This means knowing the duration of the sprint, its status, the number of open items, estimates remaining, and a completed percentage. And before you begin the sprint, this acts as a summary of the amount of work your team will be working on.

Normally, a scrum master is in charge of setting up and making sure the scrum board is always updated. However, all team members should be able to access and update it. Which is why, unless every member is located in the same room, most teams and organizations prefer to use an online scrum board tool.

Choosing a Scrum Board — Physical vs Online

Given the situation we’re all in, most of us are left with no choice but to use an online scrum board. However, if you’re a team that still manages to physically meet, then you might be able to use a physical scrum board.

But that shouldn’t be the only variable for you to choose between a physical and an online scrum board.

To identify which is a better solution for your team, it’s essential to know what your team’s strengths, weaknesses, and needs are.

While no article or guide can tell you what those are, here’s how a physical and online scrum board stack against each other:

Physical Scrum Board

1. A physical scrum board works perfectly when your entire team is located in a single room or a floor.
2. It can serve as a constant reminder of what’s happening.
3. It facilitates daily scrum standup meetings and promotes face-to-face interaction.

Online Scrum Board

1. An online scrum board is ideal if your team works remotely.
2. If you work in a large team, you’ll benefit from the automatically generated reports.
3. Enables multiple users to work synchronously.
4. Gives you the option to restrict access depending on who’s involved in the sprint.

Related read: If you're frustrated with your current way of working, you might be interested in exploring the top scrum tools for your next sprint. Here are 9 best scrum tools you should consider.

7 examples of a Scrum Board

While Scrum doesn’t prescribe a format for a Scrum Board, teams must go through a series of experiments to see what works for them. Below, you’ll find 7 examples of scrum boards used by several teams. You can take inspiration from it, see how to use them, and get started quickly.

1. Simple scrum board

As mentioned earlier, the simplest version of a scrum board contains three status columns:

1. Todo: All prioritized sprint items start from the todo column.
2. In progress: This column communicates that a specific item is being worked upon.
3. Done: This column is used to communicate when the item has been completed.

This is ideal for a small team (< 5 members) who are new to agile or scrum and don’t require fine-grained updates.

2. A scrum board with a separate column for all stories

This version of the scrum board is the most popularly used. It contains five status columns:

1. Backlog/Stories
2. Todo
3. In progress
4. Review
5. Done

As you can see, the only difference between this example and the previous example is the extra column named “Backlog” at the beginning and a “Review” column before the “Done” state.

The “Backlog” column is where all the sprint backlog items are added at first before they are moved to the “Todo” state. This “Backlog” column must not be confused with the “Product Backlog”.  

The “Todo” column is used to represent all the items for which work hasn’t started yet. And the “Review” column is added to make sure developers spend time reviewing their code before it is marked as completed.

This type of scrum board, like the previous example, is ideal for small teams (< 5 members).

3. Scrum board including QA

In the previous two examples we saw, all members, irrespective of which discipline they belong to, use a column that’s common to all. In this example, a new column is added that’s dedicated specifically for the QA team.

1. Backlog
2. Todo
3. In progress
4. Ready for QA
5. Review
6. Done

The “Ready for QA” column is dedicated to the QA process. Once a user story is developed, the developer moves it to “Ready for QA”. This helps members of the QA team to know they can begin testing. If there are no issues in the functionality, the QA team moves it to the “Review” column for the code review. Otherwise, it is moved back to the “Todo” column.

When the QA team moves an item back to the “Todo” column, they must communicate the reasons behind by adding comments. This will help the respective developer get a perspective of what needs to get fixed.

This scrum board is ideal for a team who have a dedicated QA person.

4. A scrum board including Design and QA

Similar to the previous example, apart from a dedicated column for the QA team, there’s also one for the design team.

1. Backlog
2. Todo
3. Design in progress
4. Dev in progress
5. Ready for QA
6. Review
7. Done

This scrum board is ideal when there is plenty of design work to be done before the development can begin. In most cases, this means when there’s a pile of front-end specific work items that needed to be done in the sprint.

If there is any work item that doesn’t require design, the team will move the item from “Todo” to “Dev in progress” directly. Otherwise, the item moves through “Design in progress”.

5. A scrum board that takes blockers into consideration

This scrum board is designed to help the team communicate they’re being blocked.

1. Backlog
2. Todo
3. Design in progress
4. Dev in progress
5. Blocked
6. Ready for QA
7. Review
8. Done

The “Blocked” column is added in after all in progress columns and before it is delivered to QA.

Any item could be moved to a “Blocked” state due to either poor communication, lack of planning, lack of backlog refinement and/or weak dependency management. Other scenarios where an item could be blocked could be due to unforeseen circumstances that prevented the work from being done. When blocked, teams need to communicate why they’re blocked in the comments area, so everyone is aware of the latest situation.

This type of scrum board is ideal for larger teams (> 10 members) and/or when working remote.

6. A single scrum board with multiple statuses for multiple teams

This scrum board is similar to the previous examples in that it includes multiple teams. The only difference is, it includes multiple statuses for each of those teams.

Here’s an example of the different columns it contains:

1. Backlog
2. Todo
3. Design in progress
4. Design Done
5. Dev in progress
6. Dev done
7. Ready for QA
8. QA Tested
9. Review
10. Done

As you can imagine, having too many columns makes the scrum board hard to manage. However, as teams grow bigger, the need for more fine-grained updates also increases, which leads to scrum boards such as this.

While this type of board isn’t ideal, it is often seen among larger teams (> 10 members)with multiple members from multiple disciplines.

7. Example of having multiple scrum boards for each discipline

In the previous example, you witnessed a scenario where a team requires multiple statuses for multiple teams and it got unwieldy too quickly. In such scenarios, it is better to have multiple boards for each discipline.

Design Board:

1. Todo
2. Building mockup
3. Design Ready

Dev Board:

1. Todo
2. In progress
3. Review
4. Done

QA Board:

1. Todo
2. QA tested
3. Done

A caveat to this example is, you need a tool that allows you to seamlessly move an item from one board to another without having to set up multiple configurations.

An equally important aspect is the ability to know that an item has moved from one board to another.

An advantage of tracking your Sprint using multiple Scrum Boards is that it allows you to track:- A user story- A specific team- Manage workload in each team- And get the complete picture of the progress of the entire sprint

This type of scrum boards is ideal for large teams who require fine-grained updates at different phases of the sprint.

What next?

That’s it! You’re ready to start using a project management tool that supports the Scrum Board.

From here, it’s about making sure you pick the tool that lets you quickly visualize and get started without any hassle.

The tool should enable you to track progress at multiple levels — user story, sprint, specific team, in the scrum board, and at a feature level. Without this perspective from multiple levels, removing inefficiencies in your development process and shipping on time will be nearly impossible.