Scrum Boards: How to Track Tasks in Your Sprints
Just when you’ve gotten the hang of Scrum’s basics like Sprints, Daily Scrums, and user stories, a coworker pulls up the “Scrum Board.” To you, it looks like a Kanban task board with columns and cards representing to-do items, like you’ve seen in Trello. Your teammate insists it’s different… but can’t quite explain how.
Luckily, we can walk you through the nuances of a Scrum Board and how it’s different from other types of task boards.
In this article, we’ll cover:
- What’s a Scrum Board?
- How a Scrum task board makes your Sprints better
- Five steps to set up your Scrum Board
- Expand your Scrum board to make it even more useful
- Next up: Become a Scrum and Kanban expert
What’s a Scrum Board?
A Scrum Board is a visual representation of the Scrum workflow. It has columns indicating the state of a task, and task cards that move through those columns on their way to completion.
The columns represent phases of the work process – like “To do”, “Doing”, and “Done” – and the cards represent tasks and other work items in your sprint backlog.
Because of this setup, you can look at a board and simultaneously grasp the high-level workflow of your team and the status of individual work items.
So far, you may be thinking there’s no difference between a Scrum Board and a Kanban board or other task board.
Scrum Boards are different because you populate them according to the current Sprint – the work cycle of a Scrum team that usually lasts two weeks.
The development team’s goal is to get all tasks on a Scrum Board to the Done column by the end of the Sprint. This is different to a Kanban board, where items are continuously added to the board and continuously flow through its stages to completion.
The team and Scrum Master use the Scrum Board during Scrum meetings like the Daily Scrum, as it shows which items have problems and deserve discussion. And because team members use the board so often during standups, it acts as a dashboard that reminds them of the Sprint Goal and other metrics they choose to include.
Scrum Boards vs Kanban boards: What’s the difference?
Scrum Boards look like Kanban boards, but they have a few essential differences:
- The Scrum Board gets cleaned out after every Sprint, whereas teams use a Kanban board indefinitely with items continuously flowing through it.
- Kanban boards often have more columns than Scrum Boards to break down the workflow into more granular or task-specific steps.
- You use a Scrum Board with a single team, whereas more than one team can use the same Kanban board for their agile planning and project management.
- Kanban boards often use agile metrics like Work In Progress (WIP) limits for the number of items that can be on the board or in a specific column simultaneously, whereas Scrum does not.
- You can add new items to a Kanban board at any time, as long as they don’t violate the WIP limits. With a Scrum Board, you only add new user stories during Sprint Planning.
How a Scrum task Board improves your Sprints
Scrum Boards have a significant advantage over a simple to-do list. A list of tasks is binary – to do or done? – and lacks detail about your workflow. Whereas a Scrum Board’s columns visualize the entire Scrum workflow and the status of complex pieces of work.
This visual representation improves transparency and accountability, and allows the entire team to spot bottlenecks and opportunities to optimize their workflow. It also gives teams a visual sense of how likely they are to reach their sprint goal.
Another benefit of your Scrum Board is that Scrum rule-breakers have a tougher time getting away with their misdeeds. It’s a lot harder for a Product Owner or any other stakeholder to insert a user story mid-Sprint – instead of during the next Sprint Planning meeting – when they have to add it on a board the entire team constantly monitors during the work day and in the Daily Scrum.
Parabol’s 5 step process to set up your Scrum Board
The official Scrum Guide doesn’t mention having a task board of any kind, so there’s no “official” way to set up a Scrum Board. But some general steps and best practices have emerged over the years.
1. Figure out the different stages of your work process
Even a shared team board with only three columns is better than personal to-do lists. Still, your Scrum process is likely more refined. Every column on your board should reflect a significant step in your workflow.
The most common Scrum Board setup includes these columns, from left to right:
- 📦 Product Backlog holds all the backlog items the team could work on and select for a Sprint.
- 🏃 Sprint Backlog contains the user stories selected for the current Sprint. Some teams call this column “Story.”
- 🛠️ In progress has all the items the team is actively working on. Some teams call this column “Doing.”
- 🔍 Review is for items a team member considers done but need to be reviewed, tested, or approved by someone else. Some teams call this column “Testing” or “To verify.”
- ✅ Done holds the items the team considers finished.
- 🚫 Stuck or Blocked includes all items that need attention to be unblocked. The Daily Scrum is a daily check-in point where the team can clear out this column together and move tasks back into In Progress.
When you create a column, make sure to agree on exit and entry requirements for each stage. In
Applying Scrum with Kanban author Andy Hiles calls this process setting a “workflow policy” for your board.
Say you have a Review column. Who needs to do the review? And what factors determine if the item moves to Done or needs redoing? Such parameters go into your workflow policy, which some teams write at the top of each column.
2. Move all last Sprint’s work items back into the Product Backlog
You move all the items you had on a list or in the To-do column of your previous task board into the Product Backlog column of your new Scrum Board. Or, in case you don’t have any items yet, just move to the next step.
3. Create rows or “swimlanes” for user stories (Optional)
Swimlanes are rows on your board, with one for every user story you select for the Sprint.
The advantage of swimlanes is you can see which tasks belong to which user story (since most include many tasks). You can also check each story’s progress simply by looking at how many of its tasks are moving to the right on your Scrum Board. You only move the overall story card to “Done” once you’ve completed all its tasks.
⚡️ Power tip: One handy idea you can borrow from Kanban is to create a swimlane for recurring tasks that don’t fit within a specific user story. Say you have a monthly report or periodic maintenance work. You can insert such tasks into a swimlane called “Recurring tasks” every other Sprint.
4. Make your Scrum Board visible and accessible
Your Scrum Board must be visible and accessible to the entire Scrum team in your workspace, whether you work with a physical whiteboard and sticky notes or an online Scrum Board.
This transparency reduces the need for constant status updates and preserves more time for deep work. Folks can just glance at the virtual or physical Scrum Board to understand what everyone is working on and the status of different items.
Furthermore you can use the Scrum Board as a sort of team dashboard that reminds everyone of the Sprint Goal and other metrics you choose to display.
5. Set rules for how and when to add new tasks
The development team members can add new tasks to the board at any time during the Sprint, as long as they relate to the selected user stories in the Sprint Backlog. Often they do this during the Daily Scrum meeting.
The Scrum Master plays a critical role here to ensure nobody adds new stories during the Sprint and the tasks the team adds fit with the Sprint Goal and Sprint Backlog.
Expand your Scrum Board to make it even more useful
Once you’ve run a few Sprints with your new Scrum Board, consider expanding it with more columns, metrics, and card types, if you need them. Your board can be customized as you like!
Add more columns
Here are some columns we’ve seen other teams add to their boards:
- ⏰ Waiting for…/Blocked: A place for work items that can’t proceed to Review or Done because of a dependency or other blocker. Items that end up in this column are ideal subjects for discussion during your Sprint Retrospective – they signal friction in your workflow. This column is different from stuck or blocked, which imply a personal blocker rather than a dependency.
- 🏁 Tests specified: A typical agile practice is to write a test that determines whether an item is done or not. You should write such test requirements before you start working on the actual task. Adding this column ensures team members create such a test before moving an item to “In progress.”
- 🎨 Design, UX, development: These columns break down the “In progress” phase into more specific steps an item might go through to reach Done.
- 📝 Notes: A column – usually on the far right of the board – where the team can leave notes related to the current Sprint.
Display helpful metrics
Many teams use the space around their Scrum Board to display critical metrics and information since people view it daily.
A frequent inclusion is the Sprint Burndown Chart. It shows whether you’re on track to complete all the items in the Sprint Backlog. Most teams also display their Sprint Goal on the board, and you can add business metrics and other real-time data, too.
Use colors for different types of work items
You can use colored cards to distinguish between different types of work items. You can, for example, make bugs red, new features green, and regular tasks blue.
Such coloring makes it easy to see what type of work is dominant during each Sprint. Procrastination also becomes visible when all the bugs, for example, stay on the left side of the board while everything else progresses to Done. Sound familiar?
Next up: Become a Scrum and Kanban expert
Next time anyone talks about any kind of task board, you’re ready for their questions or claims. And now that you’ve mastered the nuances of Scrum and Kanban boards, why not dive deeper into the underlying Kanban and Scrum frameworks?
👉️ Check out: Scrum vs Kanban: 5 Differences Between Sprints and Flow.