2.3 Scrum Values
Key Takeaways
- The five Scrum values are Commitment, Focus, Openness, Respect, and Courage — memorize this exact list.
- CRITICAL trap: Transparency is an empirical pillar, not a Scrum value; do not mix the three pillars with the five values.
- Successful use of Scrum depends on people becoming more proficient in living the five values; when embodied, the pillars of transparency, inspection, and adaptation come to life, building trust.
- Commitment in 2020 is to goals and supporting each other — not a promise that every forecasted backlog item will ship unchanged.
- Product Owners model the values when they order honestly, say no with respect, share bad news openly, focus on the Product Goal, and show courage under stakeholder pressure.
A team can schedule every Scrum event and still fail at product ownership if people hide bad news, chase every stakeholder request, or fear saying the product is not valuable enough. The 2020 Scrum Guide is explicit:
Successful use of Scrum depends on people becoming more proficient in living five values: Commitment, Focus, Openness, Respect, and Courage.
These five words are high-yield on PSPO I. So is the relationship between values and pillars — and the classic trap of calling Transparency a value.
The Critical Trap: Pillars vs. Values
| Empirical pillars (3) | Scrum values (5) |
|---|---|
| Transparency | Commitment |
| Inspection | Focus |
| Adaptation | Openness |
| Respect | |
| Courage |
Transparency is a pillar, not a Scrum value. Openness is a value; transparency is the pillar that describes visibility of process and work through artifacts. Exam writers deliberately mix these lists. If an option says the five values are “Commitment, Focus, Transparency, Respect, and Courage,” it is wrong — Transparency does not belong in the value list.
Likewise, Inspection and Adaptation are pillars, not values. Values and pillars are related but not interchangeable: the values enable the pillars.
How Values Enable the Pillars
The Guide states that the values give direction to the Scrum Team regarding work, actions, and behavior. Decisions, steps taken, and the way Scrum is used should reinforce the values, not diminish them. Team members learn the values as they work with events and artifacts.
Then comes the causal link you should quote on the exam:
When these values are embodied by the Scrum Team and the people they work with, the empirical Scrum pillars of transparency, inspection, and adaptation come to life, building trust.
Without trust:
- People will not make the true state of the Product Backlog or Increment visible → transparency fails
- People will not inspect diligently or admit variances → inspection is shallow
- People will not change course when evidence demands it → adaptation stalls
Values are not optional culture decoration and they do not replace the pillars. Mechanics without values become empty ceremony; values without the framework’s events and artifacts lack the formal opportunities to inspect and adapt.
The Five Values in Guide Language
Learn the Guide’s own descriptions; distractors swap one value’s meaning onto another.
| Value | 2020 Scrum Guide description | Product Owner example |
|---|---|---|
| Commitment | The Scrum Team commits to achieving its goals and to supporting each other | Commit to the Product Goal and to supporting Developers toward a coherent Sprint Goal; do not abandon the team when stakeholders scream for side work |
| Focus | Primary focus is on the work of the Sprint to make the best possible progress toward these goals | Keep ordering and Sprint proposals aligned to the Product Goal; resist turning the Sprint into a grab bag of unrelated requests |
| Openness | The Scrum Team and its stakeholders are open about the work and the challenges | Share true progress, risks, and “this hypothesis failed” outcomes at Sprint Review; do not green-status a failing product |
| Respect | Members respect each other as capable, independent people, and are respected as such by those they work with | Respect Developer ownership of how work is done and of sizing; respect stakeholder needs without surrendering Product Backlog accountability to a committee |
| Courage | Courage to do the right thing and to work on tough problems | Say no to low-value work, cancel a Sprint if the Sprint Goal is obsolete, release an honest Increment rather than a fake demo, and defend empirical ordering under political pressure |
Commitment — goals, not fixed scope contracts
In the 2020 Guide, commitment is about goals and supporting each other. A common outdated trap equates commitment with “the team promised every item selected in Sprint Planning.” Developers forecast what they believe they can do; the Sprint Goal is the commitment that provides focus and flexibility. Product Owners who weaponize the Sprint Backlog as a fixed contract undermine both commitment and empiricism.
Product Owner commitment looks like:
- Explicitly communicating and standing behind the Product Goal
- Coming to Sprint Planning prepared to discuss the most important items and how they map to that goal
- Supporting the team when trade-offs are needed mid-Sprint without quietly injecting unplanned work that endangers the Sprint Goal
Focus — one objective at a time
The Scrum Team focuses on one Product Goal at a time; within a Sprint, the Sprint Goal creates coherence. Product Owners destroy focus when they:
- Juggle multiple competing “number one” priorities for the same team
- Constantly interrupt the Sprint with new urgent items that endanger the Sprint Goal
- Expand the Product Goal into an unfocused wish list
Focus is lean as well as values-based: essential work only, for the current goal.
Openness — the partner of transparent artifacts
Openness is the human behavior that makes the transparency pillar real. A perfectly formatted backlog still fails if the Product Owner conceals that a major stakeholder need changed or that last Sprint’s release produced no usage. Openness includes stakeholders: the Guide says the Scrum Team and its stakeholders are open about the work and the challenges. Sprint Review is a working session for that honesty, not a sales pitch.
Respect — one Product Owner, capable team
Respect runs both ways. Stakeholders and the organization must respect Product Owner decisions visible in backlog content and order and in the inspectable Increment. Product Owners must respect Developers as professionals who decide how to turn items into Done Increments and who size the work. Turning the Product Owner role into a committee, or letting managers reassign ordering behind the Product Owner’s back, shows disrespect for the accountabilities that make Scrum work.
Courage — value decisions under pressure
Courage is often the deciding value in Product Owner scenarios:
- Stopping work that no longer serves the Product Goal
- Presenting an Increment that honestly meets Done rather than dressing up incomplete work
- Ordering a less popular item that is higher value than a politically favored one
- Escalating that empiricism is being blocked by organizational barriers
Without courage, openness collapses into silence and adaptation never happens.
Diagnosing Values on Exam Scenarios
Map behaviors to the value most at risk:
- Product Owner hides declining metrics from stakeholders → Openness (and often Courage)
- Backlog thrashes weekly with no Product Goal focus → Focus
- Product Owner blames Developers publicly for a failed forecast instead of supporting goal-based replanning → Respect and Commitment
- Team avoids cancelling an obsolete Sprint Goal because leadership “won’t like it” → Courage
- Product Owner agrees to every request so nobody is upset, drowning the Sprint Goal → Focus and Courage
Remember: more than one value can be involved; pick the most direct fit the question asks for.
Values Across the Whole Scrum Team
Values apply to the entire Scrum Team and the people they work with — not only the Scrum Master, and not only Developers. A distractor that says “values are enforced by management through KPIs” misreads the Guide. Values are lived; the Scrum Master coaches and helps establish Scrum, but Product Owners remain accountable for value and backlog decisions that either reinforce or undermine the values every day.
Artifact commitments (Product Goal, Sprint Goal, Definition of Done) exist to reinforce empiricism and the Scrum values. When you order the backlog toward a clear Product Goal, protect focus on the Sprint Goal, and insist on Done quality, you are not doing “extra process” — you are embodying the values that make transparency, inspection, and adaptation trustworthy.
Quick Memorization Checklist for PSPO I
- List the five values in any order: Commitment, Focus, Openness, Respect, Courage.
- Never put Transparency (or Inspection/Adaptation) in that list.
- Link: values → trust → pillars come to life.
- Commitment = goals + support each other, not fixed scope slavery.
- Product Owner daily practice: honest backlog, Product Goal focus, open stakeholder dialogue, respect for self-managing Developers, courage under pressure.
Master that checklist and value questions stop being “soft” — they become precise applications of the Scrum Guide.
Which of the following correctly lists the five Scrum values from the 2020 Scrum Guide?
A Product Owner avoids cancelling a Sprint even though the Sprint Goal is clearly obsolete, because leadership prefers “keeping the plan.” Which Scrum value is most directly missing, and who may cancel the Sprint?
How does the 2020 Scrum Guide describe the relationship between the Scrum values and the empirical pillars?