7.1 The Three Commitments & Empirical Artifact Transparency
Key Takeaways
The Scrum Guide 2020 commitment architecture binds each empirical artifact to a specific commitment: the Product Goal commits the Product Backlog, the Sprint Goal commits the Sprint Backlog, and the Definition of Done commits the Increment.
Commitments in Scrum foster focus, alignment, and radical transparency toward a shared outcome; they never represent deterministic scope contracts or fixed-delivery guarantees within complex, unpredictable environments.
Superficial visibility (such as digital Jira boards, automated burndown charts, and green status dashboards) does not equal transparency if the underlying technical reality, code quality, or actual progress is obscured or feared.
Artifact gaming—including story point inflation, splitting unfinished user stories to harvest artificial velocity, and maintaining shadow defect backlogs—corrupts empirical inspection and undermines organizational decision-making.
Incomplete Product Backlog items at Sprint conclusion receive zero story point credit and cannot silently roll over; they must transparently return to the Product Backlog for the Product Owner to re-evaluate, re-prioritize, and the Developers to re-estimate.
7.1 The Three Commitments & Empirical Artifact Transparency
Note
In the 2020 revision of the Scrum Guide, Ken Schwaber and Jeff Sutherland introduced a formal architectural relationship between artifacts and commitments: each of the three Scrum artifacts contains an explicit commitment designed to ensure it provides information that enhances transparency and focus against which progress can be measured.
The Scrum Guide 2020 Commitment Architecture
In complex product development, artifacts are not mere static repositories of documentation or administrative task trackers. They are empirical instruments of inspection and adaptation. Without an explicit target and standard of quality, artifacts easily degenerate into chaotic task lists or speculative wish lists that obscure progress. To reinforce transparency, the 2020 Scrum Guide paired every artifact with a dedicated commitment:
| Scrum artifact | Commitment |
|---|---|
| Product Backlog | Product Goal |
| Sprint Backlog | Sprint Goal |
| Increment | Definition of Done |
1. Product Backlog Commits to the Product Goal
The Product Backlog is an emergent, ordered list of what is needed to improve the product. Its commitment is the Product Goal, which describes a future state of the product that can serve as a target for the Scrum Team to plan against. The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one goal before taking on the next. By committing to a Product Goal, the Product Backlog gains strategic coherence, preventing the team from degenerating into a disconnected "feature factory" that processes isolated stakeholder requests.
2. Sprint Backlog Commits to the Sprint Goal
The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), and an actionable plan for delivering the Increment (how). Its commitment is the Sprint Goal. The Sprint Goal is the single objective for the Sprint. While the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. It creates cohesion and focus, encouraging the team to work together rather than on separate, fractured initiatives.
3. Increment Commits to the Definition of Done
The Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. Its commitment is the Definition of Done (DoD), which is a formal description of the state of the Increment when it meets the quality measures required for the product. The moment a Product Backlog item meets the Definition of Done, an Increment is born. Work cannot be considered part of an Increment unless it meets the Definition of Done, so the DoD tells everyone that what is declared complete is usable.
Commitment vs. Guarantee: The Danger of Fixed-Scope Thinking
A critical conceptual trap on the PSM II assessment is the conflation of a Commitment with a Deterministic Scope Guarantee or fixed-price contract. This misunderstanding stems from traditional predictive management, where "commitment" implies a binding promise to deliver a predetermined set of features on an exact date for a fixed cost.
| Predictive (defined) paradigm: "Commitment = binding scope contract" | Empirical (complex) paradigm: "Commitment = dedication to goal and quality" |
|---|---|
| Fixed features | Scope negotiated as the team learns |
| Inflexible task list | Relentless focus on the Sprint Goal |
| Quality sacrificed to meet dates | Definition of Done never compromised |
Empiricism in the Complex Domain
In Dave Snowden's Cynefin framework, software development resides firmly in the Complex domain. Cause-and-effect relationships are only perceptible in retrospect, and unknown unknowns dominate. In such an environment, it is intellectually impossible to guarantee upfront how long complex engineering tasks will take or what unforeseen technical impediments will arise.
When organizational leadership interprets the Developers' Sprint forecast as a fixed contract, destructive side effects inevitably follow:
- Quality Compromises: Under pressure to meet a fixed scope contract, developers take technical shortcuts, skip automated unit tests, and defer integration testing, accumulating invisible technical debt.
- Loss of Transparency: Developers begin concealing technical blockers, underreporting bugs, and presenting half-finished features to avoid executive reprimands.
- Destruction of Self-Management: Teams stop collaborating creatively to solve user problems and instead become defensive ticket-movers focused on personal survival.
True Meaning of Commitment in Professional Scrum
In Scrum, the value of Commitment means that team members dedicate themselves personally to achieving their collective goals, collaborating transparently, and upholding professional standards of quality. The Developers commit to achieving the Sprint Goal, not to blindly completing every task on the initial Sprint Backlog. If the work turns out to be more complex than anticipated, the Developers and Product Owner negotiate the tactical scope of the Sprint Backlog without compromising the Sprint Goal or lowering the Definition of Done.
Transparency vs. Superficial Visibility: The Jira Illusion
Many organizations confuse superficial visibility with genuine empirical transparency:
Visibility is the mere visual display of data, artifacts, and activity (e.g., tickets arranged on a digital Jira board, automated burn-up charts, or velocity reports).
Transparency requires that artifacts and aspects of the process be perceived and understood uniformly by all participants. The 2020 Scrum Guide puts it this way: the emergent process and work must be visible to those performing the work as well as those receiving the work—and what is seen must reflect the real technical and business state.
The Jira Illusion Anti-Pattern
Consider a common enterprise scenario: an engineering dashboard displays twenty user story cards in the "Done" column. The Sprint burndown chart shows a perfect downward diagonal, and velocity appears consistent. Management observes 100% visibility. However, behind this facade:
- The code has not been integrated into the mainline repository.
- End-to-end automated tests were skipped because the test environment was down.
- Performance, load, and security testing have been postponed to an unacknowledged "hardening phase."
- The application crashes when deployed to a production-equivalent server.
In this scenario, there is complete visibility but zero transparency. The visual artifacts communicate success while the underlying software is broken. True transparency requires a shared, unambiguous standard of reality—which is precisely why the Definition of Done serves as the non-negotiable commitment for the Increment.
Psychological Safety as the Bedrock of Transparency
Transparency cannot exist in an environment ruled by fear. If developers are penalized whenever they report that a Sprint Goal is in jeopardy or that an estimate was incorrect, human nature dictates that they will distort reality to protect themselves. Radical transparency demands high psychological safety: leaders must treat the discovery of impediments, failed experiments, and technical obstacles as valuable empirical data rather than personal performance failures.
Detecting and Addressing Artifact Gaming
When organizations govern through vanity metrics, quotas, or punitive management, Scrum artifacts are frequently gamed. Advanced Scrum Masters must identify these subtle anti-patterns and guide teams back to empirical integrity:
1. Story Point Inflation
When management treats velocity as an executive KPI or compares velocity across teams (violating Goodhart's Law), developers respond rationally: they inflate story point estimates. A task that was previously estimated as 3 points is re-estimated as 8 or 13 points. Velocity rises dramatically on executive slides, yet the actual amount of customer value delivered remains unchanged.
2. Splitting Unfinished Stories to Harvest Velocity
At the end of a Sprint, an 8-point Product Backlog item has code written and unit tests passing, but integration testing remains incomplete. To avoid a "dip" in velocity, the team splits the item into two: a 5-point "Development Done" story (marked Done in the current Sprint) and a 3-point "Testing" story (pushed to the next Sprint).
- The Destruction: In Scrum, work is strictly binary: an item either meets the Definition of Done in its entirety, or it is undone. Awarding partial credit or partial points creates a deceptive illusion of progress and distorts future capacity forecasts. The entire item is incomplete and must return to the Product Backlog.
3. The Shadow Defect Backlog
Teams create a secondary, private spreadsheet or separate Jira project to track bugs discovered during the Sprint. By keeping defects off the official Product Backlog, the Product Backlog appears clean and well-ordered, and velocity metrics remain untarnished. In reality, this conceals technical debt and deprives the Product Owner of the transparency needed to make informed ordering decisions.
4. Silent Rollover of Undone Work
When Product Backlog items are incomplete at Sprint end, developers automatically drag them into the next Sprint's backlog without consulting the Product Owner. This strips the Product Owner of the accountability to re-order the Product Backlog. Market conditions, stakeholder feedback, or strategic priorities may have shifted, making other backlog items significantly more valuable than finishing the rolled-over work.
Comprehensive Reference: Artifacts, Commitments & Transparency Breakdown
The table below contrasts the empirical function of each artifact and commitment against common gaming anti-patterns:
| Artifact | Formal Commitment | Empirical Transparency Mechanism | Common Gaming Anti-Pattern | Scrum Master Remediation |
|---|---|---|---|---|
| Product Backlog | Product Goal | Provides clear, long-term direction against which progress is measured | Unordered dumping ground of hundreds of speculative features with no coherent Product Goal | Coach the PO to craft focused Product Goals and prune irrelevant items to restore strategic alignment. |
| Sprint Backlog | Sprint Goal | Focuses Developers on a singular business outcome while allowing tactical scope flexibility | Fixed-scope contract; stuffing unrelated tasks into the Sprint; abandoning the Sprint Goal when obstacles arise | Coach the team that Developers commit to the Sprint Goal, negotiating tactical task scope with the PO as learning emerges. |
| Increment | Definition of Done | Guarantees universal quality, reliability, and immediate deployability | Splitting incomplete stories to claim partial velocity; deferring testing to hardening Sprints | Enforce binary completeness: items are either Done or undone; eliminate partial points; return unfinished work to Product Backlog. |
During Sprint Planning, the Developers forecast completing six Product Backlog items to achieve the Sprint Goal. Mid-way through the Sprint, the Developers realize that the third item is significantly more complex than anticipated due to unforeseen legacy API limitations. If they build all six items, they will have to skip integration testing. The Developers meet with the Product Owner and propose removing the bottom two non-critical items from the Sprint Backlog so they can complete the remaining work according to the Definition of Done and satisfy the Sprint Goal. An external Project Manager accuses the Developers of 'breaking their commitment.' How should the Scrum Master coach the Project Manager?
Agree with the Project Manager, as the Developers made a binding commitment to deliver all six items during Sprint Planning and must honor it to maintain stakeholder trust.
Coach the PM that Developers commit to the Sprint Goal, not fixed scope; renegotiating with the PO while keeping the DoD is professional Scrum.
Advise the Developers to lower their Definition of Done temporarily so they can deliver all six items without renegotiating scope.
Direct the Product Owner to immediately cancel the Sprint because any change to the initial forecast invalidates the entire iteration and requires a fresh Sprint Planning.
On the final day of a Sprint, a Scrum Team has an 8-story-point feature where the coding is complete, but performance load testing—a mandatory requirement in the team's Definition of Done—could not be executed due to environment downtime. The team lead proposes splitting the user story into two: creating a 5-point story for 'Development Completed' to count toward this Sprint's velocity, and a 3-point story for 'Performance Testing' to be completed in the next Sprint. What systemic risk does this practice introduce, and how should the Scrum Master respond?
Support the team lead's proposal, because awarding partial velocity accurately reflects developer effort and maintains team morale during a Sprint disrupted by environment downtime.
Instruct the team to mark the entire 8-point story as Done and present it at the Sprint Review, but secretly log a technical debt ticket.
Explain that an item is either Done or not Done; splitting unfinished work to harvest points games velocity and corrupts forecasting, so the whole item returns to the Product Backlog for re-estimation.
Recommend that the Product Owner increase the total story points of the feature to 13 points to compensate for the delayed performance testing and keep the forecast honest.
An enterprise engineering director inspects an automated Jira burndown chart showing that a Scrum Team completed 100% of their planned user stories in the last three Sprints. However, during user acceptance testing by key business stakeholders prior to production deployment, dozens of critical regressions and architectural performance flaws are uncovered, delaying release by two months. The director asks the Scrum Master how the burndown chart could look so successful while the product was failing. How should the Scrum Master explain this discrepancy?
Explain that boards and burndowns are visibility, not transparency; without a rigorous Definition of Done, apparent progress is an illusion.
Explain that the business stakeholders conducted acceptance testing incorrectly, because any work marked as Done in Jira is automatically defect-free and ready for production.
Suggest replacing the Jira burndown chart with a physical whiteboard with paper sticky notes, which inherently prevents software defects.
Advise the director to punish the Developers by withholding their quarterly bonuses until all discovered bugs are resolved, so that the team takes the Definition of Done seriously in future.
Sections you finish are checked off in the contents.