Scrum Rules: The Product Backlog Is Easily Visible to Every Stakeholder

The Product Backlog is a constantly changing artifact, owned by the Product Owner. Stakeholders need real-time visibility into the current state of the Product. Stakeholders should be able to discuss the state of the Product Backlog with the Product Owner at any time, make recommendations and requests. Any change resulting from the request of any stakeholder(s) must be visible in real-time to all other stakeholders.

One of the greatest benefits of a highly visible Product Backlog is that it becomes a conversational space for key stakeholders and many others that are connected to or interested in the work of the Scrum team. Of course, a visible Product Backlog also upholds the Scrum value of transparency which is essential for long-term success with Scrum. What if my Product Backlog is not easily visible to every stakeholder? Stakeholders will become disengaged from the work of the Scrum Team, and will forget to give support and/or offer insights into the work. If the Product Backlog is managed in an electronic tool that requires people to login and/or go into a special space that has restricted access then they are much less likely to view it regularly.

The most effective method of making the Product Backlog visible to every stakeholder is by using an information radiator approach. One common way of doing this is to have each Product Backlog Item written (or printed) in a large text size on 4 inch x 6 inch blank note cards (one PBI per note card). These note cards are then placed on a wall such that the team and other stakeholders can easily see them. The cards are organized on the wall to reflect the order of the PBIs. One simple way to do this is to have column labels for upcoming Sprints as headers, and then the PBI cards that are planned for that Sprint to be laid out underneath the column labels. For example, if the team is currently on their 5th Sprint, then the Product Backlog “wall” starts with a label for the 6th Sprint (and the planned PBIs for that Sprint laid out below), then with a second column label for the 7th Sprint, and so on.

It is usually sufficient to display the Product Backlog up to the projected next release date or for the next few Sprints (whichever is longer). Of course, electronic tools can be used to mimic this layout and are certainly acceptable if any interested party has easy access to this view. To be clear: this access should be as granted as proactively and as openly as possible and be as easy as possible – it should not be given only upon request, and it should not be accessed through any complicated navigation or search process. For teams with most stakeholders in the same physical building, the cards on a wall approach is strongly preferred – and the few non-local stakeholders can be sent regular updates via emailed digital photos of the cards on the wall.

The Product Owner is the sole person responsible for…. ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next….

Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.

… Product Backlog items usually acquire this degree of transparency…

— The Scrum Guide

Certified ScrumMaster® – Guaranteed to Run! ✅

Certified Scrum Product Owner® – Guaranteed to Run! ✅

All virtual learning events run from 9am to 4:30pm Toronto/New York time and are 100% virtual.  Both CSM and CSPO courses have approximately 2 hours of required pre-work through our e-learning portal, and require you to have high speed internet for Zoom video conferencing and Miro virtual white-boarding.

Maybe attending a virtual training session isn’t for you, but you would like to acknowledge that this article helped you out somehow…