The Scrum Guide – 2017:
Scrum relies on transparency. Decisions to optimize value and control risk are made based on the perceived state of the artifacts. To the extent that transparency is complete, these decisions have a sound basis. To the extent that the artifacts are incompletely transparent, these decisions can be flawed, value may diminish and risk may increase.
The Scrum Master must work with the Product Owner, Development Team, and other involved parties to understand if the artifacts are completely transparent. There are practices for coping with incomplete transparency; the Scrum Master must help everyone apply the most appropriate practices in the absence of complete transparency. A Scrum Master can detect incomplete transparency by inspecting the artifacts, sensing patterns, listening closely to what is being said, and detecting differences between expected and real results.
The Scrum Master’s job is to work with the Scrum Team and the organization to increase the transparency of the artifacts. This work usually involves learning, convincing, and change. Transparency doesn’t occur overnight, but is a path.
The Scrum Guide – 2020:
The new Scrum Guide rephrased all chapters and made this one redundant. Transparency as a requirement toward artifacts is emphasized throughout the text but no chapter details its importance anymore.
Commentary:
Artifact transparency has been part of the Guide since as early as 2011.
Note: the Guide has a sub-chapter detailing transparency. In Scrum, the entire delivery process is transparent, as well as the artifacts. (Even though “transparency doesn’t occur overnight, but is a path”.)
The transparency of the Product Backlog is the Product Owner‘s responsibility. However, the Scrum Master is responsible for supporting the Product Owner in this. In the end, artifact transparency is an important requirement of the Scrum framework, therefore the Scrum Master is responsible for achieving it.
Why is it important?
- For delivering good solutions. One of the major advantages of agile over the traditional delivery approach is stakeholder involvement. In the waterfall approach the users, stakeholders are involved in the requirement gathering phase and in the testing phase, but not in between. This bears the risk of spending a long time on implementing a problematic solution. However, stakeholders can only be involved in the process if it is transparent: the backlog items and their evolution are known, the increment is inspectable.
- For organizing the delivery process. Transparency is the key to establish a clear status of the Sprint, the product, the implementation process (so to speak the project, approaching the question from a less agile point of view). There is no project manager in Scrum, therefore participants have to rely on artifact transparency and on the related metrics.
What does artifact transparency mean in practice?
- Scrum Team members and stakeholders should have access to the Product Backlog;
- Development Team members and the Scrum Master should have access to the Sprint Backlog;
- The Product Owner and the stakeholders should have access to the Sprint Backlog at least at backlog item level (thus which product backlog items are in the Sprint and what is their current status);
- Scrum Team members and stakeholders should have access to the product (the delivered increments).
In this context, access, of course, does not mean a right to create, modify, delete data. Transparency might be impacted by organizational rules. E.g. an intelligence service and an FMCG company certainly consider different conditions ideal.
Since items can change anytime, transparency includes regular notification about changes.
In today’s environment, artifact transparency is more and more a data governance issue. Mature organizations, skilled professionals will not wait for the Scrum Master’s advice to generate the desirable detail of content when they work on the artifacts. On the other hand, provisioning access to the Product Backlog (or to all systems maintaining requirements, including the Product Backlog) and to the Sprint Backlog usually requires considerable effort from the organization. The Scrum Master must ensure the effort is made. This may be as simple as disseminating information, and as difficult as coaching the people involved.
Transparency also means stakeholders are able to determine the content of a product and the status of a delivery process. Stakeholders feel informed (and ideally trained or experienced) about the way Scrum works. They know how to interact with the team and are aware that they have to turn to the Product Owner with their wishes. They are aware that requirements must be in the Product Backlog otherwise the Development Team cannot work on them. IT managers must also accept that their requests, pet projects, KPI works must pass the planning sessions: everything is visible.
