Professional Scrum Master I (PSM I) Exam Questions

According to the Scrum Guide, Scrum is founded on which two foundations?

✅ Empiricism and lean thinking
⬜ Waterfall and empiricism
⬜ Predictive planning and lean thinking
⬜ Agile principles and iterative planning

Explanation:
The Scrum Guide states that Scrum is founded on empiricism and lean thinking, combining an iterative, incremental approach to optimize predictability and control risk.
Why other options are incorrect:
● Waterfall and empiricism — Waterfall is a predictive, sequential approach and is not part of Scrum’s theoretical foundation described in the Guide.
● Predictive planning and lean thinking — “Predictive planning” contradicts empiricism, which is based on experience and decisions made from what is observed, not upfront prediction.
● Agile principles and iterative planning — “Agile principles” is not the phrase the Scrum Guide uses to describe Scrum’s theoretical foundation; the Guide specifically names empiricism and lean thinking.
Source: The Scrum Guide (2020)

---

Scrum combines four formal events for inspection and adaptation within a containing event. What is that containing event called?

✅ The Sprint
⬜ The Daily Scrum
⬜ The Release
⬜ The Program Increment

Explanation:
The Scrum Guide describes the Sprint as the container for all other Scrum events, inside which the four formal inspect-and-adapt events take place.
Why other options are incorrect:
● The Daily Scrum — The Daily Scrum is one of the four formal events for inspection and adaptation, not the containing event.
● The Release — “Release” is not an event defined anywhere in the Scrum Guide.
● The Program Increment — “Program Increment” is not an event defined anywhere in the Scrum Guide.
Source: The Scrum Guide (2020)

---

The Scrum Guide names three pillars that uphold every implementation of empirical process control: transparency, inspection, and adaptation. Which TWO of the following statements about these pillars are accurate?

✅ Inspection enables adaptation; inspection without adaptation is considered pointless.
⬜ Adaptation enables transparency; without adaptation, transparency is impossible.
✅ Transparency enables inspection; inspection without transparency is misleading and wasteful.
⬜ Adaptation becomes easier when the people involved are not empowered or self-managing.

Explanation:
The Scrum Guide states that transparency enables inspection, and inspection in turn enables adaptation — inspection without adaptation is considered pointless, and inspection without transparency is misleading and wasteful.
Why other options are incorrect:
● Adaptation enables transparency; without adaptation, transparency is impossible. — This reverses the actual relationship described in the Guide; transparency enables inspection, not the other way around.
● Adaptation becomes easier when the people involved are not empowered or self-managing. — This contradicts the Guide, which states adaptation becomes MORE difficult, not easier, when the people involved are not empowered or self-managing.
Source: The Scrum Guide (2020)

---

Per the Scrum Guide, what happens to inspection when it is not followed by adaptation?

⬜ It becomes more valuable
✅ It is considered pointless
⬜ It automatically triggers a Sprint cancellation
⬜ It replaces the need for transparency

Explanation:
The Scrum Guide states plainly that inspection enables adaptation, and inspection without adaptation is considered pointless.
Why other options are incorrect:
● It becomes more valuable — This is the opposite of what the Guide states; inspection without follow-through adaptation loses its value.
● It automatically triggers a Sprint cancellation — The Guide does not connect a lack of adaptation to Sprint cancellation; only the Product Owner can cancel a Sprint, and only if the Sprint Goal becomes obsolete.
● It replaces the need for transparency — Transparency enables inspection, not the reverse; inspection does not replace or substitute for transparency.
Source: The Scrum Guide (2020)

---

How many values does the Scrum Guide define, and what is their stated purpose?

⬜ Three values; they define the Scrum Team’s roles
⬜ Four values; they define the length of each timebox
✅ Five values; they give direction to the Scrum Team with regard to their work, actions, and behavior
⬜ Five values; they replace the need for Scrum events

Explanation:
The Scrum Guide defines five values — Commitment, Focus, Openness, Respect, and Courage — and states these values give direction to the Scrum Team with regard to their work, actions, and behavior.
Why other options are incorrect:
● Three values; they define the Scrum Team’s roles — The Guide defines five values, not three, and values are not role definitions.
● Four values; they define the length of each timebox — The Guide defines five values, not four, and values are not timeboxes.
● Five values; they replace the need for Scrum events — Values do not replace the events; the events remain necessary to create the cadence for inspection and adaptation.
Source: The Scrum Guide (2020)

---

Which TWO of the following are among the five Scrum values named in the Scrum Guide?

⬜ Discipline
✅ Courage
⬜ Predictability
✅ Respect

Explanation:
The five Scrum values named in the Scrum Guide are Commitment, Focus, Openness, Respect, and Courage.
Why other options are incorrect:
● Discipline — Discipline is not one of the five Scrum values listed in the Guide.
● Predictability — Predictability is an outcome Scrum’s iterative, incremental approach aims to optimize, but it is not one of the five Scrum values.
Source: The Scrum Guide (2020)

---

According to the Scrum Guide, what is expected of a Scrum Team the moment it learns something new through inspection?

⬜ It should wait until the next Sprint Retrospective to act
✅ It is expected to adapt immediately
⬜ It should escalate the change to the Product Owner for approval before adapting
⬜ It should document the learning for the next release cycle

Explanation:
The Scrum Guide states that a Scrum Team is expected to adapt the moment it learns anything new through inspection, so adjustments are made as soon as possible to minimize further deviation.
Why other options are incorrect:
● It should wait until the next Sprint Retrospective to act — Waiting for the Retrospective contradicts the Guide’s emphasis on adapting immediately upon learning something new.
● It should escalate the change to the Product Owner for approval before adapting — The Guide does not require Product Owner pre-approval before a team adapts its own process; scope changes to the Sprint Backlog specifically are negotiated with the Product Owner, but that is a separate point.
● It should document the learning for the next release cycle — The Guide calls for adaptation, not a documentation-only response to what was learned.
Source: The Scrum Guide (2020)

---

True or False: According to the Scrum Guide, artifacts with low transparency can lead to decisions that diminish value and increase risk.

✅ True
⬜ False

Explanation:
The Scrum Guide states this directly under its description of the Transparency pillar: important decisions are based on the perceived state of the three formal artifacts, and artifacts with low transparency can lead to decisions that diminish value and increase risk.
Why other options are incorrect:
● False — This is false — the Guide explicitly states that low-transparency artifacts create exactly this risk.
Source: The Scrum Guide (2020)

---

Which of the following correctly describes the composition of a Scrum Team as defined in the Scrum Guide?

✅ One Scrum Master, one Product Owner, and Developers, with no sub-teams or hierarchies
⬜ A Product Owner, a Project Manager, and a Development Team led by a Team Lead
⬜ Multiple Scrum Masters overseeing several development sub-teams
⬜ A Product Owner and Developers only; the Scrum Master is optional

Explanation:
The Scrum Guide defines the Scrum Team as consisting of one Scrum Master, one Product Owner, and Developers, with no sub-teams or hierarchies within it.
Why other options are incorrect:
● A Product Owner, a Project Manager, and a Development Team led by a Team Lead — The Guide does not define “Project Manager” or “Team Lead” roles within the Scrum Team.
● Multiple Scrum Masters overseeing several development sub-teams — The Guide specifies one Scrum Master per Scrum Team, and it explicitly states there are no sub-teams within the team.
● A Product Owner and Developers only; the Scrum Master is optional — The Guide defines the Scrum Master as one of exactly three accountabilities in the Scrum Team, not as optional.
Source: The Scrum Guide (2020)

---

What team size does the Scrum Guide suggest a Scrum Team should be to remain nimble yet still complete significant work within a Sprint?

⬜ Exactly 5 people
✅ Typically 10 or fewer people
⬜ Between 15 and 20 people
⬜ No size guidance is given

Explanation:
The Scrum Guide states the Scrum Team should be small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people.
Why other options are incorrect:
● Exactly 5 people — The Guide does not fix an exact number of 5; it offers “typically 10 or fewer” as general guidance, not a hard rule.
● Between 15 and 20 people — 15-20 contradicts the Guide’s note that smaller teams communicate better, and that overly large teams should reorganize.
● No size guidance is given — This is incorrect — the Guide does give this general size guidance.
Source: The Scrum Guide (2020)

---

Which TWO characteristics does the current Scrum Guide use to describe Scrum Teams?

✅ Cross-functional
⬜ Self-organizing
✅ Self-managing
⬜ Hierarchical

Explanation:
The Scrum Guide describes Scrum Teams as cross-functional, meaning members have all the skills necessary to create value each Sprint, and self-managing, meaning they internally decide who does what, when, and how.
Why other options are incorrect:
● Self-organizing — “Self-organizing” was used in earlier, pre-2020 versions of the Scrum Guide; the current 2020 Scrum Guide specifically uses “self-managing” instead.
● Hierarchical — The Guide explicitly states there are no hierarchies within a Scrum Team.
Source: The Scrum Guide (2020)

---

Who is accountable for creating a valuable, useful Increment every Sprint, according to the Scrum Guide?

⬜ The Product Owner alone
⬜ The Developers alone
✅ The entire Scrum Team
⬜ The Scrum Master, since they own the Definition of Done

Explanation:
The Scrum Guide states that the entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.
Why other options are incorrect:
● The Product Owner alone — The Product Owner is accountable for maximizing product value and Product Backlog management, not solely for producing the Increment.
● The Developers alone — Developers do the work of building the Increment, but the Guide assigns the accountability to the entire Scrum Team, not the Developers in isolation.
● The Scrum Master, since they own the Definition of Done — The Scrum Master does not “own” the Definition of Done; it is a shared standard the whole Scrum Team must conform to, and the Guide credits the whole Scrum Team with this accountability, not the Scrum Master specifically.
Source: The Scrum Guide (2020)

---

Which TWO of the following are accountabilities of the Developers, as defined in the Scrum Guide?

✅ Creating the Sprint Backlog, the plan for the Sprint
⬜ Ordering the Product Backlog
✅ Instilling quality by adhering to a Definition of Done
⬜ Setting the price of the certification exam

Explanation:
The Scrum Guide lists Developer accountabilities as: creating the Sprint Backlog, instilling quality by adhering to a Definition of Done, adapting their plan daily toward the Sprint Goal, and holding each other accountable as professionals.
Why other options are incorrect:
● Ordering the Product Backlog — Ordering the Product Backlog is a Product Owner accountability, not a Developer accountability.
● Setting the price of the certification exam — Setting exam pricing is not a Scrum concept described anywhere in the Scrum Guide; it is an unrelated distractor.
Source: The Scrum Guide (2020)

---

According to the Scrum Guide, what is the Product Owner primarily accountable for?

⬜ Assigning daily tasks to the Developers
✅ Maximizing the value of the product resulting from the work of the Scrum Team
⬜ Facilitating the Daily Scrum
⬜ Removing impediments faced by the Developers

Explanation:
The Scrum Guide states the Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.
Why other options are incorrect:
● Assigning daily tasks to the Developers — The Guide describes Developers as self-managing, deciding internally who does what, when, and how; the Product Owner does not assign daily tasks.
● Facilitating the Daily Scrum — The Daily Scrum is an event for the Developers; the Guide does not assign its facilitation to the Product Owner.
● Removing impediments faced by the Developers — Causing the removal of impediments is listed as a way the Scrum Master serves the team, not a Product Owner accountability.
Source: The Scrum Guide (2020)

---

Per the Scrum Guide, can a Product Owner delegate Product Backlog management work to others?

⬜ No, the Product Owner must personally perform every Product Backlog management activity
✅ Yes, but the Product Owner remains accountable
⬜ Yes, and accountability transfers to whoever performs the delegated work
⬜ No, delegation would violate the self-managing nature of the Scrum Team

Explanation:
The Scrum Guide states the Product Owner may do Product Backlog management work themselves or delegate it to others, but regardless, the Product Owner remains accountable.
Why other options are incorrect:
● No, the Product Owner must personally perform every Product Backlog management activity — The Guide explicitly permits delegating this work; the Product Owner need not do all of it personally.
● Yes, and accountability transfers to whoever performs the delegated work — The Guide states the Product Owner “remains accountable” even after delegating; accountability does not transfer to the delegate.
● No, delegation would violate the self-managing nature of the Scrum Team — Delegating Product Backlog work does not conflict with the Scrum Team’s self-management, which is about Developers deciding who does what, when, and how within the Sprint.
Source: The Scrum Guide (2020)

---

According to the Scrum Guide, how should stakeholders who want to change the Product Backlog proceed?

⬜ By submitting a formal change request to the Scrum Master
✅ By trying to convince the Product Owner
⬜ By voting with the Developers during Sprint Planning
⬜ By directly editing the Product Backlog themselves

Explanation:
The Scrum Guide states that those wanting to change the Product Backlog can do so by trying to convince the Product Owner.
Why other options are incorrect:
● By submitting a formal change request to the Scrum Master — The Guide does not describe a formal change-request process routed through the Scrum Master; the Product Owner is the one stakeholders must persuade.
● By voting with the Developers during Sprint Planning — Developers do not vote on Product Backlog changes; ordering the Product Backlog is the Product Owner’s accountability.
● By directly editing the Product Backlog themselves — The Product Backlog is a single source of work managed under the Product Owner’s accountability, not something stakeholders edit directly.
Source: The Scrum Guide (2020)

---

What is the Scrum Master accountable for, per the Scrum Guide?

✅ Establishing Scrum as defined in the Scrum Guide, and the Scrum Team’s effectiveness
⬜ Writing the Product Backlog items
⬜ Approving the Increment before it can be released
⬜ Managing the organization’s budget for the product

Explanation:
The Scrum Guide states the Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide, and for the Scrum Team’s effectiveness.
Why other options are incorrect:
● Writing the Product Backlog items — Creating and clearly communicating Product Backlog items is part of the Product Owner’s accountability for Product Backlog management.
● Approving the Increment before it can be released — The Guide describes no Scrum Master “approval gate” for the Increment; in fact, the Sprint Review is explicitly stated to never be a gate to releasing value.
● Managing the organization’s budget for the product — Budget management is not described anywhere in the Scrum Guide as a Scrum Master accountability.
Source: The Scrum Guide (2020)

---

If a Scrum Team becomes too large to remain nimble, what does the Scrum Guide suggest?

⬜ Appoint a second Scrum Master to manage the extra members
⬜ Split into multiple sub-teams under one Scrum Master
✅ Consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product and sharing the same Product Goal, Product Backlog, and Product Owner
⬜ Increase the Sprint length to accommodate more people

Explanation:
The Scrum Guide states that if Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product, sharing the same Product Goal, Product Backlog, and Product Owner.
Why other options are incorrect:
● Appoint a second Scrum Master to manage the extra members — The Guide does not describe adding a second Scrum Master to one oversized Scrum Team; each Scrum Team has one Scrum Master.
● Split into multiple sub-teams under one Scrum Master — Sub-teams contradict the Guide’s explicit statement that there are no sub-teams within a Scrum Team.
● Increase the Sprint length to accommodate more people — Lengthening the Sprint is not the Guide’s suggested remedy for an oversized team; reorganizing the team structure is.
Source: The Scrum Guide (2020)

---

True or False: According to the Scrum Guide, a Scrum Team may have multiple Product Owners representing different stakeholder groups.

⬜ True
✅ False

Explanation:
The Scrum Guide states, “The Product Owner is one person, not a committee,” though that one person may represent the needs of many stakeholders within the Product Backlog.
Why other options are incorrect:
● True — This is false — the Guide is explicit that the Product Owner is one person, not a committee, even while representing many stakeholders’ needs.
Source: The Scrum Guide (2020)

---

According to the Scrum Guide, what is the maximum length of a Sprint?

⬜ Two weeks
✅ One month or less
⬜ Six weeks
⬜ There is no maximum; it depends on the Product Owner

Explanation:
The Scrum Guide states Sprints are fixed-length events of one month or less, and a new Sprint starts immediately after the conclusion of the previous one.
Why other options are incorrect:
● Two weeks — Two weeks is a common practice in many organizations, but it is not the rule the Guide states; the Guide’s stated maximum is one month.
● Six weeks — Six weeks exceeds the Guide’s stated maximum Sprint length of one month.
● There is no maximum; it depends on the Product Owner — The Guide does specify a fixed maximum length (one month or less); it is not left open to the Product Owner’s discretion.
Source: The Scrum Guide (2020)

---

Who has the authority to cancel a Sprint, according to the Scrum Guide?

⬜ The Scrum Master
⬜ The Developers, by majority vote
✅ Only the Product Owner
⬜ Any stakeholder, if the Sprint Goal becomes obsolete

Explanation:
The Scrum Guide states that a Sprint could be cancelled if the Sprint Goal becomes obsolete, and only the Product Owner has the authority to cancel the Sprint.
Why other options are incorrect:
● The Scrum Master — The Scrum Master ensures events happen and are productive, but the Guide does not grant the Scrum Master authority to cancel a Sprint.
● The Developers, by majority vote — The Guide describes no voting mechanism for Sprint cancellation; it names a single accountable person, the Product Owner.
● Any stakeholder, if the Sprint Goal becomes obsolete — The Guide restricts this authority specifically to the Product Owner, not to any stakeholder.
Source: The Scrum Guide (2020)

---

Which TWO of the following does the Scrum Guide state must hold true during a Sprint?

✅ No changes are made that would endanger the Sprint Goal
⬜ The scope of the Sprint Backlog is completely fixed and can never be renegotiated
✅ Quality does not decrease
⬜ The Product Backlog may not be touched until the Sprint ends

Explanation:
The Scrum Guide states that during the Sprint: no changes are made that would endanger the Sprint Goal; quality does not decrease; the Product Backlog is refined as needed; and scope may be clarified and renegotiated with the Product Owner as more is learned.
Why other options are incorrect:
● The scope of the Sprint Backlog is completely fixed and can never be renegotiated — The Guide states that scope “may be clarified and renegotiated with the Product Owner as more is learned” — it is not completely fixed.
● The Product Backlog may not be touched until the Sprint ends — The Guide states “The Product Backlog is refined as needed” during the Sprint, so it is not off-limits.
Source: The Scrum Guide (2020)

---

What is the maximum timebox for Sprint Planning in a one-month Sprint, per the Scrum Guide?

⬜ Four hours
✅ Eight hours
⬜ Two hours
⬜ There is no timebox for Sprint Planning

Explanation:
The Scrum Guide states that Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint, and is usually shorter for shorter Sprints.
Why other options are incorrect:
● Four hours — Four hours is the Guide’s timebox for the Sprint Review, not Sprint Planning.
● Two hours — Two hours is not a timebox the Scrum Guide assigns to any of the five events.
● There is no timebox for Sprint Planning — The Guide does define a timebox for Sprint Planning: a maximum of eight hours for a one-month Sprint.
Source: The Scrum Guide (2020)

---

The Scrum Guide describes Sprint Planning as addressing three topics. Which of the following correctly reflects them?

✅ Why is this Sprint valuable? What can be Done this Sprint? How will the chosen work get done?
⬜ Who will do the work? What is the budget? When is the deadline?
⬜ What went wrong last Sprint? What should we improve? Who is responsible?
⬜ What is the Definition of Done? Who are the stakeholders? What is the Sprint length?

Explanation:
The Scrum Guide states Sprint Planning addresses three topics: Why is this Sprint valuable?, What can be Done this Sprint?, and How will the chosen work get done?
Why other options are incorrect:
● Who will do the work? What is the budget? When is the deadline? — The Guide does not frame Sprint Planning around budget or deadline questions; it addresses value, scope, and a delivery plan instead.
● What went wrong last Sprint? What should we improve? Who is responsible? — This describes the focus of the Sprint Retrospective, not Sprint Planning.
● What is the Definition of Done? Who are the stakeholders? What is the Sprint length? — The Guide does not structure Sprint Planning around these questions; the Definition of Done, stakeholders, and Sprint length are addressed elsewhere in the framework.
Source: The Scrum Guide (2020)

---

Per the Scrum Guide, who decides how the selected Product Backlog items will be turned into an Increment during Sprint Planning?

⬜ The Product Owner, since they know the business priorities
⬜ The Scrum Master, who plans the technical approach
✅ The Developers, at their sole discretion
⬜ A separate architecture review board

Explanation:
The Scrum Guide states that for each selected item, the Developers plan the work necessary to create an Increment, and how this is done is at the sole discretion of the Developers — no one else tells them how to turn Product Backlog items into Increments of value.
Why other options are incorrect:
● The Product Owner, since they know the business priorities — The Guide has the Product Owner discuss “what” can be done with the Developers, but the “how” is at the Developers’ sole discretion.
● The Scrum Master, who plans the technical approach — The Guide does not assign technical planning of the work to the Scrum Master.
● A separate architecture review board — The Guide does not describe any external review board involved in the Scrum Team’s planning.
Source: The Scrum Guide (2020)

---

What is the timebox for the Daily Scrum, and who is it for, according to the Scrum Guide?

⬜ 30 minutes, for the entire Scrum Team including stakeholders
✅ 15 minutes, for the Developers
⬜ 15 minutes, for the Scrum Master to report to management
⬜ One hour, for the Product Owner to review priorities

Explanation:
The Scrum Guide states the Daily Scrum is a 15-minute event for the Developers of the Scrum Team, held to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary.
Why other options are incorrect:
● 30 minutes, for the entire Scrum Team including stakeholders — 30 minutes and including stakeholders both contradict the Guide’s 15-minute, Developers-focused description.
● 15 minutes, for the Scrum Master to report to management — The Guide does not describe the Daily Scrum as a status report delivered by the Scrum Master to management.
● One hour, for the Product Owner to review priorities — The Guide sets a 15-minute timebox, not one hour, and the event is for the Developers, not a Product Owner priority review.
Source: The Scrum Guide (2020)

---

If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, how do they participate in the Daily Scrum, per the Scrum Guide?

⬜ They observe silently without participating
✅ They participate as Developers
⬜ They lead the Daily Scrum instead of the Developers
⬜ They are excluded from the Daily Scrum entirely

Explanation:
The Scrum Guide states that if the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.
Why other options are incorrect:
● They observe silently without participating — The Guide does not describe a silent-observer role for them; it says they participate as Developers.
● They lead the Daily Scrum instead of the Developers — The Guide does not give the Product Owner or Scrum Master a leadership role over the Daily Scrum; the Developers control its structure and technique.
● They are excluded from the Daily Scrum entirely — The Guide does not exclude them; it specifically says they participate as Developers when working Sprint Backlog items.
Source: The Scrum Guide (2020)

---

What is the primary purpose of the Sprint Review, according to the Scrum Guide?

⬜ To assign story points for the next Sprint
✅ To inspect the outcome of the Sprint and determine future adaptations
⬜ To conduct a formal performance review of the Developers
⬜ To finalize the Definition of Done for the first time

Explanation:
The Scrum Guide states the purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations, with the Scrum Team presenting results to key stakeholders.
Why other options are incorrect:
● To assign story points for the next Sprint — The Guide does not describe estimation or story-pointing as a Sprint Review activity; story points themselves are not mentioned anywhere in the Guide.
● To conduct a formal performance review of the Developers — The Guide does not describe individual performance reviews of the Developers as a Sprint Review purpose.
● To finalize the Definition of Done for the first time — The Definition of Done is not established for the first time at the Sprint Review; it is an existing standard the team conforms to throughout the Sprint.
Source: The Scrum Guide (2020)

---

What is the maximum timebox for the Sprint Review in a one-month Sprint, per the Scrum Guide?

⬜ Three hours
✅ Four hours
⬜ Eight hours
⬜ There is no maximum

Explanation:
The Scrum Guide states the Sprint Review is the second-to-last event of the Sprint and is timeboxed to a maximum of four hours for a one-month Sprint.
Why other options are incorrect:
● Three hours — Three hours is the Guide’s timebox for the Sprint Retrospective, not the Sprint Review.
● Eight hours — Eight hours is the Guide’s timebox for Sprint Planning, not the Sprint Review.
● There is no maximum — The Guide does specify a maximum timebox of four hours for a one-month Sprint.
Source: The Scrum Guide (2020)

---

According to the Scrum Guide, which event concludes the Sprint and is timeboxed to a maximum of three hours for a one-month Sprint?

⬜ Sprint Planning
⬜ Daily Scrum
⬜ Sprint Review
✅ Sprint Retrospective

Explanation:
The Scrum Guide states the Sprint Retrospective concludes the Sprint, and it is timeboxed to a maximum of three hours for a one-month Sprint.
Why other options are incorrect:
● Sprint Planning — Sprint Planning initiates the Sprint and is timeboxed to a maximum of eight hours, not three.
● Daily Scrum — The Daily Scrum is a 15-minute daily event; it does not conclude the Sprint.
● Sprint Review — The Sprint Review is the second-to-last event, timeboxed to four hours, not the event that concludes the Sprint.
Source: The Scrum Guide (2020)

---

True or False: According to the Scrum Guide, the Sprint Review should be limited to a presentation of the completed work.

⬜ True
✅ False

Explanation:
The Scrum Guide explicitly states, “The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.”
Why other options are incorrect:
● True — This is false — the Guide explicitly warns against limiting the Sprint Review to a presentation; it should be a collaborative working session.
Source: The Scrum Guide (2020)

---

Which commitment is associated with the Product Backlog, according to the Scrum Guide?

⬜ The Sprint Goal
⬜ The Definition of Done
✅ The Product Goal
⬜ The Increment forecast

Explanation:
The Scrum Guide states that each artifact contains a commitment: for the Product Backlog, it is the Product Goal.
Why other options are incorrect:
● The Sprint Goal — The Sprint Goal is the commitment for the Sprint Backlog, not the Product Backlog.
● The Definition of Done — The Definition of Done is the commitment for the Increment, not the Product Backlog.
● The Increment forecast — “Increment forecast” is not a commitment defined anywhere in the Scrum Guide.
Source: The Scrum Guide (2020)

---

Which TWO of the following artifact-commitment pairs are accurate according to the Scrum Guide?

✅ Sprint Backlog → Sprint Goal
✅ Increment → Definition of Done
⬜ Product Backlog → Sprint Goal
⬜ Increment → Product Goal

Explanation:
The Scrum Guide pairs each artifact with a commitment: Product Backlog → Product Goal; Sprint Backlog → Sprint Goal; Increment → Definition of Done.
Why other options are incorrect:
● Product Backlog → Sprint Goal — The Product Backlog’s commitment is the Product Goal, not the Sprint Goal.
● Increment → Product Goal — The Increment’s commitment is the Definition of Done, not the Product Goal.
Source: The Scrum Guide (2020)

---

How does the Scrum Guide define the Product Backlog?

⬜ A fixed, unchanging list of all future work
✅ An emergent, ordered list of what is needed to improve the product
⬜ A list maintained exclusively by the Developers
⬜ A record of completed Sprint Retrospective action items

Explanation:
The Scrum Guide defines the Product Backlog as an emergent, ordered list of what is needed to improve the product, and the single source of work undertaken by the Scrum Team.
Why other options are incorrect:
● A fixed, unchanging list of all future work — The Guide describes the Product Backlog as “emergent,” meaning it evolves over time, not fixed and unchanging.
● A list maintained exclusively by the Developers — Product Backlog management is a Product Owner accountability (work that may be delegated), not something maintained exclusively by the Developers.
● A record of completed Sprint Retrospective action items — The Guide does not define the Product Backlog as a log of retrospective action items; that is a separate, unrelated concept.
Source: The Scrum Guide (2020)

---

According to the Scrum Guide, what is Product Backlog refinement?

⬜ A formally timeboxed Scrum event held once per Sprint
✅ The act of breaking down and further defining Product Backlog items into smaller, more precise items
⬜ A ceremony required to occupy exactly 10% of team capacity
⬜ The Scrum Master’s task of reordering the backlog

Explanation:
The Scrum Guide defines Product Backlog refinement as the act of breaking down and further defining Product Backlog items into smaller, more precise items, describing it as an ongoing activity.
Why other options are incorrect:
● A formally timeboxed Scrum event held once per Sprint — Refinement is described as an ongoing activity, and it is not one of the five formal Scrum events the Guide defines.
● A ceremony required to occupy exactly 10% of team capacity — The Guide does not mandate any specific percentage of team capacity for refinement; this is a common misconception, not something stated in the Guide.
● The Scrum Master’s task of reordering the backlog — Reordering the Product Backlog is a Product Owner accountability, not the Scrum Master’s, and refinement is broader than reordering alone.
Source: The Scrum Guide (2020)

---

Who is responsible for sizing Product Backlog items, per the Scrum Guide?

⬜ The Product Owner alone
⬜ The Scrum Master
✅ The Developers who will be doing the work
⬜ An external estimation committee

Explanation:
The Scrum Guide states that the Developers who will be doing the work are responsible for the sizing, though the Product Owner may influence them by helping them understand and select trade-offs.
Why other options are incorrect:
● The Product Owner alone — The Guide gives the Product Owner an influencing role, not the sizing responsibility itself.
● The Scrum Master — Sizing is not described anywhere in the Guide as a Scrum Master responsibility.
● An external estimation committee — The Guide does not mention any external estimation committee.
Source: The Scrum Guide (2020)

---

What does the Product Goal describe, according to the Scrum Guide?

⬜ A single Sprint’s deliverable
✅ A future state of the product that serves as a target for the Scrum Team to plan against
⬜ The exact release date of the next version
⬜ A specific technical architecture decision

Explanation:
The Scrum Guide states the Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against, and is the long-term objective for the Scrum Team.
Why other options are incorrect:
● A single Sprint’s deliverable — A single Sprint’s deliverable is closer to the Increment or Sprint Goal, which operate at the Sprint level, not the longer-term Product Goal.
● The exact release date of the next version — The Guide does not tie the Product Goal to a specific release date.
● A specific technical architecture decision — Architecture decisions are not what the Product Goal describes in the Guide.
Source: The Scrum Guide (2020)

---

The Scrum Guide states the Sprint Backlog is composed of which three elements?

✅ The Sprint Goal (why), the selected Product Backlog items (what), and a plan for delivering the Increment (how)
⬜ A burndown chart, a velocity report, and a risk register
⬜ The Definition of Done, a stakeholder list, and a budget
⬜ The Product Goal, the Sprint Review agenda, and a retrospective summary

Explanation:
The Scrum Guide states 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).
Why other options are incorrect:
● A burndown chart, a velocity report, and a risk register — Burndown charts and velocity are mentioned only as optional forecasting practices elsewhere in the Guide, not as defined components of the Sprint Backlog.
● The Definition of Done, a stakeholder list, and a budget — None of these are described as Sprint Backlog components in the Guide.
● The Product Goal, the Sprint Review agenda, and a retrospective summary — The Product Goal belongs to the Product Backlog, not the Sprint Backlog; the other items listed are not Sprint Backlog components either.
Source: The Scrum Guide (2020)

---

True or False: According to the Scrum Guide, an Increment may be delivered to stakeholders before the end of the Sprint.

✅ True
⬜ False

Explanation:
The Scrum Guide states that an Increment may be delivered to stakeholders prior to the end of the Sprint, and that the Sprint Review should never be considered a gate to releasing value.
Why other options are incorrect:
● False — This is false — the Guide explicitly allows delivering an Increment before the Sprint ends.
Source: The Scrum Guide (2020)

---

If multiple Scrum Teams are working together on one product, what does the Scrum Guide require regarding the Definition of Done?

⬜ Each team may use a completely different Definition of Done
✅ They must mutually define and comply with the same Definition of Done
⬜ Only the Scrum Master of the lead team defines it for everyone
⬜ The Definition of Done does not apply when multiple teams are involved

Explanation:
The Scrum Guide states that if there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.
Why other options are incorrect:
● Each team may use a completely different Definition of Done — The Guide requires shared compliance with one common Definition of Done across teams on the same product, not independent standards per team.
● Only the Scrum Master of the lead team defines it for everyone — The Guide describes no “lead team Scrum Master” role that unilaterally sets the Definition of Done for other teams.
● The Definition of Done does not apply when multiple teams are involved — The Definition of Done still applies; the Guide explicitly addresses the multiple-team scenario rather than exempting it.
Source: The Scrum Guide (2020)

---

According to the Scrum Guide, when is a Product Backlog item considered part of an Increment?

⬜ As soon as a Developer marks it complete in a tracking tool
⬜ Only after the Sprint Review presentation
✅ The moment it meets the Definition of Done
⬜ When the Product Owner personally tests it

Explanation:
The Scrum Guide states that the moment a Product Backlog item meets the Definition of Done, an Increment is born.
Why other options are incorrect:
● As soon as a Developer marks it complete in a tracking tool — A tool status update alone does not satisfy the Guide’s requirement; the actual Definition of Done criteria must be met.
● Only after the Sprint Review presentation — The Guide ties Increment status to meeting the Definition of Done, not to the timing of the Sprint Review.
● When the Product Owner personally tests it — The Guide does not require personal Product Owner testing as the trigger for an Increment to exist.
Source: The Scrum Guide (2020)

---

Which TWO of the following are ways the Scrum Master serves the Scrum Team, according to the Scrum Guide?

✅ Causing the removal of impediments to the Scrum Team’s progress
⬜ Deciding which Product Backlog items the Developers must select for the Sprint
✅ Coaching the team members in self-management and cross-functionality
⬜ Approving the Increment for release

Explanation:
The Scrum Guide lists the Scrum Master serving the team by coaching members in self-management and cross-functionality, helping the team focus on high-value Increments that meet the Definition of Done, causing the removal of impediments, and ensuring events take place and stay within their timebox.
Why other options are incorrect:
● Deciding which Product Backlog items the Developers must select for the Sprint — Selecting Product Backlog items for the Sprint is done by the Developers themselves through discussion with the Product Owner, not decided for them by the Scrum Master.
● Approving the Increment for release — The Guide describes no Scrum Master “approval” step for releasing the Increment.
Source: The Scrum Guide (2020)

---

Which of the following correctly describes a way the Scrum Master serves the Product Owner, per the Scrum Guide?

⬜ Writing the Product Backlog items on the Product Owner’s behalf
✅ Facilitating stakeholder collaboration as requested or needed
⬜ Setting the Product Goal independently of the Product Owner
⬜ Making the final call on Product Backlog ordering

Explanation:
The Scrum Guide lists facilitating stakeholder collaboration as requested or needed among the ways the Scrum Master serves the Product Owner.
Why other options are incorrect:
● Writing the Product Backlog items on the Product Owner’s behalf — Creating and clearly communicating Product Backlog items is a Product Owner accountability; the Scrum Master instead helps the team understand the need for clear, concise items.
● Setting the Product Goal independently of the Product Owner — The Product Goal is developed and communicated by the Product Owner, not set independently by the Scrum Master.
● Making the final call on Product Backlog ordering — Ordering the Product Backlog is the Product Owner’s accountability, not the Scrum Master’s.
Source: The Scrum Guide (2020)

---

Which of the following correctly describes a way the Scrum Master serves the organization, per the Scrum Guide?

⬜ Managing the organization’s hiring decisions
✅ Leading, training, and coaching the organization in its Scrum adoption
⬜ Setting the organization’s overall product strategy
⬜ Approving the organization’s annual budget

Explanation:
The Scrum Guide lists leading, training, and coaching the organization in its Scrum adoption among the ways the Scrum Master serves the organization.
Why other options are incorrect:
● Managing the organization’s hiring decisions — Hiring decisions are not described anywhere in the Scrum Guide as a Scrum Master responsibility.
● Setting the organization’s overall product strategy — Setting product strategy is not attributed to the Scrum Master in the Guide.
● Approving the organization’s annual budget — Budget approval falls outside the Scrum Master accountabilities the Guide describes.
Source: The Scrum Guide (2020)

---

Who is accountable for the Scrum Team’s effectiveness, according to the Scrum Guide?

⬜ The Product Owner
⬜ The Developers collectively, with no single accountable role
✅ The Scrum Master
⬜ An external Agile coach

Explanation:
The Scrum Guide states the Scrum Master is accountable for the Scrum Team’s effectiveness, achieved by enabling the team to improve its practices within the Scrum framework.
Why other options are incorrect:
● The Product Owner — The Product Owner’s accountability centers on maximizing product value and Product Backlog management, not overall team effectiveness.
● The Developers collectively, with no single accountable role — The Guide assigns this accountability specifically to the Scrum Master, not to a diffuse collective with no named accountable role.
● An external Agile coach — The Guide does not define or require any “external Agile coach” role.
Source: The Scrum Guide (2020)

---

True or False: According to the Scrum Guide, the Scrum Master assigns daily tasks to the Developers.

⬜ True
✅ False

Explanation:
The Scrum Guide describes Developers as self-managing, internally deciding who does what, when, and how; the Scrum Master’s role is one of service and coaching, not task assignment.
Why other options are incorrect:
● True — This is false — assigning tasks would contradict the Guide’s description of Developers as self-managing and the Scrum Master as a servant-leader, not a manager who assigns work.
Source: The Scrum Guide (2020)

---

How does the Scrum Guide characterize Scrum Masters?

⬜ As project managers accountable for on-time delivery
✅ As true leaders who serve the Scrum Team and the larger organization
⬜ As administrative assistants who schedule meetings
⬜ As quality assurance testers for the Increment

Explanation:
The Scrum Guide states, “Scrum Masters are true leaders who serve the Scrum Team and the larger organization.”
Why other options are incorrect:
● As project managers accountable for on-time delivery — The Guide never uses “project manager” to describe the Scrum Master, and does not tie the role to delivery-timeline accountability the way a project manager would be.
● As administrative assistants who schedule meetings — While the Scrum Master does ensure events take place, the Guide’s characterization goes well beyond scheduling, explicitly naming them leaders.
● As quality assurance testers for the Increment — Quality assurance testing of the Increment is not a Scrum Master accountability described in the Guide.
Source: The Scrum Guide (2020)

---

Who, per the Scrum Guide, ensures that all Scrum events take place and are positive, productive, and kept within the timebox?

⬜ The Product Owner
⬜ The Developers
✅ The Scrum Master
⬜ The most senior Developer

Explanation:
The Scrum Guide lists “Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox” among the ways the Scrum Master serves the Scrum Team.
Why other options are incorrect:
● The Product Owner — The Product Owner participates in events like Sprint Planning and the Sprint Review, but the Guide attributes ensuring events happen and stay within timebox to the Scrum Master.
● The Developers — Developers run events like the Daily Scrum themselves, but the Guide assigns overall event facilitation and timeboxing to the Scrum Master.
● The most senior Developer — No “most senior Developer” role exists in the Scrum Guide; Developers hold no internal hierarchy.
Source: The Scrum Guide (2020)

---

A Scrum Team’s stakeholders keep approaching Developers directly mid-Sprint, disrupting their focus and bypassing the Product Owner. According to the Scrum Guide, whose accountability is it to address this organizational barrier?

⬜ The Product Owner’s, since stakeholders are their responsibility
✅ The Scrum Master’s, by removing barriers between stakeholders and the Scrum Team
⬜ The Developers’, by refusing to speak with any stakeholder
⬜ No one’s; the Scrum Guide does not address organizational barriers

Explanation:
The Scrum Guide lists “Removing barriers between stakeholders and Scrum Teams” among the ways the Scrum Master serves the organization.
Why other options are incorrect:
● The Product Owner’s, since stakeholders are their responsibility — The Product Owner represents stakeholders in the Product Backlog, but the Guide specifically assigns removing this kind of organizational barrier to the Scrum Master.
● The Developers’, by refusing to speak with any stakeholder — The Guide does not prescribe Developers refusing all stakeholder contact; the Guide’s mechanism is the Scrum Master addressing the organizational barrier.
● No one’s; the Scrum Guide does not address organizational barriers — The Guide does address this directly under how the Scrum Master serves the organization.
Source: The Scrum Guide (2020)

---

Which of the following best matches the Scrum Guide’s description of how the Scrum Master helps the Scrum Team with quality?

⬜ By personally writing the Definition of Done for the team
✅ By helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done
⬜ By testing every Increment before the Sprint Review
⬜ By lowering the Definition of Done when deadlines are tight

Explanation:
The Scrum Guide lists “Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done” among the ways the Scrum Master serves the Scrum Team.
Why other options are incorrect:
● By personally writing the Definition of Done for the team — The Guide does not state the Scrum Master personally writes the Definition of Done; the Scrum Team creates one appropriate for the product (or follows an organizational standard) collectively.
● By testing every Increment before the Sprint Review — The Guide does not assign Increment testing duties to the Scrum Master.
● By lowering the Definition of Done when deadlines are tight — The Guide states quality does not decrease during a Sprint, so lowering the Definition of Done under deadline pressure directly contradicts the Guide.
Source: The Scrum Guide (2020)