Start with Transparency
Scrum is founded upon the three pillars of empiricism: transparency, inspection and adaptation. So when we start exploring the framework and our role within, it is only right to start with the first pillar.
Transparency means being open to be observed by the public — to provide visibility to see what matters. To be deemed transparent, what is observed:
- needs to have enough detail to be valuable to the observer,
- those details must be explicit,
- needs to be accurate at the time of inspection.
In Scrum, transparency is primarily provided by the three artifacts: the Product Backlog, the Sprint Backlog and the Increment. The reason for transparency is to enable the inspection and adaptation of the artifacts during Scrum events. It also fosters shared understanding for everyone who attends these events thus establishing common ground for all. The lack of transparency might lead to poor decision making, suboptimal products and/or increased risks.
Transparency doesn’t happen overnight, as the artifacts enabling it are emergent: the Product Backlog is a living artifact, constantly changing, evolving as more detail is added to some items whilst others are being deprioritised. The Sprint Backlog might also change as the team learns more about the work being done. Increments are constantly being born as more Product Backlog items reach the “Done” state.
In the 2017 version of the Guide, it was the Scrum Master ’s job to work with the Scrum Team and the organization to increase the transparency of the artifacts, but the 2020 Guide mentions none of it. Instead, it complements each artifact with a commitment.
Commitments Increase Transparency
In the latest Scrum Guide, artifacts were coupled with a commitment each:
+-----------------+--------------------+
| Artefact | Commitment |
+-----------------+--------------------+
| Product Backlog | Product Goal |
| Sprint Backlog | Sprint Goal |
| Increment | Definition of Done |
+-----------------+--------------------+The Product Goal is a long-term objective of the Scrum team [and] describes a future state of the product which can serve as a target for the Scrum Team to plan against.
The Sprint Goal communicates why the Sprint is valuable to stakeholders.
The Definition of Done is a formal description of the state of the Increment when it meets the quality required for the product.
By adding a commitment to each artifact, another layer of information was added to increase transparency. The commitments might work as a means to test whether:
- the product has achieved the future state described in the Product Goal or not,
- the value the Scrum Team set out to deliver during the Sprint has been delivered or not,
- the state of the Increment has met the quality prescribed by the Definition of Done or not.
Due to the additional transparency provided by the commitments, it will be a black or white decision to be made.
The commitments also strengthen empiricism and the Scrum Team will be better positioned to focus on progress towards the goals by discussing questions like below related to each commitment:
- Do we understand what our product is set to achieve? What is the problem that we are committed to solve through the delivery of our product?
- What value are we committed to achieve now as a next step towards the product goal?
- What quality does our Increment need to have to become a stepping stone towards the Product Goal?
Accountability over Transparency
In order to achieve transparency and clarity regarding the Product Backlog and its commitment, the Product Owner is accountable. Scrum Master serves the Product Owner by helping them to do this effectively.
Whilst the whole Scrum Team needs to collaborate to define a Sprint Goal, it is a commitment by Developers who are tasked with selecting Product Backlog items to meet the Sprint Goal.
Developers are also responsible to plan the work necessary to create an Increment that meets the Definition of Done — no Increment can be made transparent until it does.
Transparency and Scrum Values
Transparency is also connected to the five Scrum values:
- Openness to observe and be observed.
- Focus on the artifacts that matter.
- Courage to serve relevant and valid information.
- Respect the data and the people serving that data.
- Commitment to be present when transparency happens.
Conclusion
As Scrum Masters, we are accountable for establishing Scrum in our teams and our organisations. As Scrum is founded upon empiricism, the first leg of which is transparency, it is our accountability to nurture an environment where transparency can happen. Transparency is crucial, because it enables inspection and adaptation of the artifacts. Without transparent artifacts, Scrum events will not achieve the designed outcome and we will fail our primary accountability.
So Scrum Masters, start with transparency — not only because Scrum starts with transparency but also because it is the right thing to do. The Scrum framework is purposefully incomplete so whenever you come across an issue that is not mentioned in the Scrum Guide (conflicts in or around the team, issues related to psychological safety, problems about CI/CD or delivery expectations), it is a good stance to start with transparency — to make seen what is. You might do this by asking questions like: “What needs to be made transparent to resolve this issue?” or “How might I increase transparency where isn’t much?”. Creating transparency is often not easy or comfortable — the Values will drive you to get there.
