How to Set Up and Use a Scrum Board
A Scrum board is a visual representation of the sprint backlog that shows where every task stands in the workflow. It serves as the team's shared truth about sprint status and the central tool for daily standup conversations.
Key Insight
The Scrum board is a communication tool first and a tracking tool second. Its job is to make sprint status immediately readable to any team member without a conversation. If someone needs to ask what stage a task is in, the board is not doing its job.
A Scrum board is only as useful as the team’s discipline in keeping it current. A board updated only on Fridays tells you the sprint status from five days ago. A board updated daily and reviewed in standup tells you the real status and surfaces blockers before they compound. The setup matters, but the discipline matters more.
How to Set Up and Use a Scrum Board in 6 Steps
1
Define Your Board Columns
Start with four columns: To Do, In Progress, Review, and Done. This represents the standard flow for most software work: tasks move left to right through each stage. Add a Backlog column to the left of To Do if you want to keep the full sprint backlog visible on the board. Add a Blocked column between In Progress and Review if blocked tasks are common enough that making them visually distinct is worth the column overhead.
In ClickUp, each column maps to a task status. Create these as custom statuses in your Space settings so they apply consistently across all sprint boards.
2
Set Work in Progress Limits
A WIP limit is a cap on how many tasks can be in a column at once. Setting a WIP limit of 3 on In Progress means no team member starts new work until an in-progress task moves to Review. WIP limits prevent the common failure mode where every task in the sprint moves to In Progress immediately, creating a false sense of activity while nothing reaches Done.
For a team of 5 to 7 people, a reasonable starting WIP limit for In Progress is one task per person plus one. Adjust after two to three sprints based on observed flow.
3
Write Tasks as Actionable Stories
Each task on the board should be completable within two to three days. Tasks that take the full sprint to complete are not tasks: they are epics that need to be broken down. A task title should describe a specific outcome, not a topic. 'Fix login bug' is a topic. 'Fix the null pointer exception that causes logout on Android 14 when location permissions are denied' is a task.
Add a story points estimate to each task before the sprint starts. This is used for capacity planning and velocity tracking, not for time-boxing individual work.
4
Assign and Size Before the Sprint Starts
Every task should have an assignee and a story point estimate before the sprint begins. Tasks without an owner stall. Tasks without estimates cannot be tracked against sprint capacity. During sprint planning, walk through each task as a team: confirm the assignee understands the scope and the estimate reflects realistic complexity, not optimistic effort.
Do not assign all tasks at the start of the sprint. Pre-assign tasks that have clear owners based on expertise. Leave some tasks unassigned and let team members pull them when their previous task moves to Review. Pull-based assignment reduces bottlenecks.
5
Update the Board During Standups
Use the standup to walk the board, not to walk the room. Instead of each person giving their update, move from right to left across the board: start with tasks in Review, confirm they are genuinely done or identify what they need. Move to In Progress, confirm status and surface blockers. Move to To Do, confirm the plan for the day.
Board-first standups produce shorter meetings because the board structure keeps the conversation anchored to specific tasks rather than general status. They also make it immediately visible when the sprint is at risk: a board with many items in In Progress and nothing in Done by day 7 of a two-week sprint is a warning signal.
6
Review and Archive at Sprint End
At the end of the sprint, hold the sprint review before archiving anything. The review should show the board as it stands, including any incomplete tasks. Incomplete tasks return to the backlog for re-prioritization, not automatically to the next sprint. Auto-carrying incomplete tasks into the next sprint without deliberate re-prioritization trains the team to treat incomplete work as acceptable rather than as a signal to investigate.
After the review, archive completed tasks, move incomplete tasks to the backlog, and close the sprint in ClickUp. The velocity dashboard will record the completed story points automatically.
Common Questions About How to Set Up and Use a Scrum Board
What is the right number of columns on a Scrum board?
Four to six columns covers most teams well: Backlog (optional), To Do, In Progress, Review, and Done. Adding more columns like Blocked or Staging is fine if those stages are genuinely distinct and the team consistently moves tasks through them. Avoid creating columns for stages that tasks skip frequently, as sparse columns create noise rather than signal.
Should we use a physical board or a digital one?
Digital boards are more practical for any team with remote members, async workflows, or the need to attach context like comments, files, and links to tasks. Physical boards work well for co-located teams who find the tactile act of moving sticky notes valuable for daily engagement. If your team is hybrid, use a digital board as the source of truth and optionally mirror it physically for in-office days.
What is a WIP limit and why does it matter?
A WIP limit is a cap on the number of tasks allowed in a given board column at one time. It prevents the common pattern where every task moves to In Progress at the start of the sprint, creating an illusion of activity while nothing reaches Done. Limiting In Progress forces team members to finish current work before starting new work, which improves throughput and makes bottlenecks visible faster.