Transparency in Scrum: what has to be visible, and to whom

Every team claims to be transparent. Few can say what they mean by it, which is how a team ends up with a spotless board, a green status report and a product that does not work. Transparency in Scrum is a precise requirement with a precise purpose, and it is easier to test than most people expect.

What the Guide asks for

The Scrum Guide gives transparency one short paragraph. The emergent process and the work must be visible to those performing the work as well as those receiving it. Important decisions in Scrum are based on the perceived state of its three formal artifacts, so artifacts with low transparency can lead to decisions that diminish value and increase risk.

Two further sentences carry the weight. Transparency enables inspection. Inspection without transparency is misleading and wasteful. If you remember nothing else, remember that second one. A team can hold every event on the calendar and still learn nothing if what it inspects is not true.

There are two audiences in that definition. The people doing the work need to see the state of the work, and the people receiving it, the stakeholders, need to see it too. A board that only the Developers understand is transparent in one direction only.

What carries transparency in Scrum

The framework does not leave this to goodwill. It builds transparency into specific places.

• The Product Backlog. The Guide says the Product Owner is accountable for ensuring it is transparent, visible and understood. If stakeholders cannot see what is in it and in what order, they can only guess at what they will get.
• The Sprint Backlog. The Guide calls it a highly visible, real-time picture of the work the Developers plan to do. It is updated throughout the Sprint, with enough detail to inspect progress at the Daily Scrum.
• The Increment and the Definition of Done. The Definition of Done creates transparency by giving everyone a shared understanding of what was completed. An Increment is a statement that something meets that definition, so the definition has to be real. See Definition of Done.
• The commitments. The Product Goal, Sprint Goal and Definition of Done exist, the Guide says, to reinforce empiricism and the Scrum values. They tell everyone what progress is being measured against.
• The events. The Guide says the events are specifically designed to enable the transparency required. The Sprint Review is where stakeholders see the real Increment, not a report about it.

The SBOK® Guide lists a similar set under its own words: a project vision statement, an open prioritised backlog, the sprint backlog, a release planning schedule, a scrumboard and burndown chart as information radiators, and the meetings. The names differ, the intent is the same.

A worked example: the 90 percent board

This is an illustrative situation. A team has five items in the Sprint Backlog. On day eight of ten, the board shows four of them at "90 percent" and one at "done". Everyone nods. The manager reports the Sprint as on track.

On the last morning, a stakeholder asks to see one of the 90 percent items. It turns out the feature works on one developer's machine, has no tests, is not merged and has never been shown to a user. The last ten percent is three days of work. Of five items, one meets the Definition of Done.

What failed was not the board. The board faithfully showed what people told it. What failed was the meaning of the percentage, which nobody had agreed on, and the habit of reporting effort instead of state. A transparent version would have four items marked "in progress", with a visible list of what was left on each, and one marked Done against a written definition. That board would have looked worse on day eight and would have saved the Sprint.

Two repairs follow from this example. Agree what Done means and show it, and prefer binary states over percentages. A task is finished or it is not. The Agile Manifesto makes the same point: working software is the primary measure of progress.

Transparency is about decisions

It helps to ask of any artifact, what decision does this support, and could someone make that decision wrongly because of what it shows? A Sprint Backlog supports the Developers' daily adjustment of their plan. A Product Backlog supports the Product Owner's ordering and a stakeholder's expectation of what comes next. An Increment supports a stakeholder's judgement about whether to release, and what to ask for next.

If the answer to the second question is yes, the artifact is not transparent enough, however neat it looks. This test is more useful than a checklist because it puts the weight on the reader of the artifact, who is the person the Guide is protecting.

How teams fake it without noticing

• Vague states. "Almost done", "in review" for two weeks, or a column called "Done-ish" hides risk.
• Two backlogs. A tidy one for stakeholders and a real one in the team's heads. The Guide calls the Product Backlog the single source of work.
• Selective demos. Showing only the parts that work at the Sprint Review. The Guide says that an item that does not meet the Definition of Done cannot even be presented there.
• Penalising bad news. If the person who says "this will not make it" is blamed, people stop saying it. That is a failure of the value of openness, not of the tool.
• Metrics that are targets. When a number becomes the goal, people adjust the number. See how velocity gets misused.

The Scrum Master's part

The Scrum Master is accountable for the team's effectiveness and for helping the organisation understand an empirical approach. In practice they watch for the places where visibility quietly shrinks: a status that only one person updates, a chart nobody reads, a stakeholder who hears about problems in the corridor rather than in the Review. They also protect the people who bring bad news, because nothing else keeps the artifacts honest.

Common mistakes

• Equating transparency with sharing every document. The goal is accurate state, not volume.
• Making a dashboard and calling it done. If nobody acts on what it shows, it is not part of inspection.
• Hiding risk from the Product Owner to protect the team, or hiding it from the team to protect the Product Owner.
• Leaving the Definition of Done unwritten, so each person has a private one.
• Showing stakeholders a presentation of the Sprint instead of the Increment.

How to practise it

Transparency is easy to agree with and hard to do when a deadline is close. In the simulator the artifacts you produce are what later decisions rest on, so a vague artifact early on costs you later, in the same way it does in a real project.