PSM I sample questions — 25 answered and explained

Inspection: Scrum artifacts and progress toward agreed goals are inspected frequently and diligently to detect undesirable variances or problems.

The Guide names two things: the artifacts (Product Backlog, Sprint Backlog, Increment) and progress toward agreed goals. The distractors are common management metrics — utilisation, plan conformance, hours — that Scrum does not require.

1. Recall the definition of inspection.
2. Pick the two subjects it names.
3. Reject individual or plan-based metrics.

Exam tip: Inspect the artifacts and progress toward goals, not people's hours.

Inspection enables adaptation. Inspection without adaptation is considered pointless; Scrum events are designed to provoke change.

The Guide pairs each pillar with the next. Inspection without transparency is 'misleading and wasteful'; inspection without adaptation is 'pointless'. The near-twin wording is the trap. New teams get no exemption, and Sprint cancellation is a separate rule.

1. Identify which pair of pillars the stem asks about.
2. Recall the Guide's phrase for inspection without adaptation.
3. Do not confuse it with the phrase for inspection without transparency.

Exam tip: No transparency: misleading and wasteful. No adaptation: pointless.

Scrum provides a cadence for inspection through its events; each event is a formal opportunity to inspect and adapt, and the events are designed to provoke change.

The events put the empirical pillars into practice on a regular cadence. They are not reporting checkpoints, they are not optional for mature teams, and they are not task-assignment sessions — each distractor describes a common misuse.

1. Recall why Scrum has events.
2. Link them to inspection and adaptation.
3. Reject options that describe reporting, skipping or assigning work.

Exam tip: Every Scrum event is a formal chance to inspect and adapt.

Adaptation: adjustments must be made as soon as possible; adaptation becomes more difficult when people are not empowered or self-managing.

To adapt quickly, the people who see the problem need the authority to act on it. If every change must go up a chain of approval, adaptation slows down. Sprint length, estimation and an organisational Definition of Done are not what the Guide links to difficulty adapting.

1. Recall the adaptation paragraph of Scrum Theory.
2. Ask what stops people acting on what they learn.
3. Choose lack of empowerment or self-management.

Exam tip: People who cannot decide cannot adapt quickly.

Adaptation: when a process or product deviates outside acceptable limits, the adjustment must be made as soon as possible to minimise further deviation.

Waiting for the Sprint Retrospective is the tempting answer, because process improvement is its purpose. But the Guide is explicit that adjustments are made as soon as possible, and that a Scrum Team adapts the moment it learns something new. The Retrospective is a formal opportunity, not the only one.

1. Note that the deviation is already outside acceptable limits.
2. Recall that the Guide asks for adjustment as soon as possible.
3. Reject options that delay the change to a later event or an approval.

Exam tip: Found a problem? Adapt now; the Retrospective is not a waiting room.

A Scrum Team is expected to adapt the moment it learns anything new through inspection. The Developers own the Sprint Backlog and may renegotiate scope with the Product Owner while keeping the Sprint Goal.

Two facts combine here. First, empiricism expects adaptation as soon as something new is learned, so the Developers re-plan now rather than at the Retrospective. Second, the Sprint Goal is fixed but the work to reach it is flexible: the Developers own their plan, and scope can be clarified and renegotiated with the Product Owner. Extending the Sprint and seeking the Scrum Master's approval both break the framework.

1. Recognise that the team has learned something new mid-Sprint.
2. Recall that adaptation should happen as soon as possible.
3. Recall who owns the Sprint Backlog and who can renegotiate scope.
4. Reject delay, Sprint extension and approval steps.

Exam tip: The Sprint Goal stays; the plan to reach it changes as soon as you learn.

Scrum Values: commitment, focus, openness, respect and courage.

The Guide names five values. The wrong lists mix in transparency (a pillar) and trust (what the values build), each in place of a real value. Knowing the exact five avoids these near-misses.

1. Recall the five values.
2. Check each list for an item that is a pillar or a result of the values.
3. Keep the list that matches exactly.

Exam tip: Values: commitment, focus, openness, respect, courage — not transparency.

Courage: Scrum Team members have the courage to do the right thing and to work on tough problems.

The key detail is pressure from someone senior to do something the team believes is wrong. Saying no in that situation is the Guide's description of courage. Openness and respect may be present, but they are not the value the behaviour most directly shows.

1. Identify the pressure and the risk to the Developer.
2. Recall the Guide's description of each value.
3. Match 'doing the right thing under pressure' to courage.

Exam tip: Courage: doing the right thing when it is uncomfortable.

Respect: Scrum Team members respect each other to be capable, independent people, and are respected as such by the people with whom they work.

The Product Owner gives the what and why and leaves the how to the Developers because they are trusted as capable professionals. That is the Guide's description of respect. Openness is present in sharing the reason, but the behaviour the stem centres on is trust in the others' capability.

1. Find the central behaviour: trusting the Developers' expertise.
2. Recall which value is about treating people as capable and independent.
3. Choose respect.

Exam tip: Respect: treat teammates as capable, independent people.

Openness: the Scrum Team and its stakeholders are open about the work and the challenges.

Courage is the tempting answer because sharing bad news can feel risky. But the Guide's wording for openness covers exactly this: being open with stakeholders about the work and its challenges, not only the successes. Pick the value whose description matches the behaviour, not the feeling behind it.

1. Identify the behaviour: sharing problems as well as progress.
2. Recall the Guide's description of openness, which mentions stakeholders and challenges.
3. Prefer it over courage, which is about doing the right thing on tough problems.

Exam tip: Openness: be open about the work and its challenges, not just the wins.

Commitment: the Scrum Team commits to achieving its goals and to supporting each other.

Commitment is to goals (such as the Sprint Goal and Product Goal) and to each other, not to a fixed list of items, estimates or dates. A common folk version of Scrum treats the selected backlog items as a promise; the 2020 Guide keeps the scope flexible and the goal firm.

1. Recall the wording of commitment in the Scrum Values section.
2. Notice that it names goals and mutual support.
3. Reject commitments to items, estimates or dates.

Exam tip: Commit to goals and to each other, not to a fixed list of items.

Within a Scrum Team there are no sub-teams or hierarchies; Developers decide how to do the work together.

The Scrum Guide describes the Scrum Team as a cohesive unit of professionals with no sub-teams or hierarchies, and says no one tells the Developers how to turn Product Backlog items into Increments. A tech lead who must approve the others' decisions creates exactly such a hierarchy. The near-twin distractor reaches the right verdict for the wrong reason: the Scrum Master is a true leader who serves, but does not approve technical decisions either.

1. Identify the structure being proposed: one Developer approving the others' decisions.
2. Recall that a Scrum Team has no hierarchies.
3. Check the reason given in each option, not only the verdict.

Exam tip: No hierarchies inside a Scrum Team: no one approves the Developers' technical choices.

The Scrum Guide prescribes no tracking tool; how the Developers manage their own work is theirs to decide.

The Scrum Guide says the Sprint Backlog is a plan by and for the Developers and that the team decides internally how the work is done. It mentions burn-downs, burn-ups and cumulative flow only as practices that can help, not as requirements. So a burndown chart is optional, and the Developers can swap it for a technique that works better for them. The Scrum Master may coach the team on it, but does not decide.

1. Check whether the Guide requires the practice: it does not require burndowns.
2. Identify whose work is being managed: the Developers' own Sprint work.
3. Apply self-management: the team chooses how it manages that work.

Exam tip: Burndowns are optional; the Developers choose how they track their own work.

Some decisions belong to the Developers alone; others belong to the Product Owner or to the whole Scrum Team.

The Scrum Guide gives the Developers sole discretion over how to turn Product Backlog items into Increments, and lets them choose the structure and techniques of their Daily Scrum. The near-twins are decisions made by the whole Scrum Team (the Sprint Goal, and the Definition of Done where the organization has none) and the Product Owner's ordering of the Product Backlog. Self-management does not turn every team decision into a Developers-only decision.

1. For each option, recall who the Guide names: Developers, Product Owner or Scrum Team.
2. Keep the options the Guide gives to the Developers alone.
3. Watch for whole-team decisions dressed up as Developer decisions.

Exam tip: Developers alone: how to build the Increment, and how to run the Daily Scrum. Scrum Team: Sprint Goal and (if no standard) Definition of Done.

When work differs from the forecast, the Developers renegotiate Sprint Backlog scope with the Product Owner while keeping the Sprint Goal.

The Scrum Guide says that if the work turns out different from what was expected, the Developers collaborate with the Product Owner to negotiate the scope of the Sprint Backlog without affecting the Sprint Goal. It also says no changes endanger the Sprint Goal and quality does not decrease. Extending the Sprint and lowering the Definition of Done break those rules. Dropping the item alone is the near-twin: the Developers self-manage their plan, but scope is negotiated with the Product Owner.

1. Recall what is fixed during a Sprint: the Sprint Goal, the Sprint length and quality.
2. Recall what may change: the Sprint Backlog scope, by negotiation with the Product Owner.
3. Pick the options that change scope with the Product Owner and protect the Sprint Goal.

Exam tip: Scope flexes with the Product Owner; the Sprint Goal, timebox and quality stay fixed.

Self-management operates inside the Sprint Goal; new ideas go to the Product Owner for the Product Backlog.

Two facts combine. First, the Sprint Goal is the Developers' commitment for the Sprint, and the Guide says no changes are made that would endanger it. Second, the Product Owner is accountable for ordering the Product Backlog, so new work such as a refactoring is raised there. The tempting distractor quotes the 2020 idea that the team chooses "what" to work on, but that choice is exercised through Sprint Planning and the Sprint Goal, not by abandoning a valid goal mid-Sprint. Only the Product Owner could cancel a Sprint, and only if its goal became obsolete.

1. Check whether the Sprint Goal is still valid: it is.
2. Recall that changes must not endanger the Sprint Goal.
3. Route the new idea to the Product Owner and the Product Backlog.
4. Reject options that use self-management to override a commitment.

Exam tip: Self-managing does not mean dropping the Sprint Goal; new work goes through the Product Owner.

The Developers choose how to run their Daily Scrum, which supports their self-management.

The Scrum Guide says the Developers can use whatever structure and techniques they want for the Daily Scrum, as long as it focuses on progress toward the Sprint Goal and produces an actionable plan for the next day. It adds that this improves self-management. The "whole Scrum Team" distractor is the near-twin: the event is for the Developers, so the choice is theirs.

1. Recall who the Daily Scrum is for: the Developers.
2. Recall that the Guide fixes the purpose and timebox, but not the format.
3. Give the format choice to the Developers.

Exam tip: Daily Scrum format = the Developers' choice; purpose and 15-minute timebox are fixed.

Lead time belongs to Time to Market, and slower delivery slows the feedback loop that empiricism depends on.

Two facts combine. First, the EBM Guide places lead time, release frequency and time to learn under Time to Market. Second, the cost of a longer lead time is slower learning: ideas wait months before users can validate them, so the product adapts later and responds more slowly to opportunities. Healthy Current Value (revenue and satisfaction rising) does not cancel that risk, which is why the near-twin options that misplace either the area or the risk are wrong.

1. Classify the measure: idea-to-user lead time is Time to Market.
2. Ask what slower delivery costs in an empirical approach: slower feedback and learning.
3. Check that the risk is supported by the evidence given, not a guess about Current Value.

Exam tip: Strong Current Value can hide a weakening Time to Market; slow delivery means slow learning.

A product's stakeholders include its users and customers, who are outside the Scrum Team.

The Scrum Guide describes a product as having known stakeholders and well-defined users or customers, and Scrum.org's glossary describes a stakeholder as a person outside the Scrum Team with an interest in and knowledge of the product. The list in the stem covers internal business functions but misses the users and customers whose needs the product exists to meet. The three Scrum Team accountabilities are inside the team, so they are not its stakeholders.

1. Recall that stakeholders are outside the Scrum Team.
2. Ask whose needs the product exists to serve: users and customers.
3. Reject the three Scrum Team accountabilities.

Exam tip: Users and customers are stakeholders; Scrum Team members are not.

A stakeholder is a person outside the Scrum Team with an interest in and knowledge of the product.

Scrum.org's glossary describes a stakeholder as someone external to the Scrum Team with a specific interest in and knowledge of the product that the team needs for incremental discovery; the Product Owner represents stakeholders, and they engage actively with the Scrum Team at the Sprint Review. The distractors attach approval powers or priority-setting that Scrum gives to nobody outside the team, or count team members as stakeholders.

1. Recall that stakeholders are external to the Scrum Team.
2. Recall that they bring interest in and knowledge of the product.
3. Reject options that give them approval or priority-setting powers.

Exam tip: Stakeholders are outside the team and bring interest and knowledge, not approval rights.

The Sprint Review is where stakeholders inspect the outcome of the Sprint and help decide what comes next.

The Scrum Guide says the Sprint Review inspects the outcome of the Sprint and determines future adaptations: the Scrum Team presents its results to key stakeholders, progress toward the Product Goal is discussed, and attendees collaborate on what to do next. Sprint Planning can include invited advisors, but it does not inspect what was achieved; the Retrospective and Daily Scrum are internal to the team.

1. Identify the two needs: see results and influence next steps.
2. Find the event whose purpose covers both.
3. Reject events that are internal to the Scrum Team or that plan rather than inspect.

Exam tip: Stakeholders inspect the Increment and shape next steps at the Sprint Review.

Sprint Review feedback can change the Product Backlog, and the Product Owner decides how.

The Scrum Guide says the Product Backlog may be adjusted at the Sprint Review to meet new opportunities. The Product Owner remains accountable for its ordering, so a customer's request is input to her decision rather than an automatic change. Adding to the ending Sprint misreads timing, and deferring all change to a separate meeting ignores that the Review exists to adapt.

1. Recall that the Sprint Review can adjust the Product Backlog.
2. Recall who orders the Product Backlog: the Product Owner.
3. Reject automatic reordering, adding to the ending Sprint and waiting for another meeting.

Exam tip: Stakeholders inform the order at the Sprint Review; the Product Owner decides it.

The Scrum Team may invite outside people to Sprint Planning for advice.

In the Sprint Planning section, the Scrum Guide says the Scrum Team may also invite other people to attend to provide advice. That makes stakeholders and experts welcome as advisors while the Scrum Team keeps its decisions: it defines the Sprint Goal, and the Developers select the work and plan how to do it.

1. Recall the Sprint Planning section of the Scrum Guide.
2. Note the explicit permission to invite others for advice.
3. Reject options that bar outsiders or give them approval powers.

Exam tip: Outsiders can advise at Sprint Planning; the Scrum Team still decides.

Advisors may join Sprint Planning; the Sprint Goal and Sprint Backlog stay with the Scrum Team.

Two facts combine. The Scrum Guide allows the Scrum Team to invite other people to Sprint Planning to provide advice, and it says the whole Scrum Team collaborates to define the Sprint Goal while the Developers own the Sprint Backlog. An expert's input therefore improves the plan without transferring any decision to her.

1. Recall that advisors may be invited to Sprint Planning.
2. Recall who defines the Sprint Goal and who owns the Sprint Backlog.
3. Reject options that give the advisor a decision or add conditions the Guide does not state.

Exam tip: Experts advise; the Scrum Team commits.

The Sprint Goal tells stakeholders why the Sprint is valuable.

The first Sprint Planning topic is why the Sprint is valuable: the Product Owner proposes how the product could increase its value, and the whole Scrum Team defines a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The goal is an objective, not a list of assignments, a point total or a release date.

1. Recall the first Sprint Planning topic: why is this Sprint valuable?
2. Connect it to the Sprint Goal.
3. Reject assignments, quantities and release dates.

Exam tip: The Sprint Goal is the 'why' of the Sprint, written for stakeholders.