A team wall practice, where a team shows its goals, work and progress on a shared board, is a choice and not a requirement of Scrum: the November 2020 Scrum Guide never mentions a wall [1]. What it does require is transparency around three formal artifacts, the Product Backlog, the Sprint Backlog and the Increment [1].
That difference matters for facilitators. Plenty of advice about walls circulates in practitioner writing. Some of it is useful. None of it is Scrum unless the Guide says so. Unless a post reports measured results, treat it as one practitioner's view.
What does Scrum require, and where does a wall fit?
The Guide says the emergent process and work must be visible to those doing the work and those receiving it [1]. It describes the Sprint Backlog as a "highly visible, real-time picture of the work" that the Developers plan to accomplish [1].
It does not say how to make that picture. The Guide calls the Scrum framework purposefully incomplete and says it is built upon by the collective intelligence of the people using it [1]. In its own words, "Various processes, techniques and methods can be employed within the framework." [1] A wall is one such technique. So is a digital board.
What can a team wall hold?
The Guide gives a natural list of things a wall could show. None of them has to be on a wall.
- The Product Goal. It is the long-term objective and sits in the Product Backlog [1].
- The Sprint Goal. It is the single objective for the Sprint and must be finalised before Sprint Planning ends [1].
- The selected items and the plan. Together with the Sprint Goal, these make up the Sprint Backlog [1].
- The Definition of Done. It gives everyone a shared understanding of what was completed [1].
- Impediments. The Daily Scrum is meant to identify them [1].
- Forecast charts. The Guide names burn-downs, burn-ups and cumulative flows as useful practices, but says they do not replace empiricism [1].
Columns, colours, swimlanes and limits on work in progress do not appear in the Guide. They are team choices.
Who keeps the wall current?
The Guide assigns ownership of the artifacts, so it also suggests who owns the parts of a wall that show them.
- Developers own the Sprint Backlog. It is a plan by and for them, and it is updated throughout the Sprint as more is learned [1].
- The Product Owner is accountable for Product Backlog management, including keeping it transparent and understood [1]. They may delegate the work but remain accountable [1].
- The Scrum Master helps the team improve its practices within the framework [1]. Keeping a wall tidy for the team is not one of the listed accountabilities.
A facilitator who updates the wall on the Developers' behalf may be taking over a plan that belongs to them.
How do you tell a team wall practice from a Scrum rule?
A simple test helps. Ask whether the Guide states it, and how firmly.
- Rules use firm wording. For example, the Daily Scrum is a 15-minute event for the Developers [1], and a Sprint is one month or less [1].
- Freedom is stated too. Developers can choose whatever structure and techniques they want for the Daily Scrum, as long as it focuses on the Sprint Goal and produces a plan for the next day [1].
- Silence means choice. If the Guide says nothing about a column, a colour or a card format, it is advice.
When someone claims that Scrum requires a Done column on the wall, check the Guide: it does not [1].
Who is affected?
- Facilitators and Scrum Masters, who explain what Scrum requires and coach teams on practice.
- Developers, who own the Sprint Backlog that a wall usually shows.
- Product Owners, who are accountable for the Product Backlog.
- Remote teams, who need the same visibility without a shared room.
- Teachers using visual boards, who may borrow the idea outside Scrum.
What is not yet clear?
The Guide does not say how often a wall should be updated, beyond saying the Sprint Backlog changes throughout the Sprint [1]. It does not say whether a physical or digital board works better. Our only source here is the Guide itself, and it reports no measured outcomes for walls or boards. Any claim that a particular wall layout improves delivery would need evidence that this source does not provide. The guide gives no comparison of wall layouts.
What should facilitators do now?
- Start with what the Guide names: the Sprint Goal, the selected items and the plan.
- Ask the Developers to design and update the Sprint part of the wall themselves.
- Agree with the Product Owner how backlog order is shown, if at all.
- Label team choices as team choices, so nobody mistakes them for Scrum rules.
- Review the wall in the Sprint Retrospective, where the team inspects its tools and processes [1].