The Scrum Glossary is an often overlooked page on Scrum.org that goes a bit deeper into terminology commonly seen in relation to Scrum. These are not always a mandatory part of doing Scrum, but are often common terms seen used by teams using the framework. I feel that the glossary takes away a lot of misconceptions that the Scrum Guide does not always take away, due to it not being Scrum and therefore not mentioned or for the sake of brevity. I am not going to explain the use of practices or parts of Scrum as these have been described over and over. These articles have a different purpose, which is to instil deeper understanding about aspects of or related to Scrum for the practitioner.
Today we are going to talk about one of these terms in the Scrum Glossary: Scrum Board. The glossary has the following description:
Scrum Board: a physical board to visualize information for and by the Scrum Team, often used to manage Sprint Backlog. Scrum boards are an optional implementation within Scrum to make information visible.
The Scrum Board is a complementary practice that is commonly used by Scrum Teams to visualize their Sprint Backlog. Because it’s so commonly occurring the Scrum Glossary has a description on the Scrum Board available for us to dissect and interpret. Let’s see what it says when we break it down:
a physical board to visualize information
Notice how it says the board is physical. Something I commonly see being referred to as a Scrum Board is JIRA boards, Azure Devops boards and other digital alternatives. Scrum.org refers to the Scrum Board as a practice as a physical medium only. Scrum does not forbid you to use other tooling of course, but understand the consequences of potentially not having a simple information radiator and a way to track progress. Teams might me so inclined not to use the digital board at all, with the added risk that transparency on progress towards the Sprint Goal is decreased.
The board visualizes information. This part of the statement is vague at best, since anything can be information. Personally I would’ve scoped information in this statement to assure the team uses the board to remain in the ballpark of information that’s valuable to the team to ensure transparency on their Sprint Backlog or whatever they use the Scrum Board for to visualize. I would add this because we are looking at the definition from a Scrum perspective (hence why it’s called Scrum Board, and not just Board). Any other additions are still allowed of course, but would potentially take away from the purpose of using the practice.
for and by the Scrum Team, often used to manage Sprint Backlog.
Because the Scrum Board isn’t necessarily focused on the Sprint Backlog only according to this statement, the practice becomes rather vague regarding who would be responsible for the Scrum Board. If looking solely at the Sprint Backlog, the Development Team would be both using the board and maintaining the board as it’s part of their accountability to create “done” Increments. Any other purpose for the Scrum Board would have consequences to who’s actually responsible. If, for example, the Product Owner wants to increase the scope of the Scrum Board to also include the Product Backlog and Refinement activities for the Product Backlog items, the scope increases beyond the Development Team and the Scrum Board becomes a Scrum Team responsibility.
Scrum boards are an optional implementation within Scrum to make information visible.
I’ll repeat it again here, as I’ve done in the initial part of the statement: The Scrum Board is a complementary practice and therefore optional. Since there’s not much to be said than just this, here’s an interesting alternative to visualize the Sprint Backlog: I’ve seen some teams succesfully use the architecture map and/or UML for their product to identify work that needs to be done to achieve the Sprint Goal. Put sticky notes on a physical visualization of your landscape and let me know how that works for you as an experiment.
The Scrum Board is often mistaken as a mandatory part of Scrum. It’s important to understand why you’re using any complementary practice as a team and also be willing to let go of them when they are not beneficial. That said, there is value in increasing transparency on your current plan and any changes happening to it. In conclusion, the Scrum Board is only a means to an end that is artifact transparency. Ensure the transparency is there, and if not, see how you can help to increase transparency as a Scrum Master.
Let me know if this blogged helped you gain a better understanding about the Scrum Board in the comments below. Until next time!