Scrum Board Setup Guide: Physical, Digital, and Hybrid Options

That Board Nobody Updates Anymore

Every team has been here. Someone set up a beautiful Scrum board with colour-coded tickets, well-defined columns, and swimlanes for every team member. It looked great for about two weeks. Then the standups got sloppy. People stopped moving their cards. The board drifted out of sync with reality. Eventually it became wallpaper that everyone walked past without looking at.

The board failed. But not because it was the wrong tool. It failed because the setup didn’t match how the team actually works. A Scrum board that nobody updates is worse than no board at all because it gives you false confidence about where things stand.

Let’s set one up properly this time.

What a Scrum Board Actually Does

A Scrum board makes the sprint’s work visible at a glance. It shows what hasn’t been started, what’s in progress, and what’s done. That’s the core job. Everything else is refinement.

In Scrum, the board represents the Sprint Backlog. During Sprint Planning, the team selects items from the Product Backlog and places them on the board. Throughout the sprint, cards move from left to right as work progresses. During the Daily Scrum, the team references the board to discuss progress and blockers.

A well-maintained board answers three questions instantly: Where are we in this sprint? What’s blocked? Is anyone overloaded?

The Basic Column Structure

Start simple. You can always add complexity later, but you can never easily undo a board that started too complicated.

The minimum setup is three columns:

To Do contains all the items the team committed to for this sprint that haven’t been started yet. These came from Sprint Planning. Nothing else goes here mid-sprint without a deliberate conversation.

In Progress shows work that someone is actively working on right now. The key word is “actively.” If a developer started something on Monday but has been pulled to a different task, that card shouldn’t still sit in In Progress pretending to be worked on.

Done means the work meets the team’s Definition of Done. Not “code complete.” Not “waiting for QA.” Done means done. If your team has a different interpretation, that’s a conversation worth having before you set up the board.

When to Add More Columns

Three columns work for small teams with simple workflows. Most teams eventually benefit from splitting “In Progress” into more specific stages. Common expansions include:

To Do | In Development | In Review | Testing | Done

This works when your team has a clear handoff between development, code review, and testing. Each column represents a distinct phase where different people or skills are involved.

Some teams add a “Ready for Review” or “Blocked” column. This can be useful if work frequently stalls waiting for someone’s attention and you want to make that wait state visible rather than hiding it inside “In Progress.”

The rule of thumb: add a column only when an invisible handoff or wait state is causing problems. If adding the column doesn’t change anyone’s behaviour, it’s just decoration.

Physical Scrum Boards: Whiteboard and Sticky Notes

There’s something about a physical board that digital tools still can’t replicate. The tactile satisfaction of peeling a sticky note and moving it to the Done column. The impossibility of ignoring a wall of bright yellow cards. The accidental conversations that happen when someone stops to look at the board.

What You Need

A large whiteboard (at least 4 feet wide), a pack of sticky notes in 3 to 4 colours, painter’s tape or whiteboard tape for column dividers, and markers. That’s it. Total cost: under $50.

Use different sticky note colours to represent different types of work. Yellow for user stories, pink for bugs, blue for technical tasks, green for spikes or research. This gives you an instant visual breakdown of what kind of work the team is doing without reading a single card.

What Goes on Each Card

Keep it brief. A physical card should have: the item title, the story point estimate (if your team uses them), the assignee’s initials, and the ticket number if you’re cross-referencing with a digital tool. That’s enough. If someone needs more detail, they look it up in the backlog tool.

Strengths of Physical Boards

They’re impossible to ignore. You walk past them every day. They encourage conversation. They’re fast to update during standups. And there’s no login, no loading screen, no “Jira is down” problem.

Physical boards also make problems visible in a way digital tools don’t. When one column is overflowing with sticky notes and another is empty, everyone can see the imbalance from across the room.

Weaknesses of Physical Boards

They don’t work for remote teams. They don’t persist if someone bumps the board or the sticky notes lose their adhesive. They don’t generate metrics automatically. And they require the team to be co-located, which is increasingly rare.

Digital Scrum Boards: Tool Comparison

Most teams in 2026 use a digital board, either because they’re remote, distributed, or because their organisation requires digital tracking for reporting purposes. Here’s how the major options compare.

Jira

The industry standard for enterprise Scrum teams. Jira offers the most customisation: custom workflows, swimlanes, filters, reporting dashboards, and integrations with nearly every development tool.

Best for: Mid-to-large teams, organisations that need detailed reporting, teams already in the Atlassian ecosystem.

Watch out for: Over-configuration. Jira’s flexibility is both its strength and its biggest risk. Teams that add too many custom fields, statuses, and workflows end up spending more time managing Jira than managing work. Start with a simple board and resist the urge to customise everything on day one.

Trello

Simple, visual, and fast. Trello’s card-and-board interface is the digital equivalent of sticky notes on a whiteboard. It’s intuitive enough that most people can start using it without training.

Best for: Small teams, non-technical teams, teams new to Scrum, and anyone who values simplicity over feature depth.

Watch out for: Scaling limits. Trello works great for one or two teams but gets unwieldy when you need cross-team visibility, advanced reporting, or complex workflows. Power-Ups can extend its capabilities, but they add cost and complexity.

Azure DevOps

Microsoft’s offering combines boards, repos, pipelines, and test management in one platform. If your team is already using Azure for CI/CD and source control, the board integration is tight and convenient.

Best for: Teams in the Microsoft ecosystem, organisations that want boards integrated with their deployment pipeline, enterprise teams with compliance requirements.

Watch out for: The UI isn’t as polished or intuitive as Jira or Trello. The board experience is functional but can feel clunky compared to tools built board-first. Teams sometimes find themselves fighting the interface rather than using it naturally.

Other Notable Options

Linear has gained popularity with product-focused engineering teams. Clean interface, fast, and opinionated about workflow. Great if your team values speed and simplicity.

Monday.com and Asana offer board views that work for teams blending Scrum with other project management approaches. They’re less Scrum-native but more versatile for cross-functional work.

Shortcut (formerly Clubhouse) sits between Trello’s simplicity and Jira’s power. It’s a solid middle ground for small to mid-size engineering teams.

Hybrid Boards: When You Need Both

Some teams run a physical board for daily standups and a digital tool for tracking, metrics, and remote access. This hybrid approach gives you the immediacy of a physical board with the persistence and reporting of a digital tool.

The catch is double maintenance. Someone has to keep both boards in sync, and that job usually falls on the Scrum Master. If your team is disciplined enough to update both, it works well. If not, one of the boards will always be out of date and it’s usually the physical one.

A practical approach: use the physical board as the “source of truth” during the standup and update the digital board immediately after. Or use the digital tool as the source of truth and print a snapshot for the wall each morning. Pick one source and treat the other as a mirror.

What a Good Board Looks Like

A healthy Scrum board has a few tell-tale signs.

Work flows left to right at a steady pace. Cards don’t pile up in one column while another sits empty. There’s visible movement throughout the sprint.

The “In Progress” column isn’t overflowing. If your team has five people and twelve cards in progress, something is wrong. Good teams limit how much they take on at once, even if Scrum doesn’t formally require WIP limits the way Kanban does.

Blockers are visible. Whether you use a red dot, a flag, or a separate “Blocked” column, blocked items should scream for attention. A blocked card that nobody notices for three days is a board that isn’t doing its job.

The board matches reality. If you ask any team member “what are you working on right now?” their answer matches what the board shows. When those two things diverge, the board has become fiction.

What a Messy Board Looks Like

You’ve seen these. Maybe you’re looking at one right now.

Too many columns. Eight or nine columns for a five-person team turns the board into a process map that nobody follows. If work passes through “Backlog | Refinement Ready | Sprint Backlog | In Dev | Dev Done | In QA | QA Done | UAT | Done,” ask yourself whether every handoff is real or whether you’re adding columns to feel thorough.

Cards stuck for days. If the same cards sit in “In Progress” for a week, the board is telling you something. Either the work was too big to complete in a reasonable timeframe, something is blocking it that nobody’s addressing, or the person assigned has moved on to other work without updating the board.

No one looks at it. The deadliest sign. If the team doesn’t reference the board during standup, it’s already dead. A board that isn’t the centre of your daily conversation about work is furniture.

Common Scrum Board Mistakes

Too Many Columns From Day One

Start with three or four columns. Add more only when you identify a specific problem that an additional column would solve. “Code review takes too long and we can’t see the bottleneck” is a good reason to add a “In Review” column. “It would look more professional” is not.

No WIP Thinking

Scrum doesn’t formally prescribe WIP limits like Kanban does, but that doesn’t mean you should ignore the concept entirely. If every team member has three or four items in progress simultaneously, your board might look active but your team is context-switching constantly and finishing nothing quickly. Borrowing WIP discipline from Kanban is one of the best things a Scrum team can do.

Ignoring the Board Between Standups

The board should be a living document that gets updated in real time, not a snapshot that gets refreshed once a day during standup. When you finish a task, move the card. When you hit a blocker, flag it immediately. A board that only gets updated during ceremonies is always 23 hours out of date.

Making It a Status Report for Management

The board exists for the team, not for managers. When teams start adding fields, tags, and statuses because “leadership wants to see progress,” the board stops serving the people who actually do the work. Build the board for the team first. Generate reports from the data if leadership needs them, but don’t warp the board’s design to serve external stakeholders.

Never Changing the Board Setup

Your board should evolve as your team evolves. The setup that worked six months ago might not work now. Use retrospectives to ask whether the board structure still reflects how work actually moves through the team. If it doesn’t, change it.

Practical Setup Tips

Agree on a Definition of Done before setting up the board. If the team doesn’t agree on what “Done” means, the last column is meaningless. Define it, write it down, and post it next to the board.

Use avatars or initials on cards. Knowing who’s working on what at a glance prevents the “who’s doing that?” question during every standup.

Colour-code by work type. Bugs, features, technical debt, and spikes should be visually distinct. This gives you an instant read on the mix of work in the sprint.

Keep the board near the team. For physical boards, put it where the team sits, not in a conference room down the hall. For digital boards, pin it as a browser tab or put it on a dashboard screen. Proximity drives usage.

Review the board setup every few sprints. Ask the team during retro: “Is our board still useful? What would make it better?” Then actually change it based on the answers.

The Board Is the Team’s Mirror

A Scrum board reflects how your team actually works. If the board is messy, your process probably is too. If the board is clear and current, your team likely has a shared understanding of what’s happening and what needs attention. Don’t overthink the setup. Start simple, use it honestly, and let it evolve. The best board is the one that tells the truth about your sprint.

Frequently Asked Questions

What is the difference between a Scrum board and a Kanban board?

A Scrum board resets each sprint. At the start of a new sprint, the board clears and gets populated with the new Sprint Backlog. A Kanban board is continuous and never resets. Both use columns to track work flow, but Kanban boards typically have explicit WIP limits on each column while Scrum boards don’t formally require them.

How many columns should a Scrum board have?

Three to five columns work for most teams. Start with To Do, In Progress, and Done. Add columns like In Review or Testing only when you identify a specific bottleneck or invisible handoff that a new column would make visible. More than six columns is a warning sign that you’re over-engineering the board.

Should we use a physical or digital Scrum board?

If your team is fully co-located, a physical board offers unmatched visibility and simplicity. If any team members are remote, go digital. Hybrid approaches work but require discipline to keep both in sync. For most teams in 2026, a digital board is the practical choice given the prevalence of distributed work.

Is Jira too complex for a small team?

Jira can work for small teams if you resist the urge to over-configure it. Use a simple board with basic columns and minimal custom fields. The problem isn’t Jira itself but the tendency to add complexity because the tool allows it. If simplicity is your priority and you’re a small team, Trello or Linear might be a better starting point.

How do you handle blocked items on a Scrum board?

Make blockers highly visible. Most digital tools let you flag or tag items as blocked. On a physical board, use a red dot sticker or a small “BLOCKED” sticky note on top of the card. During standup, blocked items should be discussed first. The goal is to unblock work as quickly as possible, not to let blocked cards sit unnoticed.

Should the Scrum board include sub-tasks?

It depends on your team’s needs. Some teams break user stories into sub-tasks and track those on the board for finer-grained visibility. Others find that sub-tasks clutter the board and prefer to track only stories. A good middle ground is to show sub-tasks within a card (collapsed by default in digital tools) rather than giving them their own cards on the board.

What happens to the board at the end of a sprint?

All completed items stay in Done for the Sprint Review. Any items not completed move back to the Product Backlog for reprioritisation. The board then gets cleared and repopulated during the next Sprint Planning session. This clean reset is one of the things that distinguishes a Scrum board from a Kanban board.

Can multiple Scrum teams share one board?

It’s not recommended. Each Scrum team should have its own board reflecting its own Sprint Backlog. When teams share a board, accountability gets blurred and the board becomes too noisy to be useful. If you need cross-team visibility, use a programme-level board or a dashboard that aggregates data from individual team boards.