The Scrum Guide’s section on Scrum Values is one of its shortest. Five words, a paragraph of explanation, two sentences connecting the values to the empirical pillars. Most candidates read it once, memorize the five words, and move on. Then they hit exam scenarios where the correct answer depends entirely on understanding what those values actually demand — and they guess.
This article breaks down each value with the precision the exam requires, explains the most common misconceptions, and shows you how to use the values as a lens when scenario questions give you no obvious right answer.
What the Scrum Guide Actually Says
The 2020 Scrum Guide states: “Successful use of Scrum depends on people becoming more proficient in living five values: Commitment, Focus, Openness, Respect, and Courage.”
Two words in that sentence deserve close attention. Proficient — not “aware of” or “compliant with” — suggests the values are something you develop over time, not a checkbox to tick. And living signals that these are not policies to follow but behaviors to embody. You cannot write a process that makes a team courageous. You can only create conditions where courage grows.
The Scrum Guide then makes a connection that candidates frequently overlook:
“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.”
This is the exam insight worth internalizing: the values are not a separate topic from empiricism — they are the prerequisite for it. Transparency requires openness and courage. Honest inspection requires respect and courage. Meaningful adaptation requires commitment and focus. If a scenario question shows a team struggling with Scrum’s empirical pillars — hiding problems, skipping hard retrospective conversations, delivering the same issues Sprint after Sprint — the root cause is almost always a values gap.
Each Value in Depth
Commitment
The Scrum Guide: “The Scrum Team commits to achieving its goals and to supporting each other.”
The word goals is doing important work here. The Scrum Guide is explicit that the Sprint Goal is the single objective for the Sprint, and that it “provides flexibility in terms of the exact work needed to achieve it.” If the work turns out differently from what was expected, Developers can negotiate Sprint Backlog scope with the Product Owner — without compromising the Sprint Goal.
This matters enormously for the exam. Many candidates, drawing on older training or intuition from traditional project management, interpret commitment as “we promised to deliver every item on the Sprint Backlog.” When a scenario presents a team pushing back on unplanned work mid-Sprint, they choose the answer that protects the task list rather than the goal. The Scrum Guide’s position is the reverse: protect the Sprint Goal, negotiate the scope.
Also worth noting: commitment is explicitly to goals and to supporting each other. It is both about the work and about the team. A scenario where a Developer withholds a blocker to avoid “slowing the team down” is violating this value — withholding information denies teammates the support they need to succeed.
Focus
The Scrum Guide: “Their primary focus is on the work of the Sprint to make the best possible progress toward these goals.”
Focus has structural support throughout Scrum. The Sprint is a fixed-length event precisely because boundaries create conditions for sustained attention. The Daily Scrum exists to inspect progress toward the Sprint Goal — not to report status upward or address unrelated topics. The Sprint Goal itself, as the Scrum Guide notes, “creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.”
Exam scenarios that introduce competing priorities mid-Sprint — a manager pulling a Developer to another project, a stakeholder requesting a new feature, an urgent issue from a different product — are testing your understanding that focus is protected by Scrum’s structure and by the Scrum Master’s accountability. The correct answer almost always involves the Scrum Master helping address the impediment, not silently absorbing the distraction.
Openness
The Scrum Guide: “The Scrum Team and its stakeholders are open about the work and the challenges.”
Pay attention to who openness applies to: not just the Scrum Team internally, but the Scrum Team and its stakeholders together. This is why the Sprint Review is described as “a working session” — it is the formal event where both the team and stakeholders are expected to collaborate openly on what to do next. The Scrum Guide explicitly says the team should “avoid limiting it to a presentation.”
Openness also means being transparent about challenges, not just progress. A team that reports only good news to stakeholders, buries technical debt, or avoids surfacing impediments is violating openness — even if everything they do say is technically accurate. What they are leaving out matters.
When a scenario presents a choice between a comfortable answer that stakeholders will welcome and an honest answer about the team’s actual state, the correct answer involves openness. The Scrum Guide’s entire empirical model depends on decisions being based on accurate information.
Respect
The Scrum Guide: “Scrum Team members respect each other to be capable, independent people, and are respected as such by the people with whom they work.”
The phrase “capable, independent people” is precise. Respect in Scrum is not simply being courteous — it means trusting team members to determine how to do their own work. The Scrum Guide states that Scrum Teams are self-managing: “they internally decide who does what, when, and how.” A manager who assigns tasks directly to Developers, bypassing the team’s autonomy, violates both the self-management principle and the value of respect.
The Scrum Guide reinforces this in Sprint Planning: how Developers turn Product Backlog items into Increments is “at the sole discretion of the Developers. No one else tells them how.” That language is unusually direct. Exam questions that show an external authority directing the technical approach are testing whether you recognize that as a structural violation rooted in disrespect for the team’s expertise and autonomy.
Courage
The Scrum Guide: “The Scrum Team members have the courage to do the right thing, to work on tough problems.”
Courage is the value that gets the least attention in study materials and causes the most difficulty on scenario questions. It surfaces when a Scrum Master needs to name an organizational impediment that leadership would prefer to ignore. When Developers must honestly say mid-Sprint that they will not meet the Sprint Goal. When a Product Owner needs to push back on a stakeholder’s request because it does not align with the Product Goal. When the Retrospective discussion needs to go somewhere uncomfortable.
“Doing the right thing” frequently means doing the uncomfortable thing. The Scrum Guide’s empirical model functions only if people speak up — which requires courage. Scenarios that present a situation where a team member sees a significant problem but avoids raising it to preserve harmony are testing courage. Candidates who pick the conflict-avoidance answer lose the point.
How the Values Connect to Transparency, Inspection, and Adaptation
The Scrum Guide’s sentence connecting values to the three pillars deserves to be a core study anchor. Here is how that connection works in practice:
- Transparency depends on openness (people share the real state of things) and courage (they share things that may be unwelcome).
- Inspection depends on respect (you trust others’ honest feedback) and courage (you can examine your own work without defensiveness).
- Adaptation depends on commitment (to follow through on improvements identified) and focus (to change what matters without disrupting what is working).
If you encounter a question about Scrum’s empirical pillars failing — transparency being undermined, inspection being superficial, adaptation not happening despite retrospectives — ask yourself which values are absent. The root cause is almost always there.
Recognizing Values Questions in Exam Scenarios
Most PSM I and PSPO I scenario questions do not ask directly “which Scrum value is being violated?” They present a situation and ask what the Scrum Master, Product Owner, or Scrum Team should do. The values reasoning is embedded in why certain answers are correct.
Common scenario patterns and the values logic behind them:
- A team consistently hides impediments from stakeholders → Openness is missing; the Scrum Master should create safety for surfacing problems, not protect the team’s image.
- A manager assigns daily tasks directly to Developers → Respect is being violated; the Scrum Master coaches on self-management.
- A team member avoids raising a major technical risk in the Sprint Review because a senior stakeholder is in the room → Courage and openness are both at stake; raising the risk is the correct answer.
- The team commits to a Sprint Goal but adds unrelated items throughout the Sprint to “help out” another team → Focus is being compromised; good intentions do not override the Sprint Goal commitment.
- The Retrospective produces a long improvement list that is never acted on → Commitment and courage are absent; the Scrum Guide says “the most impactful improvements are addressed as soon as possible.”
A Five-Scenario Self-Check
Work through these before your exam. Identify which value is at stake and what the Scrum Guide would support as the correct response.
Scenario 1: Two days into a Sprint, the Product Owner asks the Developers to swap out a selected item for a higher-priority request. The Developers are concerned this will jeopardize the Sprint Goal but say nothing and accept the change.
Value at stake: Courage. The Developers should raise the concern openly, discuss it with the Product Owner, and collaboratively assess whether the Sprint Goal is still achievable.
Scenario 2: The Scrum Master notices two Developers in a persistent disagreement. Rather than facilitating a conversation, she reassigns work to keep them separate and avoids the conflict.
Value at stake: Courage. Separation avoids the problem; it does not resolve it. The Scrum Master’s accountability includes coaching on self-management, which requires engaging with the difficulty directly.
Scenario 3: The team’s throughput has dropped for three Sprints because of accumulating technical debt no one has disclosed. The Scrum Master and Product Owner agree to keep this from stakeholders at the Sprint Review to “avoid unnecessary alarm.”
Values at stake: Openness and Courage. Stakeholders need accurate information to make sound decisions. The Sprint Review exists precisely to discuss what has changed and what to do about it — including bad news.
Scenario 4: A senior developer tells the other Developers each morning which specific tasks they should work on, based on matching skills to work items.
Value at stake: Respect. Even a well-intentioned, experienced developer who assigns work to teammates is undermining self-management. The team — as a whole — decides who does what.
Scenario 5: Midway through the Sprint, the team completes the core work of the Sprint Goal ahead of schedule. Rather than starting on unrelated items, they pull in the next highest-priority Product Backlog items after discussing them with the Product Owner.
Values in action: Commitment and Focus. This is correct Scrum behavior — the team stays focused on delivering value and collaborates with the Product Owner rather than going off on their own.
How to Study This Material
The Scrum Guide is the authoritative source for every values question on the PSM I and PSPO I exams. Read the Scrum Values section multiple times — not to memorize the five words, but to understand the specific behaviors each value describes. Notice the language carefully: “capable, independent people,” “achieving its goals and to supporting each other,” “open about the work and the challenges.”
When you practice scenario questions, train yourself to ask: which value does the correct answer reinforce, and which value does the wrong answer undermine? That framing turns difficult scenarios into answerable ones.
Scrum.org’s free Scrum Open assessment is worth running through multiple times. It will surface areas where your reasoning needs work before you sit the actual exam.
When you are ready to practice at exam depth and volume, the PSM I Exam Simulator includes scenario questions specifically targeting the interplay between values, accountabilities, and events — the areas where prepared candidates separate themselves from candidates who only studied definitions. For PSPO I preparation, the PSPO I Exam Simulator covers the same values landscape from the Product Owner’s perspective, with particular focus on how commitment and openness show up in backlog management and stakeholder collaboration.
Not sure where your knowledge gaps are? The free 20-question PSM I practice test is a good place to baseline your understanding before diving deeper.