SkarpChapter 19 of 21
Transparency and Quality: Making Work and Progress Visible
See how artifacts, commitments, and the Definition of Done create transparency, and explore how weak transparency leads to poor decisions, rework, and exam trick questions.
Why Transparency Is the Oxygen of Scrum
Empiricism Needs Transparency
Scrum is founded on empiricism and lean thinking. Empiricism needs facts you can see. Without transparency, inspection is blind and adaptation becomes guesswork.
Focus of This Module
We focus on transparency and quality: how artifacts and the Definition of Done make work visible, and how weak transparency causes bad decisions and rework.
Artifacts and Commitments
Current Scrum (as of 2026) has three artifacts and three commitments: Product Backlog/Product Goal, Sprint Backlog/Sprint Goal, and Increment/Definition of Done.
Exam Mindset
In PSM I scenarios, when you see confusion about status or quality, ask: what is not transparent here, and which artifact, commitment, or event should fix it?
The Three Artifacts: What Must Be Visible
Product Backlog Transparency
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It must be visible so everyone can inspect direction and content.
Sprint Backlog Transparency
The Sprint Backlog holds the Sprint Goal (why), selected items (what), and plan (how). It must be updated and visible, not static or hidden in someone’s head.
Increment Transparency
An Increment is a concrete stepping stone toward the Product Goal. Everyone should know what works now, at what quality level, and whether it is usable.
Exam Signal
If an artifact is missing, outdated, or private, transparency is broken. Many PSM I questions hide the root cause in a non-transparent artifact.
Commitments: Product Goal, Sprint Goal, Definition of Done
Why Commitments?
Commitments clarify what “good enough and clear enough” means for each artifact, making direction, purpose, and quality explicit and visible.
Product Goal
The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. It makes long-term direction transparent.
Sprint Goal
The Sprint Goal is the single objective for the Sprint. It makes the Sprint’s purpose transparent and guides how Developers adjust their plan.
Definition of Done
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. It makes quality visible.
Definition of Done and Quality: No Hidden Work
One Definition of Done
There is one Definition of Done for the product. It applies to every Increment and every selected Product Backlog item, every Sprint.
What the DoD Is
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
What the DoD Prevents
A clear DoD prevents hidden work, rework, and technical debt by making tests, documentation, and other quality measures non-negotiable.
Exam Signal
Phrases like “almost done” or “PO accepted without tests” are red flags: the Definition of Done is weak or ignored. The fix is to strengthen and apply it.
Example: Weak vs Strong Definition of Done
Team A: Weak DoD
Team A’s DoD is informal: “works on my machine, PO liked the demo”. They skip performance and security checks and postpone tests and docs.
Team A: Consequences
Production bugs, emergency fixes, and growing technical debt follow. Stakeholders think work is done when it is actually fragile and incomplete.
Team B: Strong DoD
Team B’s DoD covers acceptance criteria, automated tests, performance, security, code review, and docs. Only then is an item called done.
Team B: Consequences
Each Increment is truly usable and potentially releasable. There is less surprise rework, and technical debt becomes a conscious, visible choice.
Technical Debt and Incomplete Work: Making the Invisible Visible
What Is Technical Debt?
Technical debt is work you postpone (like tests or refactoring) to go faster now, creating more work later. In Scrum, it must be transparent.
Sources of Debt
Skipping tests, hard-coding values, duplicating code, or ignoring known performance and security issues are common sources of technical debt.
Undone Work and the Increment
If work does not meet the Definition of Done, it is not part of the Increment. It stays visible as undone work or explicit technical debt items.
Exam Signal
If a team says “we will fix it later but mark it done”, that hides debt. The Scrum answer is to keep undone work visible and protect the Increment.
Transparency Enables Inspection and Adaptation
The Core Loop
Scrum relies on transparency → inspection → adaptation. If transparency is weak, inspection is blind and adaptation is random.
Daily Scrum Needs Transparency
Daily Scrum depends on a clear Sprint Goal and visible Sprint Backlog. Without them, Developers cannot inspect progress or adapt their plan well.
Review and Retrospective
Sprint Review needs a visible Increment and Product Backlog. Retrospective needs visible quality issues and debt. Hidden problems cannot be improved.
Scrum Master’s Role
A Scrum Master often serves by improving transparency so that the Scrum Team and stakeholders can inspect and adapt without relying on status reports.
Thought Exercise: Spot the Transparency Gaps
Work through this mental exercise to train your “transparency radar” for the exam.
Scenario 1
A team finishes a Sprint. In the Sprint Review, they show a slide deck with screenshots and say: “The feature is almost done; we just need to finish tests and documentation next Sprint.” Stakeholders are happy and assume they can start using the feature next week.
Questions to reflect on:
- What is not transparent here?
- Which artifact or commitment is involved?
- What Scrum-consistent action could the Scrum Master encourage?
Sample reasoning
- The state of the Increment is not transparent. Stakeholders believe it is usable, but it does not meet the Definition of Done.
- The commitment involved is the Definition of Done (Increment) and, indirectly, the Sprint Goal if the goal implied a fully usable feature.
- The Scrum Master could coach the team to:
- Present only work that meets the Definition of Done as “done” in the Sprint Review.
- Make the Definition of Done visible to stakeholders.
- Keep unfinished work visible in the Product Backlog.
Scenario 2
Developers complain in the Sprint Retrospective: “We always feel rushed. Halfway through the Sprint, the Product Owner keeps adding new tasks to the Sprint Backlog, but we still get blamed when we miss the plan.”
Reflect:
- What transparency issue do you see?
- Which artifact/commitment could help?
- How might a self-managing team respond?
Pause and answer before moving on. This kind of reasoning is exactly what PSM I questions test.
Quiz 1: Artifacts, Commitments, and Transparency
Test your understanding of how artifacts and commitments support transparency.
A Scrum Team frequently delivers features that the Product Owner believes are ‘done’, but later discovers missing performance tests and security checks. Which SINGLE Scrum element is most directly failing to provide transparency here?
- The Product Goal
- The Sprint Goal
- The Definition of Done
- The Daily Scrum
Show Answer
Answer: C) The Definition of Done
The issue is that 'done' does not mean the same thing to everyone, and quality steps (performance, security) are missing. This is a failure of the Definition of Done, which should be a formal, shared description of the state of the Increment when it meets required quality measures. Product Goal and Sprint Goal describe direction and purpose, not quality. The Daily Scrum is an event, not the primary mechanism for defining quality.
Quiz 2: Handling Undone Work and Technical Debt
Check how well you can apply Scrum rules to incomplete work and technical debt.
Near the end of a Sprint, a Product Backlog item is functionally complete but lacks automated tests required by the Definition of Done. What is the most Scrum-consistent action?
- Mark the item as done because it works and add the missing tests as a new item next Sprint.
- Do not include the item in the Increment and keep the work transparent as undone or split the item and return the undone part to the Product Backlog.
- Ask the Product Owner to accept the item as an exception so the Sprint Goal can be met.
- Extend the Sprint by a few days so the team can finish the tests and mark the item as done.
Show Answer
Answer: B) Do not include the item in the Increment and keep the work transparent as undone or split the item and return the undone part to the Product Backlog.
If an item does not meet the Definition of Done, it is not part of the Increment. The work should remain transparent as undone. The team may split the item, keeping only the Done part. Marking it done anyway or asking for exceptions breaks transparency. Extending the Sprint violates Scrum; Sprints have a fixed duration.
Key Term Flashcards: Transparency and Quality
Flip through these cards to reinforce core definitions and relationships. Try to recall the answer before revealing the back.
- Scrum
- Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
- Scrum Team
- The Scrum Team is a cohesive unit of professionals focused on one objective at a time, the Product Goal.
- Product Backlog
- The Product Backlog is an emergent, ordered list of what is needed to improve the product.
- Product Goal
- The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against.
- Sprint Backlog
- The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).
- Sprint Goal
- The Sprint Goal is the single objective for the Sprint.
- Increment
- An Increment is a concrete stepping stone toward the Product Goal.
- Definition of Done
- The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
- Empiricism (in Scrum)
- Scrum is founded on empiricism and lean thinking.
- Technical Debt (Scrum context)
- A metaphor for the extra work and risk created when teams take shortcuts (for example, skipping tests or refactoring). In Scrum it is allowed but must be transparent and managed.
Exam Patterns: Classic Transparency and Quality Traps
Typical Exam Traps
Look for patterns: status-reporting Scrum Master, hidden Product Backlog, no single Definition of Done, and PowerPoint-only Sprint Reviews.
Remedy Pattern
For each trap, the fix is to strengthen transparency of the right artifact or commitment, not add roles, approvals, or side processes.
Answering Strategy
Ask what information is unclear, map it to an artifact or commitment, and choose options that make work and quality visible to the Scrum Team.
Next Steps in Your Path
Your next mock exam will stress these ideas. Missed items on transparency or quality will return in spaced review and in your gap guide.
Key Terms
- Scrum
- Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
- Sprint
- Sprints are the heartbeat of Scrum, where ideas are turned into value.
- Increment
- An Increment is a concrete stepping stone toward the Product Goal.
- Developers
- Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.
- Empiricism
- Scrum is founded on empiricism and lean thinking.
- Scrum Team
- The Scrum Team is a cohesive unit of professionals focused on one objective at a time, the Product Goal.
- Sprint Goal
- The Sprint Goal is the single objective for the Sprint.
- Product Goal
- The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against.
- Scrum Master
- The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide.
- Product Owner
- The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.
- Sprint Backlog
- The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).
- Technical debt
- A metaphor for the extra work and risk created when teams take shortcuts (for example, skipping tests, refactoring, or design). In Scrum it must be made transparent and managed via the Product Backlog.
- Product Backlog
- The Product Backlog is an emergent, ordered list of what is needed to improve the product.
- Definition of Done
- The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.