- Scrum is founded on empiricism. What does empiricism assert about how knowledge is gained?
- Knowledge comes from experience and from making decisions based on what is observed
- Knowledge comes from a fixed plan created at the start of the project
- Knowledge comes from copying processes used on past successful projects
- Knowledge comes from following a detailed specification approved by management
Correct answer: Knowledge comes from experience and from making decisions based on what is observed
Empiricism asserts that knowledge comes from experience and that decisions are made based on what is observed. Scrum uses an iterative, incremental approach precisely because the work is complex and outcomes cannot be fully predicted in advance, so the team learns by doing and inspecting actual results rather than relying solely on an upfront plan or copied processes.
- Which three pillars uphold the empirical process that Scrum is built on?
- Planning, execution, and review
- Transparency, inspection, and adaptation
- Commitment, focus, and respect
- Roles, events, and artifacts
Correct answer: Transparency, inspection, and adaptation
The three pillars that uphold Scrum's empirical process are transparency, inspection, and adaptation. Commitment, focus, courage, openness, and respect are the Scrum values, while roles, events, and artifacts are structural elements of the framework, not the empirical pillars.
- Why must significant aspects of the Scrum process be transparent before they can be inspected?
- Transparency is only required during Sprint Review, not for ongoing inspection
- Inspection is performed by managers who do not need transparency
- Inspection without transparency can lead to flawed decisions because what is observed is incomplete or misleading
- Transparency replaces the need for inspection entirely
Correct answer: Inspection without transparency can lead to flawed decisions because what is observed is incomplete or misleading
Transparency must precede meaningful inspection because inspection of an opaque or misleading situation produces decisions based on incomplete information, which leads to waste and diminished value. The Scrum Guide ties the pillars together: transparency enables inspection, and inspection enables adaptation.
- According to the causal chain among the three pillars, what must occur for adaptation to be effective?
- Adaptation can occur independently of inspection or transparency
- Adaptation depends only on the Product Owner approving changes
- Adaptation requires a formal change-control board
- Inspection must occur, which in turn depends on transparency
Correct answer: Inspection must occur, which in turn depends on transparency
Effective adaptation depends on inspection, and meaningful inspection depends on transparency. The pillars form a dependent chain: transparency enables inspection, and inspection enables adaptation. Without transparency, both inspection and the resulting adaptation are compromised.
- What are the five values of Scrum?
- Commitment, courage, focus, openness, and respect
- Transparency, inspection, adaptation, trust, and honesty
- Planning, discipline, accountability, ownership, and speed
- Collaboration, simplicity, feedback, communication, and quality
Correct answer: Commitment, courage, focus, openness, and respect
The five Scrum values are commitment, courage, focus, openness, and respect. Transparency, inspection, and adaptation are the three pillars, not values. When these values are embodied by the Scrum Team, the pillars of empiricism come to life and build trust.
- A Scrum Team member raises a difficult issue about the Increment's quality even though it may be uncomfortable for the group to hear. Which Scrum value is most directly demonstrated?
- Focus
- Courage
- Commitment
- Respect
Correct answer: Courage
Raising a difficult truth despite discomfort most directly demonstrates courage, the value of having the courage to do the right thing and work on tough problems. Focus concerns concentrating on Sprint work, commitment concerns dedication to goals, and respect concerns regarding people as capable and independent.
- The Scrum Team agrees to keep its attention on the work of the Sprint and the Sprint Goal rather than chasing unrelated requests. Which Scrum value does this best reflect?
- Openness
- Courage
- Focus
- Commitment
Correct answer: Focus
Concentrating attention on the Sprint's work and the Sprint Goal best reflects focus. Openness concerns being open about work and challenges, courage concerns tackling tough problems, and commitment concerns personal dedication to achieving the goals of the Scrum Team.
- Besides empiricism, what is the other foundational basis the 2020 Scrum Guide identifies for Scrum?
- Waterfall planning, which sequences phases
- Six Sigma, which removes statistical variation
- Critical path method, which optimizes scheduling
- Lean thinking, which reduces waste and focuses on essentials
Correct answer: Lean thinking, which reduces waste and focuses on essentials
The 2020 Scrum Guide states that Scrum is founded on empiricism and lean thinking. Lean thinking reduces waste and focuses on the essentials. Waterfall, Six Sigma, and critical path method are not identified as foundations of Scrum.
- How does lean thinking, as a foundation of Scrum, primarily contribute to the framework?
- It reduces waste and focuses on the essentials
- It mandates detailed upfront documentation
- It introduces fixed-scope contracts
- It requires comprehensive predictive estimation
Correct answer: It reduces waste and focuses on the essentials
Lean thinking contributes to Scrum by reducing waste and focusing on the essentials. This complements empiricism by keeping the team's attention on delivering value efficiently rather than producing unnecessary documentation, fixed-scope contracts, or exhaustive predictive estimates.
- In Scrum, which event acts as the container that holds all other Scrum events?
- Sprint Planning
- The Sprint
- The Daily Scrum
- The Sprint Review
Correct answer: The Sprint
The Sprint is the container event; all other events, Sprint Planning, the Daily Scrum, the Sprint Review, and the Sprint Retrospective, happen within it. A new Sprint starts immediately after the conclusion of the previous Sprint, with no gaps in between.
- What happens immediately after one Sprint concludes?
- A planning phase of several days occurs before the next Sprint
- A formal handoff to operations pauses all work
- A new Sprint starts immediately, with no gap between Sprints
- The team waits for stakeholder approval before starting again
Correct answer: A new Sprint starts immediately, with no gap between Sprints
A new Sprint starts immediately after the conclusion of the previous Sprint, with no gaps. Sprints are fixed-length events of one month or less that run back-to-back to create consistency and maintain the rhythm of empirical inspection and adaptation.
- What is the maximum length of a Sprint according to the Scrum Guide?
- Two months or less
- Six weeks or less
- Exactly four weeks
- One month or less
Correct answer: One month or less
A Sprint is timeboxed to one month or less. Shorter Sprints generate more learning cycles and limit risk to a smaller window of time and cost, but the upper bound defined by Scrum is one month.
- Why does Scrum recommend keeping Sprints short, such as one to four weeks?
- Shorter Sprints generate more learning cycles and limit cost and risk to a shorter time horizon
- Shorter Sprints eliminate the need for a Sprint Review
- Shorter Sprints allow the team to skip Sprint Planning
- Shorter Sprints remove the requirement for a Definition of Done
Correct answer: Shorter Sprints generate more learning cycles and limit cost and risk to a shorter time horizon
Shorter Sprints are favored because they generate more learning cycles and limit the risk of cost and effort to a smaller time frame. Regardless of Sprint length, Scrum still requires all events and a Definition of Done; short Sprints do not remove any of those.
- How are the consistency of Sprint length and the absence of gaps between Sprints connected to empiricism?
- A steady cadence eliminates the need to inspect the Increment
- A steady cadence creates regular opportunities to inspect and adapt, reinforcing empirical control
- A steady cadence guarantees the Sprint Goal is always met
- A steady cadence removes uncertainty from the work
Correct answer: A steady cadence creates regular opportunities to inspect and adapt, reinforcing empirical control
A consistent Sprint length with no gaps creates a reliable cadence of inspection and adaptation, which is the heart of empirical process control. It does not eliminate the need to inspect, guarantee goals, or remove the inherent uncertainty of complex work.
- What is the maximum timebox for Sprint Planning in a one-month Sprint?
- Four hours
- Two hours
- Eight hours
- Twelve hours
Correct answer: Eight hours
Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint, and is usually shorter for shorter Sprints. This is the event that initiates the Sprint by laying out the work to be performed.
- Sprint Planning addresses three topics. Which set correctly lists them?
- Who attends, when to meet, and where to work
- Which tools to use, what budget exists, and who approves
- What went well, what to improve, and what to start
- Why the Sprint is valuable, what can be done, and how the work will get done
Correct answer: Why the Sprint is valuable, what can be done, and how the work will get done
Sprint Planning addresses three topics: why the Sprint is valuable (which leads to the Sprint Goal), what can be Done this Sprint, and how the chosen work will get done. The last option describes a Retrospective, not Sprint Planning.
- During Sprint Planning, which topic produces the Sprint Goal?
- Why this Sprint is valuable
- How the work will be done
- Who will do the work
- When the work will be reviewed
Correct answer: Why this Sprint is valuable
The topic of why the Sprint is valuable produces the Sprint Goal, the single objective that gives the Sprint coherence. The how topic produces a plan for turning selected items into an Increment, while the what topic identifies which Product Backlog items are selected.
- What two outputs result from a successful Sprint Planning event?
- A Product Goal and a release plan
- A Sprint Goal and a Sprint Backlog
- A Definition of Done and a Product Backlog
- A burndown chart and a velocity figure
Correct answer: A Sprint Goal and a Sprint Backlog
Sprint Planning results in a Sprint Goal and a Sprint Backlog (the selected Product Backlog items plus a plan for delivering them). The Product Goal, Definition of Done, burndown charts, and velocity are not produced by Sprint Planning.
- Who is accountable for crafting the Sprint Goal during Sprint Planning?
- The Scrum Master alone defines the Sprint Goal
- A project manager outside the team sets the Sprint Goal
- The whole Scrum Team collaborates to craft the Sprint Goal
- The stakeholders dictate the Sprint Goal
Correct answer: The whole Scrum Team collaborates to craft the Sprint Goal
The Sprint Goal is crafted by the whole Scrum Team during Sprint Planning; it is a collaborative output, not something the Scrum Master, a project manager, or stakeholders impose. The team must finalize a Sprint Goal before Sprint Planning ends.
- What is the timebox for the Daily Scrum?
- Thirty minutes
- One hour
- Five minutes
- Fifteen minutes
Correct answer: Fifteen minutes
The Daily Scrum is a 15-minute event held each working day of the Sprint. Keeping it to 15 minutes preserves focus and encourages the Developers to plan efficiently for the next day of work toward the Sprint Goal.
- For whom is the Daily Scrum held, and who is accountable for it?
- The Developers, who own and run the event
- The Scrum Master, who reports status
- The Product Owner, who assigns tasks
- Stakeholders, who track progress
Correct answer: The Developers, who own and run the event
The Daily Scrum is for the Developers of the Scrum Team; they own and conduct it to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as needed. The Scrum Master ensures it happens but does not run it as a status report.
- What is the primary purpose of the Daily Scrum?
- To provide a status report to management
- To inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary
- To allow the Product Owner to reprioritize the Product Backlog
- To review the completed Increment with stakeholders
Correct answer: To inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary
The Daily Scrum's purpose is for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming plan of work. It is not a management status report, a backlog reprioritization, or a stakeholder review.
- If the Daily Scrum is held at the same time and place every day, what benefit does the Scrum Guide cite?
- It allows the event to be extended beyond fifteen minutes
- It transfers ownership of the event to the Scrum Master
- It reduces complexity by removing the need to coordinate scheduling each day
- It makes attendance optional for the Developers
Correct answer: It reduces complexity by removing the need to coordinate scheduling each day
Holding the Daily Scrum at the same time and place every working day reduces complexity, since the team does not have to negotiate logistics daily. It does not extend the timebox, change ownership from the Developers, or make participation optional.
- May Developers adjust their plan for the rest of the Sprint outside of the Daily Scrum?
- No, plans may only change during the Daily Scrum
- No, only the Scrum Master may change the plan
- Yes, but only with Product Owner approval
- Yes, Developers can meet and adapt the plan throughout the day as needed
Correct answer: Yes, Developers can meet and adapt the plan throughout the day as needed
The Daily Scrum is not the only time Developers may adjust their plan; they often meet throughout the day for more detailed discussions about adapting or replanning the rest of the Sprint's work. The Daily Scrum is one focused checkpoint, not a restriction on collaboration.
- What is the maximum timebox for the Sprint Review in a one-month Sprint?
- Four hours
- Eight hours
- Two hours
- Three hours
Correct answer: Four hours
The Sprint Review is timeboxed to a maximum of four hours for a one-month Sprint, and shorter for shorter Sprints. It is the second-to-last event of the Sprint, held before the Sprint Retrospective.
- What is the primary purpose of the Sprint Review?
- To hold the team accountable for missed commitments
- To inspect the outcome of the Sprint and determine future adaptations with stakeholders
- To finalize the Definition of Done
- To plan the tasks for the next Sprint
Correct answer: To inspect the outcome of the Sprint and determine future adaptations with stakeholders
The Sprint Review's purpose is to inspect the outcome of the Sprint and determine future adaptations, with the Scrum Team and stakeholders collaborating on what was accomplished and what to do next. It is not a blame session, a place to set the Definition of Done, or detailed next-Sprint task planning.
- Which statement best corrects the common misconception that the Sprint Review is merely a demo?
- It is a one-way presentation with no stakeholder input
- It is a sign-off meeting where the Product Owner approves each item
- It is a working session where the team and stakeholders inspect progress and collaborate on what to do next
- It is a status report delivered to management
Correct answer: It is a working session where the team and stakeholders inspect progress and collaborate on what to do next
The Sprint Review is a working session in which the Scrum Team presents results and collaborates with stakeholders on progress and next steps, adapting the Product Backlog as needed. Calling it just a demo, a one-way presentation, a sign-off, or a status report understates its collaborative, inspect-and-adapt nature.
- What is the maximum timebox for the Sprint Retrospective in a one-month Sprint?
- Four hours
- Eight hours
- One hour
- Three hours
Correct answer: Three hours
The Sprint Retrospective is timeboxed to a maximum of three hours for a one-month Sprint and is shorter for shorter Sprints. It is the final event of the Sprint, concluding it before the next Sprint begins.
- What is the main purpose of the Sprint Retrospective?
- To plan ways to increase quality and effectiveness as a team
- To inspect the Increment with stakeholders
- To create the Sprint Backlog for the next Sprint
- To order the Product Backlog
Correct answer: To plan ways to increase quality and effectiveness as a team
The Sprint Retrospective's purpose is for the Scrum Team to inspect how the last Sprint went regarding individuals, interactions, processes, tools, and the Definition of Done, and to plan ways to increase quality and effectiveness. Inspecting the Increment is the Sprint Review's job, not the Retrospective's.
- Which event concludes the Sprint?
- The Sprint Review
- The Sprint Retrospective
- Sprint Planning
- The Daily Scrum
Correct answer: The Sprint Retrospective
The Sprint Retrospective concludes the Sprint. The order of events within a Sprint is Sprint Planning, then daily Daily Scrums, then the Sprint Review, and finally the Sprint Retrospective, after which the next Sprint begins immediately.
- During the Sprint Retrospective, the team examines its tools, processes, interactions, and which artifact-related agreement?
- The Product Goal
- The release date
- The Definition of Done
- The team's budget
Correct answer: The Definition of Done
In the Sprint Retrospective the Scrum Team inspects how the Sprint went regarding individuals, interactions, processes, tools, and its Definition of Done. The Product Goal, release dates, and budgets are not the focus of the Retrospective's inspect-and-adapt agenda.
- How many events does the Scrum framework define, and what are they?
- Four: Sprint Planning, the Daily Scrum, the Sprint Review, and the Sprint Retrospective
- Three: Sprint Planning, the Daily Scrum, and the Sprint Review
- Six: including Backlog Refinement as a formal event
- Five: the Sprint, Sprint Planning, the Daily Scrum, the Sprint Review, and the Sprint Retrospective
Correct answer: Five: the Sprint, Sprint Planning, the Daily Scrum, the Sprint Review, and the Sprint Retrospective
Scrum defines five events: the Sprint, which contains the other four, Sprint Planning, the Daily Scrum, the Sprint Review, and the Sprint Retrospective. Product Backlog refinement is an ongoing activity, not a fifth or sixth formal event.
- Why does Scrum prescribe a fixed set of events rather than allowing ad hoc meetings?
- The prescribed events create regularity and reduce the need for meetings not defined in Scrum
- The events replace all other forms of team communication permanently
- The events guarantee that every Sprint Goal is achieved
- The events transfer decision-making to managers
Correct answer: The prescribed events create regularity and reduce the need for meetings not defined in Scrum
Scrum's prescribed events create regularity and minimize the need for meetings not defined in Scrum, each serving as a formal opportunity to inspect and adapt. They do not forbid other useful collaboration, guarantee goal achievement, or move decisions to managers.
- Which of the following is NOT one of the five Scrum events?
- The Sprint
- Product Backlog Refinement
- The Sprint Review
- The Daily Scrum
Correct answer: Product Backlog Refinement
Product Backlog refinement is an ongoing activity throughout the Sprint, not one of the five formal Scrum events. The five events are the Sprint, Sprint Planning, the Daily Scrum, the Sprint Review, and the Sprint Retrospective.
- What are the three artifacts defined by Scrum?
- The Product Goal, the Sprint Goal, and the Definition of Done
- The Sprint, the Daily Scrum, and the Sprint Review
- The Product Backlog, the Sprint Backlog, and the Increment
- The Scrum Master, the Product Owner, and the Developers
Correct answer: The Product Backlog, the Sprint Backlog, and the Increment
Scrum's three artifacts are the Product Backlog, the Sprint Backlog, and the Increment. The Product Goal, Sprint Goal, and Definition of Done are the commitments attached to those artifacts, not the artifacts themselves.
- Each Scrum artifact contains a commitment to reinforce empiricism and the Scrum values. Which pairing is correct?
- The Sprint Backlog's commitment is the Definition of Done
- The Increment's commitment is the Sprint Goal
- The Product Backlog's commitment is the Definition of Done
- The Product Backlog's commitment is the Product Goal
Correct answer: The Product Backlog's commitment is the Product Goal
The Product Backlog is committed to the Product Goal, the Sprint Backlog to the Sprint Goal, and the Increment to the Definition of Done. The incorrect options swap these pairings; matching artifact to commitment is a core PSM I point.
- Why do the artifact commitments exist in Scrum?
- They enhance transparency and focus against which progress can be measured
- They serve as contracts that bind the team legally
- They allow management to track individual performance
- They replace the need for the Scrum events
Correct answer: They enhance transparency and focus against which progress can be measured
The commitments, the Product Goal, Sprint Goal, and Definition of Done, exist to enhance transparency and focus, providing something against which progress can be measured. They are not legal contracts, performance-tracking tools, or substitutes for the Scrum events.
- What is the Product Backlog?
- A fixed contract of all requirements approved at project start
- An emergent, ordered list of what is needed to improve the product
- A list of tasks assigned to individual Developers
- A record of defects found during testing only
Correct answer: An emergent, ordered list of what is needed to improve the product
The Product Backlog is an emergent, ordered list of what is needed to improve the product; it is the single source of work undertaken by the Scrum Team. It is never a frozen contract, a per-person task list, or merely a defect log.
- Which statement best describes the ordering of the Product Backlog?
- It is grouped by team member with no overall order
- It is ordered alphabetically by feature name
- It is a single, ordered list, and the higher an item, the sooner it is likely worked on
- It is reordered only once per release
Correct answer: It is a single, ordered list, and the higher an item, the sooner it is likely worked on
The Product Backlog is a single, ordered list; items nearer the top are clearer and more detailed and are likely to be worked on sooner. It is not grouped per person, ordered alphabetically, or reordered only at release boundaries; it evolves continuously.
- Why is the Product Backlog described as emergent rather than fixed?
- It is finalized at the start and cannot change
- It only grows and never has items removed
- It is replaced entirely each Sprint
- It continuously changes to reflect new learning about the product and its environment
Correct answer: It continuously changes to reflect new learning about the product and its environment
The Product Backlog is emergent because it continuously changes to identify what the product needs to be more useful and competitive as the team learns. It is neither fixed at the start, append-only, nor wholly replaced each Sprint.
- How many Product Backlogs should a single product have in Scrum?
- One Product Backlog for the product
- One Product Backlog per Developer
- One Product Backlog per Sprint
- Several Product Backlogs, one per stakeholder group
Correct answer: One Product Backlog for the product
A product has a single Product Backlog, which is the one ordered source of work for the Scrum Team. There is not a separate backlog per Developer, per Sprint, or per stakeholder group; the single backlog preserves transparency about all upcoming work.
- What is the Sprint Backlog composed of?
- Only the list of selected Product Backlog items
- The Sprint Goal, the selected Product Backlog items, and a plan for delivering them
- Only the tasks the Scrum Master assigns
- The Product Goal and the Definition of Done
Correct answer: The Sprint Goal, the selected Product Backlog items, and a plan for delivering them
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). It is more than just a task list and is not assembled by the Scrum Master assigning work.
- For whom is the Sprint Backlog a plan, and who can update it during the Sprint?
- It is a plan owned by the Product Owner, who updates it
- It is a plan owned by the Scrum Master, who updates it
- It is a plan by and for the Developers, who update it throughout the Sprint
- It is a plan owned by stakeholders, who update it
Correct answer: It is a plan by and for the Developers, who update it throughout the Sprint
The Sprint Backlog is a plan by and for the Developers; they own it and update it throughout the Sprint as they learn more. The Product Owner, Scrum Master, and stakeholders do not control or update the Developers' Sprint Backlog.
- As new work is required to reach the Sprint Goal, what do the Developers do with the Sprint Backlog?
- They wait until the next Sprint to record it
- They ask the Product Owner to add it to the Product Backlog instead
- They leave the Sprint Backlog unchanged until Sprint Review
- They add it to the Sprint Backlog, keeping it current as more is learned
Correct answer: They add it to the Sprint Backlog, keeping it current as more is learned
The Developers add newly identified work to the Sprint Backlog as needed to meet the Sprint Goal, keeping the plan current as more is learned. The Sprint Backlog is updated throughout the Sprint, not frozen until the Review or deferred to the next Sprint.
- What is the Increment in Scrum?
- A concrete stepping stone toward the Product Goal that is usable and adds to prior Increments
- A document describing planned features
- A summary report presented at the Sprint Review
- The list of remaining Product Backlog items
Correct answer: A concrete stepping stone toward the Product Goal that is usable and adds to prior Increments
An Increment is a concrete stepping stone toward the Product Goal; each Increment is additive to all prior Increments, verified to work together, and usable. It is not a plan document, a status report, or the remaining backlog.
- When is a piece of work formally considered part of an Increment?
- When the Developers finish coding it
- When it meets the Definition of Done
- When it is demonstrated at the Sprint Review
- When the Product Owner verbally approves it
Correct answer: When it meets the Definition of Done
Work is part of an Increment only when it meets the Definition of Done. Finishing coding, demonstrating it, or receiving verbal approval is insufficient on its own; the Definition of Done is the quality bar that determines whether work counts as a usable Increment.
- Can multiple Increments be created within a single Sprint?
- No, exactly one Increment is allowed per Sprint
- No, Increments can only be created during Sprint Review
- Yes, multiple Increments may be created within a Sprint
- Yes, but only if the Sprint is one month long
Correct answer: Yes, multiple Increments may be created within a Sprint
Multiple Increments may be created within a single Sprint, and the sum of the Increments is presented at the Sprint Review. Scrum does not limit a Sprint to exactly one Increment, nor restrict Increment creation to the Sprint Review.
- Must an Increment be released to be valuable, according to Scrum?
- Yes, an Increment is only valid once released to production
- No, but it can never be released during a Sprint
- Yes, and only the Scrum Master may approve its release
- No, an Increment may be delivered to stakeholders before the Sprint ends, but releasing is not required for it to count
Correct answer: No, an Increment may be delivered to stakeholders before the Sprint ends, but releasing is not required for it to count
An Increment can be delivered before the Sprint ends, but the Sprint Review should never be considered a gate to releasing value, and releasing is not required for work to qualify as a Done Increment. A Done Increment is usable whether or not the team decides to release it.
- What is the Product Goal in Scrum?
- The commitment for the Product Backlog describing a future state of the product
- A list of tasks for the current Sprint
- The maximum timebox of a Sprint
- A measure of how fast the team delivers
Correct answer: The commitment for the Product Backlog describing a future state of the product
The Product Goal is the commitment for the Product Backlog; it describes a future state of the product and serves as a long-term objective the Scrum Team plans against. It is not a Sprint task list, a timebox, or a velocity metric.
- How many Product Goals can a Scrum Team pursue at the same time?
- Several Product Goals concurrently, one per Sprint
- One Product Goal at a time; the team must fulfill or abandon it before taking on the next
- One Product Goal per Developer
- An unlimited number simultaneously
Correct answer: One Product Goal at a time; the team must fulfill or abandon it before taking on the next
A Scrum Team works toward one Product Goal at a time; it must fulfill (or abandon) one objective before taking on the next. The Product Goal provides a single long-term target that the entire team plans against.
- What relationship does the Product Goal have to the Product Backlog?
- The Product Goal is a single Product Backlog item near the bottom
- The Product Goal replaces the Product Backlog once set
- The Product Backlog emerges to define what will fulfill the Product Goal
- The Product Goal is unrelated to the Product Backlog
Correct answer: The Product Backlog emerges to define what will fulfill the Product Goal
The Product Goal is the long-term objective in the Product Backlog, and the Product Backlog emerges to define what will fulfill that goal. The Product Goal is the commitment for the Product Backlog, not a low-priority item, a replacement for the backlog, or unrelated to it.
- What is a Sprint Goal?
- A detailed list of all tasks to complete in the Sprint
- The same thing as the Definition of Done
- A long-term objective spanning many Sprints
- The single objective for the Sprint that provides coherence and focus
Correct answer: The single objective for the Sprint that provides coherence and focus
The Sprint Goal is the single objective for the Sprint; it provides coherence and focus, encouraging the team to work together rather than on separate initiatives. It is not a task list, the Definition of Done, or a long-term multi-Sprint objective (that is the Product Goal).
- How many Sprint Goals does a Sprint have?
- One Sprint Goal
- One per Developer
- One per Product Backlog item selected
- As many as the team wishes
Correct answer: One Sprint Goal
A Sprint has a single Sprint Goal. It is the one objective that gives the Sprint coherence and focus; having one shared goal helps the Developers collaborate rather than pursue separate, unrelated tasks.
- Once the Sprint begins, can the Sprint Goal itself be changed?
- Yes, the Developers may change it at any Daily Scrum
- No, the Sprint Goal remains fixed; only the scope may be renegotiated with the Product Owner as more is learned
- Yes, stakeholders may replace it at the Sprint Review
- No, and the scope also cannot change at all
Correct answer: No, the Sprint Goal remains fixed; only the scope may be renegotiated with the Product Owner as more is learned
The Sprint Goal does not change once the Sprint starts, but as the Developers learn more, the scope may be clarified and renegotiated with the Product Owner without abandoning the Sprint Goal. The goal stays fixed while the scope can flex.
- Which artifact does the Sprint Goal serve as the commitment for?
- The Product Backlog
- The Increment
- The Sprint Backlog
- The Definition of Done
Correct answer: The Sprint Backlog
The Sprint Goal is the commitment for the Sprint Backlog. The Product Goal is the commitment for the Product Backlog, and the Definition of Done is the commitment for the Increment; the Definition of Done is itself a commitment, not an artifact.
- What is the Definition of Done?
- A list of acceptance criteria for a single Product Backlog item
- The team's estimate of how much work it can finish
- A schedule of release dates
- A formal description of the state the Increment must meet to be of the required quality
Correct answer: A formal description of the state the Increment must meet to be of the required quality
The Definition of Done is a formal description of the state the Increment must reach to meet the required quality measures for the product. It applies to the Increment as a whole, distinct from per-item acceptance criteria, capacity estimates, or release schedules.
- Why does the Definition of Done create transparency?
- Everyone shares a common understanding of what work is completed as part of the Increment
- It shows management who finished their tasks
- It lists the team's velocity for the Sprint
- It records how many meetings occurred
Correct answer: Everyone shares a common understanding of what work is completed as part of the Increment
The Definition of Done creates transparency by giving everyone a shared understanding of what work is actually completed as part of the Increment. This shared standard is what makes the Increment's quality visible, which is the basis for inspection and adaptation.
- If a Product Backlog item does not meet the Definition of Done, what should happen?
- It can still be released because it is mostly complete
- It cannot be released or even presented as Done; it returns to the Product Backlog
- It is added to the Increment and fixed later automatically
- It is marked Done with a note about the gaps
Correct answer: It cannot be released or even presented as Done; it returns to the Product Backlog
If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review as Done; it returns to the Product Backlog for future consideration. Partially complete work is never counted as a Done Increment.
- When an organization already has a product-wide standard for Done, how does the Scrum Team's Definition of Done relate to it?
- The Scrum Team may ignore the organizational standard
- The organizational standard replaces the need for a team Definition of Done entirely
- The Scrum Team must meet that standard as a minimum and may add stricter criteria
- The Scrum Team applies a weaker standard than the organization
Correct answer: The Scrum Team must meet that standard as a minimum and may add stricter criteria
If a Definition of Done is an organizational standard, all Scrum Teams must follow it as a minimum; if no organizational standard exists, the Scrum Team creates one appropriate for the product. Teams may make it stricter but never weaker than the organizational baseline.
- Who is accountable for establishing Scrum as defined in the Scrum Guide within the team and organization?
- The Product Owner
- The Developers
- A project manager
- The Scrum Master
Correct answer: The Scrum Master
The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide and for the Scrum Team's effectiveness. This includes helping everyone understand Scrum theory and practice both within the team and across the organization.
- How does the Scrum Guide describe the Scrum Master's form of leadership?
- A true leader who serves the Scrum Team and the larger organization
- A command-and-control manager who assigns tasks
- An administrative coordinator with no leadership role
- A technical lead who designs the solution
Correct answer: A true leader who serves the Scrum Team and the larger organization
The Scrum Master is described as a true leader who serves the Scrum Team and the larger organization. This service-oriented leadership stands in contrast to command-and-control management; the Scrum Master leads by enabling others, not by assigning and directing work.
- Which of the following is a Scrum Master service to the Scrum Team?
- Ordering the Product Backlog on behalf of the Product Owner
- Helping the team focus on creating high-value Increments that meet the Definition of Done
- Writing all the code in the Increment
- Approving the Increment for release
Correct answer: Helping the team focus on creating high-value Increments that meet the Definition of Done
A core Scrum Master service is helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done. Ordering the Product Backlog is the Product Owner's accountability, and writing code or approving releases is not the Scrum Master's defined service.
- The Scrum Master serves the organization in several ways. Which is one of them?
- Setting individual performance targets for Developers
- Approving budgets for the product
- Helping employees and stakeholders understand and enact an empirical approach for complex work
- Assigning Product Backlog items to team members
Correct answer: Helping employees and stakeholders understand and enact an empirical approach for complex work
The Scrum Master serves the organization by helping employees and stakeholders understand and enact an empirical approach for complex work, and by leading and coaching the adoption of Scrum. Setting performance targets, approving budgets, and assigning backlog items are not Scrum Master services.
- How does the Scrum Master serve the Product Owner?
- By taking over ordering the Product Backlog permanently
- By approving which items are valuable
- By writing the Product Backlog items themselves
- By helping find techniques for effective Product Goal definition and Product Backlog management
Correct answer: By helping find techniques for effective Product Goal definition and Product Backlog management
The Scrum Master serves the Product Owner by helping find techniques for effective Product Goal definition and Product Backlog management, and by facilitating stakeholder collaboration. The Scrum Master assists the Product Owner rather than taking over the Product Owner's accountabilities.
- Is the Scrum Master accountable for the team's adherence to Scrum even though they do not manage the team's work?
- Yes, the Scrum Master is accountable for the team's effectiveness and for the Scrum process being followed
- No, the Product Owner is accountable for Scrum adherence
- No, adherence is solely each Developer's responsibility
- Yes, and the Scrum Master also directs all task assignments
Correct answer: Yes, the Scrum Master is accountable for the team's effectiveness and for the Scrum process being followed
The Scrum Master is accountable for the Scrum Team's effectiveness and for ensuring Scrum is understood and enacted, without managing the Developers' day-to-day work. They hold accountability for the process while the team self-manages its work, not by directing task assignments.
- What are the three accountabilities within a Scrum Team?
- The Project Manager, the Team Lead, and the Architect
- The Product Owner, the Scrum Master, and the Developers
- The Scrum Master, the Tester, and the Analyst
- The Product Owner, the Stakeholders, and the Customers
Correct answer: The Product Owner, the Scrum Master, and the Developers
The Scrum Team consists of three accountabilities: one Product Owner, one Scrum Master, and Developers. The 2020 Scrum Guide uses accountabilities rather than roles, and there are no sub-teams or hierarchies within the Scrum Team.
- Why does the 2020 Scrum Guide describe these as accountabilities rather than roles?
- To indicate that anyone can ignore them
- To reduce the Scrum Team to a single person
- To emphasize that each represents a set of responsibilities held by people in one cohesive team, not job titles or sub-teams
- To signal that the team needs managers above it
Correct answer: To emphasize that each represents a set of responsibilities held by people in one cohesive team, not job titles or sub-teams
The 2020 Guide uses accountabilities to stress that the Product Owner, Scrum Master, and Developers represent responsibilities within one cohesive unit, with no sub-teams or hierarchies, rather than formal job titles. It does not imply they are optional, collapse the team to one person, or require external managers.
- What happens to a Product Backlog item that the Developers do not complete by the end of a Sprint?
- It is automatically carried into the next Sprint Backlog unchanged
- It is deleted because it failed
- It is marked Done with the unfinished portion noted
- It returns to the Product Backlog and is re-estimated for future consideration
Correct answer: It returns to the Product Backlog and is re-estimated for future consideration
Work that does not meet the Definition of Done by Sprint end returns to the Product Backlog, where it is re-estimated based on what was learned and considered for the future. It is not automatically carried over, deleted, or counted as partially Done.
- Is incomplete work at the end of a Sprint considered a failure of the Sprint?
- No, the Sprint still produced a Done Increment of completed items; unfinished work simply returns to the Product Backlog
- Yes, any incomplete item means the Sprint failed entirely
- Yes, and the Increment must be discarded
- No, but the team must extend the Sprint to finish
Correct answer: No, the Sprint still produced a Done Increment of completed items; unfinished work simply returns to the Product Backlog
A Sprint is not a failure merely because some items were not finished; completed work that meets the Definition of Done forms a usable Increment, and unfinished items return to the Product Backlog. Sprints are never extended, and the Increment is not discarded because of unfinished items.
- How does a weak or incomplete Definition of Done relate to technical debt?
- A weak Definition of Done eliminates technical debt automatically
- A weak Definition of Done lets undone work and hidden defects accumulate as technical debt
- Technical debt is unrelated to the Definition of Done
- A strong Definition of Done increases technical debt
Correct answer: A weak Definition of Done lets undone work and hidden defects accumulate as technical debt
A weak Definition of Done allows incomplete or low-quality work to be declared Done, so undone work and hidden defects accumulate as technical debt. A strong Definition of Done is what guards against this by making the true state of the Increment transparent.
- Why does technical debt undermine transparency of the Increment?
- It makes the Product Backlog longer
- It forces the Sprint to be canceled
- It hides the true amount of remaining work, making the Increment appear more complete than it is
- It removes the need for a Sprint Review
Correct answer: It hides the true amount of remaining work, making the Increment appear more complete than it is
Technical debt undermines transparency because it conceals remaining work and quality problems, making the Increment look more finished than it really is and distorting the basis for inspection and adaptation. It does not cancel Sprints or remove the Sprint Review.
- A Scrum Team consistently declares items Done that still require rework before release. Which Scrum concept is being violated, leading to accumulating technical debt?
- The Sprint timebox
- The Daily Scrum cadence
- The Product Goal
- The integrity of the Definition of Done
Correct answer: The integrity of the Definition of Done
Declaring items Done when they still need rework violates the integrity of the Definition of Done, which is the quality commitment for the Increment. Allowing this erodes transparency and accumulates technical debt; the Sprint timebox, Daily Scrum cadence, and Product Goal are not the concepts being violated here.
- Which Scrum value supports being open about the work and the challenges the team faces?
- Openness
- Focus
- Commitment
- Courage
Correct answer: Openness
Openness is the value of being open about the work and the challenges of doing it. Focus concerns concentrating on the Sprint's work, commitment concerns dedication to goals, and courage concerns tackling tough problems and doing the right thing.
- Which Scrum value calls for treating team members as capable, independent people deserving of regard?
- Focus
- Respect
- Commitment
- Openness
Correct answer: Respect
Respect is the value of regarding Scrum Team members as capable, independent people, and being respected as such by those they work with. It is distinct from focus, commitment, and openness, each of which addresses a different aspect of how the team works together.
- How do the Scrum values relate to the empirical pillars of transparency, inspection, and adaptation?
- The values replace the pillars
- The values only apply during the Sprint Retrospective
- When embodied by the team, the values bring the pillars of empiricism to life and build trust
- The values are optional and unrelated to empiricism
Correct answer: When embodied by the team, the values bring the pillars of empiricism to life and build trust
When the Scrum values are embodied by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust. The values are not a replacement for the pillars, are not limited to the Retrospective, and are integral to empiricism rather than optional.
- What is the primary reason Scrum relies on an empirical approach rather than a fully predictive one?
- Empirical approaches require less skill from the team
- Predictive approaches are forbidden by the Scrum Guide for all work
- Empirical approaches remove the need for any planning
- The work Scrum addresses is complex, so future outcomes cannot be reliably predicted in advance
Correct answer: The work Scrum addresses is complex, so future outcomes cannot be reliably predicted in advance
Scrum uses an empirical approach because it tackles complex problems where outcomes cannot be reliably predicted, so the team optimizes through frequent inspection and adaptation. Empiricism is not about requiring less skill or eliminating planning, and predictive methods are appropriate for simpler, well-understood work.
- In the empirical model, what role does frequent delivery of a Done Increment play?
- It provides a real, inspectable result that grounds inspection and adaptation in actual outcomes
- It guarantees the Product Goal is reached by the next Sprint
- It replaces the need for the Sprint Review
- It is optional and only done at release time
Correct answer: It provides a real, inspectable result that grounds inspection and adaptation in actual outcomes
Frequently producing a Done Increment provides a tangible, inspectable result that grounds the team's inspection and adaptation in actual outcomes rather than assumptions. It does not guarantee the Product Goal is met soon, replace the Sprint Review, or only occur at release.
- Which statement about the three pillars is most accurate?
- Only transparency is required for empiricism to function
- All three pillars must be present together; inspection without transparency, or without acting on findings, weakens empiricism
- Adaptation can substitute for both transparency and inspection
- Inspection alone is sufficient for empirical control
Correct answer: All three pillars must be present together; inspection without transparency, or without acting on findings, weakens empiricism
All three pillars, transparency, inspection, and adaptation, must work together. Inspecting an opaque situation, or inspecting without then adapting, undermines empirical control. No single pillar is sufficient on its own; each depends on the others.
- When a Scrum Team finds during inspection that it has deviated outside acceptable limits, what does adaptation require?
- Waiting until the next Sprint Planning to act
- Ignoring the deviation until the Sprint Review
- Adjusting the process or the work as soon as possible to minimize further deviation
- Cancelling the Sprint automatically
Correct answer: Adjusting the process or the work as soon as possible to minimize further deviation
Adaptation requires adjusting the process or the materials being worked on as soon as possible to minimize further deviation when inspection reveals the team is heading outside acceptable limits. Delaying until later events or cancelling the Sprint is not what adaptation calls for.
- What is the relationship between the Sprint and the other four Scrum events?
- The Sprint takes place within the Sprint Review
- The events are independent of the Sprint
- Only Sprint Planning occurs within the Sprint
- The other four events take place within the Sprint
Correct answer: The other four events take place within the Sprint
The Sprint is a container in which Sprint Planning, the Daily Scrum, the Sprint Review, and the Sprint Retrospective all take place. The other events do not occur outside the Sprint, and the Sprint is not contained within any other event.
- During a Sprint, which of the following is true about quality and the Product Goal?
- Quality does not decrease, and scope may be clarified and renegotiated with the Product Owner as more is learned
- Quality may be lowered to fit the timebox
- The Product Goal must change each Sprint
- No changes that endanger the Sprint Goal may be allowed, but quality may drop
Correct answer: Quality does not decrease, and scope may be clarified and renegotiated with the Product Owner as more is learned
During a Sprint, quality does not decrease, while scope may be clarified and renegotiated with the Product Owner as more is learned. The Definition of Done protects quality, so lowering it to hit a deadline is not permitted, and the Product Goal is a long-term objective not required to change each Sprint.
- Which statement correctly orders the events within a Sprint?
- Sprint Review, Sprint Planning, Daily Scrum, Sprint Retrospective
- Sprint Planning, then daily Daily Scrums, then the Sprint Review, then the Sprint Retrospective
- Sprint Retrospective, Sprint Planning, Sprint Review, Daily Scrum
- Daily Scrum, Sprint Planning, Sprint Retrospective, Sprint Review
Correct answer: Sprint Planning, then daily Daily Scrums, then the Sprint Review, then the Sprint Retrospective
Within a Sprint the order is Sprint Planning first, then a Daily Scrum each working day, then the Sprint Review, and finally the Sprint Retrospective. The other orderings misplace the planning, review, or retrospective relative to the Sprint's structure.
- Why is Sprint Planning timeboxed rather than allowed to run as long as needed?
- An open-ended plan guarantees a better outcome
- Timeboxing transfers planning to the Scrum Master
- A timebox keeps planning efficient and prevents over-planning before empirical work begins
- Timeboxing removes the need for a Sprint Goal
Correct answer: A timebox keeps planning efficient and prevents over-planning before empirical work begins
Sprint Planning is timeboxed to keep planning efficient and avoid excessive upfront planning, since detailed predictions about complex work add little value before the team starts learning empirically. The timebox does not transfer planning ownership or remove the requirement for a Sprint Goal.
- In the how topic of Sprint Planning, what do the Developers primarily do?
- Decide which Product Backlog items are most valuable
- Set the long-term Product Goal
- Approve the release of the Increment
- Decompose selected items into smaller work and plan how to deliver a Done Increment
Correct answer: Decompose selected items into smaller work and plan how to deliver a Done Increment
In the how topic, the Developers decompose the selected Product Backlog items into smaller pieces of work and plan how they will deliver a Done Increment that meets the Definition of Done. Choosing valuable items and setting the Product Goal involve the Product Owner, and releasing is not part of this topic.
- Who participates in crafting the Sprint Goal, selecting items, and planning the work during Sprint Planning?
- The entire Scrum Team, which may invite others for advice
- Only the Developers
- Only the Product Owner and Scrum Master
- Only stakeholders and management
Correct answer: The entire Scrum Team, which may invite others for advice
The entire Scrum Team participates in Sprint Planning and may invite other people to provide advice. The event is collaborative across the whole team rather than restricted to the Developers, to the Product Owner and Scrum Master, or to outside stakeholders.
- If the Developers realize during the Daily Scrum that they will not meet the Sprint Goal at the current pace, what is the appropriate response?
- Cancel the Sprint immediately
- Adapt the Sprint Backlog and replan the remaining work toward the Sprint Goal
- Extend the Sprint to add more time
- Wait until the Sprint Review to raise it
Correct answer: Adapt the Sprint Backlog and replan the remaining work toward the Sprint Goal
When the Daily Scrum reveals the team may miss the Sprint Goal, the Developers adapt their plan by updating the Sprint Backlog and replanning the remaining work. Sprints are never extended, only the Product Owner can cancel a Sprint, and waiting until the Review would forfeit the chance to adapt.
- Does Scrum require the Daily Scrum to follow a specific three-question format?
- Yes, the three-question format is mandatory
- Yes, but only the Scrum Master may ask the questions
- No, the Developers may choose any structure or technique as long as it focuses on progress toward the Sprint Goal
- No, but the Product Owner must lead the discussion
Correct answer: No, the Developers may choose any structure or technique as long as it focuses on progress toward the Sprint Goal
The 2020 Scrum Guide does not prescribe a specific structure for the Daily Scrum; the Developers can select whatever technique or format they like, provided it focuses on progress toward the Sprint Goal and produces an actionable plan. The three-question format is a common option, not a requirement.
- How often is the Daily Scrum held?
- Once at the start of each Sprint
- Only when the team encounters a problem
- Once per week
- Every working day of the Sprint
Correct answer: Every working day of the Sprint
The Daily Scrum is held every working day of the Sprint, providing a regular checkpoint for the Developers to inspect progress and adapt the plan. It is not a one-time, problem-triggered, or weekly event.
- At the Sprint Review, what is the main subject the Scrum Team and stakeholders inspect?
- The Increment and progress toward the Product Goal
- The team's personal interactions and processes
- The detailed plan for the next Sprint's tasks
- The Scrum Master's effectiveness
Correct answer: The Increment and progress toward the Product Goal
At the Sprint Review the Scrum Team and stakeholders inspect what was accomplished in the Sprint, namely the Increment, and discuss progress toward the Product Goal. Inspecting team interactions and processes is the Retrospective's focus, and detailed next-Sprint planning happens in Sprint Planning.
- What is a likely outcome of the collaboration at the Sprint Review?
- The Sprint Goal for the just-completed Sprint is rewritten
- The Product Backlog is adjusted to reflect new opportunities and changing conditions
- The Definition of Done is formally signed by stakeholders
- The Sprint is extended to finish remaining items
Correct answer: The Product Backlog is adjusted to reflect new opportunities and changing conditions
A likely outcome of the Sprint Review is that the Product Backlog is adapted based on the collaboration about what to do next, given new opportunities and changing conditions. The completed Sprint's goal is not rewritten, the Definition of Done is not signed off here, and Sprints are never extended.
- After identifying improvements in the Sprint Retrospective, what does the team typically do with the most impactful ones?
- It records them in the Product Goal
- It waits a quarter before implementing any of them
- It may add them to the Sprint Backlog of the next Sprint to ensure they are acted on
- It assigns them all to the Scrum Master to fix alone
Correct answer: It may add them to the Sprint Backlog of the next Sprint to ensure they are acted on
The Scrum Team may add the most helpful improvements identified in the Retrospective to the next Sprint's Sprint Backlog so they are addressed. Improvements are not stored in the Product Goal, deferred for a quarter, or made the Scrum Master's sole responsibility.
- Which best distinguishes the Sprint Review from the Sprint Retrospective?
- Both events inspect only the product
- Both events inspect only the team
- The Review inspects the team; the Retrospective inspects the product
- The Sprint Review inspects the product and outcome; the Retrospective inspects how the team works
Correct answer: The Sprint Review inspects the product and outcome; the Retrospective inspects how the team works
The Sprint Review inspects the product Increment and the outcome of the Sprint with stakeholders, while the Sprint Retrospective inspects how the Scrum Team works, its people, interactions, processes, tools, and Definition of Done. They examine different subjects, not the same one.
- Which artifact serves as the single source of work for the Scrum Team?
- The Product Backlog
- The Sprint Backlog
- The Increment
- The Definition of Done
Correct answer: The Product Backlog
The Product Backlog is the single source of work undertaken by the Scrum Team. The Sprint Backlog is the subset selected for the current Sprint plus a plan, the Increment is the result of completed work, and the Definition of Done is a quality commitment, not a source of work.
- Which artifact is created entirely within a single Sprint and discarded conceptually when that Sprint ends?
- The Product Backlog
- The Sprint Backlog
- The Product Goal
- The Definition of Done
Correct answer: The Sprint Backlog
The Sprint Backlog is the plan created during Sprint Planning for a single Sprint; it pertains only to that Sprint. The Product Backlog persists across Sprints, the Product Goal is a long-term objective, and the Definition of Done is an ongoing quality standard.
- Which artifact provides transparency about the work the Developers have planned for the current Sprint?
- The Product Backlog
- The Increment
- The Sprint Backlog
- The Product Goal
Correct answer: The Sprint Backlog
The Sprint Backlog makes the Developers' plan for the current Sprint transparent, showing the Sprint Goal, the selected items, and how they intend to deliver the Increment. The Product Backlog covers all future work, the Increment is the result, and the Product Goal is a long-term target.
- How does Scrum describe the management of the Product Backlog over time?
- It is locked after the first Sprint
- It is recreated from scratch each Sprint
- It is managed solely by the Developers
- It is continuously refined and reordered as the product and environment evolve
Correct answer: It is continuously refined and reordered as the product and environment evolve
The Product Backlog is continuously refined and reordered as the product and its environment evolve, remaining an emergent artifact. It is not locked after the first Sprint, recreated each Sprint, or managed solely by the Developers; its content is the Product Owner's accountability.
- What does it mean that the Increment is additive?
- Each new Increment builds on and works together with all prior Increments
- Each Increment replaces the previous one entirely
- Increments are stored separately and never combined
- Only the final Increment of a release matters
Correct answer: Each new Increment builds on and works together with all prior Increments
The Increment being additive means each new Increment is added to all prior Increments and thoroughly verified to ensure they work together, forming a continually growing, usable product. Increments are not replacements, isolated pieces, or relevant only at the end.
- Which artifact-commitment pairing reflects the Product Backlog?
- Product Backlog with the Sprint Goal
- Product Backlog with the Product Goal
- Product Backlog with the Definition of Done
- Product Backlog with the Increment
Correct answer: Product Backlog with the Product Goal
The Product Backlog's commitment is the Product Goal. The Sprint Goal is paired with the Sprint Backlog, and the Definition of Done is paired with the Increment; the Increment is itself an artifact, not a commitment.
- How does the Sprint Goal create flexibility within the Sprint?
- It fixes every task so nothing can change
- It lets the team change the objective whenever convenient
- It is a single objective that allows the exact scope to flex as long as the objective is met
- It is decided after the Increment is built
Correct answer: It is a single objective that allows the exact scope to flex as long as the objective is met
The Sprint Goal provides a single objective so that the exact work and scope can be renegotiated with the Product Owner as the team learns, as long as the objective is still pursued. The goal itself does not change mid-Sprint, and it is set during Sprint Planning, not after the Increment is built.
- A Done Increment that meets the Definition of Done but is not yet released still provides what?
- No value until it is released
- A reason to cancel the Sprint
- A replacement for the Sprint Review
- A transparent, usable result that can be inspected and released whenever the Product Owner decides
Correct answer: A transparent, usable result that can be inspected and released whenever the Product Owner decides
A Done Increment is usable and transparent, available to be inspected and released whenever the Product Owner decides; value is not contingent on immediate release. It does not lack value before release, trigger Sprint cancellation, or replace the Sprint Review.
- Which scenario correctly shows the Definition of Done acting as the Increment's quality commitment?
- The team only declares items Done once they meet every criterion in the shared Definition of Done
- Each Developer applies their own personal quality standard
- Done is decided item by item with no shared standard
- The Product Owner declares items Done based on appearance
Correct answer: The team only declares items Done once they meet every criterion in the shared Definition of Done
The Definition of Done is a shared commitment, so items are declared Done only when they meet every criterion in the team's single Definition of Done. Individual standards, ad hoc per-item decisions, or appearance-based judgments would undermine the transparency the Definition of Done provides.
- How does the Scrum Master help the larger organization with respect to Scrum?
- By managing the budgets of multiple products
- By leading, training, and coaching the organization in its Scrum adoption
- By approving organizational hires
- By writing the organization's strategy documents
Correct answer: By leading, training, and coaching the organization in its Scrum adoption
The Scrum Master serves the organization by leading, training, and coaching it in its Scrum adoption and by helping employees and stakeholders understand empirical, lean approaches. Managing budgets, approving hires, and writing strategy documents are outside the Scrum Master's defined accountabilities.
- A new team is unsure how the Scrum events fit together. Which Scrum Master action best fits their accountability?
- Assigning each person their tasks for the Sprint
- Deciding the order of the Product Backlog
- Coaching the team to understand and enact the Scrum framework effectively
- Writing the code for the Increment
Correct answer: Coaching the team to understand and enact the Scrum framework effectively
Coaching the team to understand and enact Scrum effectively directly fits the Scrum Master's accountability for the team's understanding of Scrum theory and practice. Assigning tasks, ordering the Product Backlog, and writing code belong to the Developers or Product Owner, not the Scrum Master.
- What is the correct description of the Scrum Team's structure in the 2020 Scrum Guide?
- Two sub-teams: a development team and a management team
- A hierarchy with the Scrum Master at the top
- Separate teams for testing, design, and coding
- One cohesive unit of professionals with no sub-teams or hierarchies
Correct answer: One cohesive unit of professionals with no sub-teams or hierarchies
The 2020 Scrum Guide describes the Scrum Team as one cohesive unit of professionals focused on one Product Goal at a time, with no sub-teams or hierarchies. There is no separate development team, no internal management layer, and no Scrum Master hierarchy.
- Within the Scrum Team, who is accountable for instilling and ensuring adherence to Scrum, distinct from the Product Owner and Developers?
- The Scrum Master
- The Product Owner
- The Developers
- The stakeholders
Correct answer: The Scrum Master
The Scrum Master is accountable for establishing Scrum and ensuring it is understood and enacted, distinct from the Product Owner's value accountability and the Developers' Increment accountability. Stakeholders are outside the Scrum Team and hold none of these internal accountabilities.
- What is the purpose of having a single objective, the Sprint Goal, that the Developers commit to?
- It locks every task in place for the Sprint
- It gives the team flexibility in how to meet it while keeping everyone working toward the same outcome
- It allows each Developer to pursue separate goals
- It replaces the need for a Definition of Done
Correct answer: It gives the team flexibility in how to meet it while keeping everyone working toward the same outcome
The Sprint Goal gives the Developers flexibility regarding the exact work needed while keeping them aligned toward a shared outcome, fostering collaboration and focus. It does not lock every task, encourage separate individual goals, or replace the Definition of Done.
- Which of the following correctly describes the timeboxes of the four Sprint sub-events for a one-month Sprint?
- Sprint Planning up to 4 hours, Daily Scrum 30 minutes, Sprint Review up to 8 hours, Sprint Retrospective up to 4 hours
- Sprint Planning up to 2 hours, Daily Scrum 15 minutes, Sprint Review up to 2 hours, Sprint Retrospective up to 2 hours
- Sprint Planning up to 8 hours, Daily Scrum 15 minutes, Sprint Review up to 4 hours, Sprint Retrospective up to 3 hours
- All four sub-events share a single 8-hour timebox
Correct answer: Sprint Planning up to 8 hours, Daily Scrum 15 minutes, Sprint Review up to 4 hours, Sprint Retrospective up to 3 hours
For a one-month Sprint the timeboxes are: Sprint Planning up to 8 hours, the Daily Scrum 15 minutes, the Sprint Review up to 4 hours, and the Sprint Retrospective up to 3 hours. The other options misstate one or more of these maximums.
- Why does Scrum keep its rules and components deliberately minimal, or lightweight?
- It is intentionally incomplete and should not be followed fully
- It removes accountability from the team
- It guarantees success regardless of how it is used
- It defines only what is needed to enact empiricism, leaving practices to be added by the team
Correct answer: It defines only what is needed to enact empiricism, leaving practices to be added by the team
Scrum is purposefully lightweight, defining only the parts needed to implement empiricism and lean thinking, while the specific tactics and practices are left to the people using it. Being minimal does not mean it is optional, removes accountability, or guarantees success on its own.
- If the parts of Scrum, such as omitting an event, are not implemented as described, what does the Scrum Guide say?
- The framework is immutable; omitting elements covers up problems and limits the benefits of Scrum
- Teams are free to drop any event they dislike
- Omitting events is encouraged for experienced teams
- Only the Sprint is mandatory; all other events are optional
Correct answer: The framework is immutable; omitting elements covers up problems and limits the benefits of Scrum
The Scrum Guide states that Scrum's framework is immutable; while only parts of Scrum can be implemented, the result is not Scrum, and omitting elements covers up problems and reduces the benefits. Dropping events is not permitted, even for experienced teams.
- What is the relationship between the Sprint Backlog and the Sprint Goal?
- The Sprint Goal is unrelated to the Sprint Backlog
- The Sprint Goal is part of the Sprint Backlog and gives meaning to the selected work
- The Sprint Goal is part of the Product Backlog, not the Sprint Backlog
- The Sprint Backlog contains the Product Goal instead of the Sprint Goal
Correct answer: The Sprint Goal is part of the Sprint Backlog and gives meaning to the selected work
The Sprint Goal is part of the Sprint Backlog, alongside the selected Product Backlog items and the plan to deliver them; it gives meaning and coherence to the chosen work. The Product Goal belongs to the Product Backlog, not the Sprint Backlog.
- Which statement about the Increment and the Definition of Done is accurate?
- An Increment exists as soon as coding starts
- An Increment exists only after the Sprint Review approves it
- The moment a Product Backlog item meets the Definition of Done, an Increment is born
- The Definition of Done applies to the Product Backlog, not the Increment
Correct answer: The moment a Product Backlog item meets the Definition of Done, an Increment is born
The moment a Product Backlog item meets the Definition of Done, an Increment is born; the Definition of Done is the commitment for the Increment. An Increment does not exist merely because coding started or because the Review approved it, and the Definition of Done applies to the Increment.
- Why is producing at least one valuable, useful Increment each Sprint important to Scrum?
- It is only a recommendation that teams may skip
- It guarantees the Product Goal is achieved that Sprint
- It eliminates the need for the Sprint Retrospective
- It ensures empirical inspection happens on real, usable results at least once every Sprint
Correct answer: It ensures empirical inspection happens on real, usable results at least once every Sprint
Delivering at least one valuable, usable Increment every Sprint ensures the team has real, usable results to inspect and adapt against, keeping empiricism intact. It is not optional, does not guarantee reaching the Product Goal, and does not remove the Retrospective.
- How does the Product Goal support the empirical process across Sprints?
- It provides a long-term target the team plans toward and measures progress against each Sprint
- It eliminates the need to inspect Increments
- It changes the Sprint Goal automatically each Sprint
- It is only relevant during Sprint Planning
Correct answer: It provides a long-term target the team plans toward and measures progress against each Sprint
The Product Goal gives the Scrum Team a long-term objective to plan against and measure progress toward over successive Sprints, supporting empiricism across the product's lifetime. It does not remove Increment inspection, auto-change Sprint Goals, or apply only during Sprint Planning.
- Which best describes how transparency, inspection, and adaptation appear in the Sprint Review?
- Only adaptation occurs at the Sprint Review
- Transparency of the Increment enables stakeholders to inspect it and the team to adapt the Product Backlog
- Only transparency is required; no inspection happens
- Inspection happens but adaptation is forbidden at the Review
Correct answer: Transparency of the Increment enables stakeholders to inspect it and the team to adapt the Product Backlog
The Sprint Review embodies all three pillars: a transparent Increment enables stakeholders and the team to inspect progress, and the resulting collaboration leads to adapting the Product Backlog. It is not limited to a single pillar, and adaptation of the backlog is a normal outcome.
- Which best illustrates focus and commitment working together in Scrum?
- The team works on as many unrelated items as possible
- Each member commits only to their own private goal
- The team concentrates on the Sprint Goal and dedicates itself to achieving the goals of the Scrum Team
- The team avoids any shared objective to stay flexible
Correct answer: The team concentrates on the Sprint Goal and dedicates itself to achieving the goals of the Scrum Team
Focus and commitment work together when the team concentrates on the Sprint Goal and the work of the Sprint while dedicating itself to the Scrum Team's goals. Spreading across unrelated items, pursuing private goals, or avoiding shared objectives would contradict these values.
- What is the role of the Sprint Backlog's plan in supporting the Daily Scrum?
- It is a fixed plan that cannot change after Sprint Planning
- It is owned by the Scrum Master who updates it daily
- It is reviewed only at the Sprint Review
- It is the plan the Developers inspect and adapt each day to make progress toward the Sprint Goal
Correct answer: It is the plan the Developers inspect and adapt each day to make progress toward the Sprint Goal
The Sprint Backlog's plan is what the Developers inspect and adapt each day at the Daily Scrum to make tangible progress toward the Sprint Goal. The plan is emergent, owned by the Developers, and adjusted throughout the Sprint, not fixed or owned by the Scrum Master.
- Which statement correctly relates the three commitments to their artifacts?
- Product Goal to Product Backlog, Sprint Goal to Sprint Backlog, Definition of Done to Increment
- Sprint Goal to Product Backlog, Product Goal to Sprint Backlog, Definition of Done to Increment
- Definition of Done to Product Backlog, Product Goal to Increment, Sprint Goal to Sprint Backlog
- Product Goal to Increment, Sprint Goal to Product Backlog, Definition of Done to Sprint Backlog
Correct answer: Product Goal to Product Backlog, Sprint Goal to Sprint Backlog, Definition of Done to Increment
The correct mapping is Product Goal to the Product Backlog, Sprint Goal to the Sprint Backlog, and Definition of Done to the Increment. The other options scramble these artifact-to-commitment relationships, which the exam frequently tests.
- Why does Scrum prescribe events rather than relying on a continuous, unstructured flow of work?
- Events make the work slower on purpose
- Each event is a formal opportunity to inspect and adapt specific artifacts, preventing the need for undefined meetings
- Events transfer decisions to a steering committee
- Events are required only for new teams
Correct answer: Each event is a formal opportunity to inspect and adapt specific artifacts, preventing the need for undefined meetings
Scrum prescribes events because each is a formal opportunity to inspect and adapt particular artifacts, creating regularity and reducing the need for meetings not defined in Scrum. They are not meant to slow work, move decisions to a committee, or apply only to new teams.
- A Scrum Team's Increment passes the team's quality bar but the team realizes mid-Sprint that quality would suffer if it rushed remaining items. What does Scrum require?
- The team lowers the Definition of Done to fit the remaining time
- The team extends the Sprint to maintain quality
- Quality must not decrease, so the team renegotiates scope rather than lowering the Definition of Done
- The team cancels the Sprint to protect quality
Correct answer: Quality must not decrease, so the team renegotiates scope rather than lowering the Definition of Done
Scrum requires that quality not decrease during a Sprint, so the team renegotiates the scope of remaining work with the Product Owner rather than weakening the Definition of Done. Lowering the Definition of Done, extending the Sprint, and cancelling the Sprint are not appropriate responses.
- Which best captures why the Definition of Done is described as a commitment for the Increment?
- It is a list of features the Product Owner promises stakeholders
- It is the team's promise to finish all Product Backlog items
- It is a deadline by which the Increment must release
- It is the agreed quality standard every Increment must meet, making the Increment's state transparent
Correct answer: It is the agreed quality standard every Increment must meet, making the Increment's state transparent
The Definition of Done is a commitment for the Increment because it is the agreed quality standard every Increment must satisfy, which makes the Increment's true state transparent. It is not a feature promise, a pledge to finish the whole backlog, or a release deadline.
- What does it mean that the Scrum Master is a true leader serving the team rather than a manager directing it?
- The Scrum Master enables the team's effectiveness and self-management instead of assigning and controlling its work
- The Scrum Master assigns daily tasks to each Developer
- The Scrum Master approves every technical decision
- The Scrum Master sets individual performance ratings
Correct answer: The Scrum Master enables the team's effectiveness and self-management instead of assigning and controlling its work
Being a true leader who serves means the Scrum Master enables the team's effectiveness and self-management rather than assigning, controlling, or approving its work. Directing tasks, approving technical decisions, and rating individuals are not part of this servant-leadership stance.
- How does the absence of gaps between Sprints support empiricism?
- Gaps would speed up delivery
- Continuous Sprints create an uninterrupted rhythm of inspect-and-adapt cycles
- Continuous Sprints remove the need for Sprint Planning
- Gaps are required to reset the Product Backlog
Correct answer: Continuous Sprints create an uninterrupted rhythm of inspect-and-adapt cycles
Running Sprints back-to-back with no gaps creates an uninterrupted cadence of inspect-and-adapt cycles, which is essential to empirical process control. Gaps would interrupt this rhythm rather than speed delivery, and continuous Sprints still require Sprint Planning each time.
- Which of the following correctly states what the Daily Scrum produces?
- A formal status report for management
- An updated Product Backlog ordering
- An actionable plan for the next day of work toward the Sprint Goal
- A finalized Definition of Done
Correct answer: An actionable plan for the next day of work toward the Sprint Goal
The Daily Scrum produces an actionable plan for the next day of work as the Developers adapt their approach toward the Sprint Goal. It does not produce a management status report, a reordered Product Backlog, or a Definition of Done.
- Which best explains why Sprint Planning must result in a Sprint Goal before it ends?
- Without it the Sprint cannot have a timebox
- Without it the Product Owner cannot order the backlog
- The Sprint Goal is needed to calculate velocity
- The Sprint Goal gives the Sprint a single coherent objective the Developers commit to pursuing
Correct answer: The Sprint Goal gives the Sprint a single coherent objective the Developers commit to pursuing
Sprint Planning must yield a Sprint Goal because it provides the single coherent objective the Developers commit to, giving focus and a basis for renegotiating scope. The Sprint timebox, backlog ordering, and velocity calculations do not depend on the Sprint Goal in this way.
- What distinguishes the Product Backlog from the Sprint Backlog?
- The Product Backlog is all future work for the product; the Sprint Backlog is the plan for the current Sprint
- They are two names for the same artifact
- The Sprint Backlog contains all future work; the Product Backlog is for one Sprint
- The Product Backlog is owned by Developers; the Sprint Backlog by the Product Owner
Correct answer: The Product Backlog is all future work for the product; the Sprint Backlog is the plan for the current Sprint
The Product Backlog is the emergent, ordered list of all work that could improve the product, while the Sprint Backlog is the Developers' plan for the current Sprint, the Sprint Goal, selected items, and how to deliver them. They are distinct artifacts with different scopes and owners.
- Why might a Scrum Team make its Definition of Done stricter over time?
- To make it easier to declare items Done quickly
- To continually raise the quality bar of the Increment as the team's capability grows
- To reduce the amount of inspection needed
- Because the Scrum Guide forbids keeping it constant
Correct answer: To continually raise the quality bar of the Increment as the team's capability grows
A team may strengthen its Definition of Done over time to raise the quality bar of the Increment as its capability and standards grow, never to make Done easier or reduce inspection. The Scrum Guide allows but does not require the Definition of Done to change.
- Which scenario shows correct handling of an item that fails the Definition of Done at Sprint end?
- The item is presented as Done at the Sprint Review with caveats
- The item is silently carried into the next Sprint Backlog
- The item is returned to the Product Backlog, re-estimated, and considered for a future Sprint
- The item is deleted to keep the backlog clean
Correct answer: The item is returned to the Product Backlog, re-estimated, and considered for a future Sprint
An item that fails the Definition of Done at Sprint end is returned to the Product Backlog and re-estimated for future consideration. It is not presented as Done at the Review, automatically carried over, or deleted, since deletion would lose valuable work and transparency.
- How does the Scrum Master support transparency of the artifacts?
- By approving the Product Backlog ordering
- By personally writing the Increment
- By hiding problems from stakeholders to keep morale high
- By coaching the team to apply the artifact commitments and helping make impediments and progress visible
Correct answer: By coaching the team to apply the artifact commitments and helping make impediments and progress visible
The Scrum Master supports artifact transparency by coaching the team to apply the commitments, Product Goal, Sprint Goal, and Definition of Done, and by helping make impediments and progress visible. Approving backlog ordering, writing the Increment, and concealing problems are not Scrum Master behaviors.
- What is the significance of the Daily Scrum's 15-minute timebox?
- It keeps the event focused and efficient so the Developers quickly create a plan for the day
- It allows time for a detailed status report to managers
- It ensures every team member speaks for an equal amount of time
- It is the minimum length, not a maximum
Correct answer: It keeps the event focused and efficient so the Developers quickly create a plan for the day
The 15-minute timebox keeps the Daily Scrum focused and efficient, prompting the Developers to quickly inspect progress and form a plan for the day. It is a maximum length, not a vehicle for management status reports, and does not mandate equal speaking time.
- Which statement best captures the shared accountability of the single Scrum Team unit?
- Each accountability holder is responsible only for their own separate deliverable
- The whole team is collectively accountable for creating a valuable, useful Increment every Sprint
- Only the Developers are accountable for anything the team produces
- Accountability belongs to managers outside the team
Correct answer: The whole team is collectively accountable for creating a valuable, useful Increment every Sprint
The whole team is collectively accountable for creating a valuable, useful Increment every Sprint. As one cohesive unit, the Scrum Team owns the outcome together rather than splitting into isolated deliverables. The accountability does not rest solely with the Developers, with separate individuals, or with managers outside the team.
- A team building a mobile app must wait two weeks every Sprint for a separate localization group to translate strings before anything can be Done. From a cross-functionality standpoint, what is the underlying issue?
- The team is missing a skill it needs, so it cannot create a complete Increment by itself
- The team has too many skills and should remove some members
- Cross-functionality does not apply to mobile apps
- The localization group should attend the team's Daily Scrum each day
Correct answer: The team is missing a skill it needs, so it cannot create a complete Increment by itself
The underlying issue is that the team is missing a skill it needs, so it cannot create a complete Increment by itself. Cross-functionality requires the team to hold all competencies needed to deliver value each Sprint. The team does not have too many skills, the concept applies to any product, and inviting the localization group to the Daily Scrum would not build the team's own capability.
- Why does cross-functionality strengthen a team's ability to deliver value empirically each Sprint?
- Because it lets the team hand off work to external groups faster
- Because it removes the team's accountability for quality
- Because the team can take an item from idea to a Done Increment without waiting on outside dependencies
- Because it guarantees the team never has to learn anything new
Correct answer: Because the team can take an item from idea to a Done Increment without waiting on outside dependencies
Cross-functionality lets the team take an item from idea to a Done Increment without waiting on outside dependencies, so it can produce inspectable results every Sprint. This supports empirical inspection and adaptation on real Increments. It is not about faster external hand-offs, removing quality accountability, or freezing the team's learning.
- A cross-functional team has a database expert who is overloaded while several teammates avoid all database work. Over several Sprints, which approach best preserves cross-functionality?
- Permanently route every database task to the single expert
- Hire a separate database team that the Scrum Team hands work to
- Stop accepting any items that require database work
- Have the experts pair with and teach teammates so database skills spread across the team
Correct answer: Have the experts pair with and teach teammates so database skills spread across the team
The experts should pair with and teach teammates so database skills spread across the team, which keeps the team genuinely cross-functional and resilient. Concentrating all work on one person, spinning up a separate team, or refusing needed work all preserve the dependency rather than developing the team's collective capability.
- Which scenario best demonstrates a fully cross-functional Scrum Team?
- The team can design, build, test, and integrate a feature into a Done Increment without external hand-offs
- The team writes code but always sends it to a separate quality group to finish
- Each member works only within their narrow specialty and never collaborates
- The team depends on an outside architect to approve every design
Correct answer: The team can design, build, test, and integrate a feature into a Done Increment without external hand-offs
A fully cross-functional team can design, build, test, and integrate a feature into a Done Increment without external hand-offs. The competencies needed to create value live within the team. Routing work to a separate quality group, confining members to isolated specialties, or depending on an outside architect for approvals all indicate the team is not yet fully cross-functional.
- What does it mean that a Scrum Team is self-managing in the 2020 Scrum Guide?
- A manager outside the team plans and assigns all of its work
- The team internally decides who does the work, what to work on, and how to do it
- The Scrum Master assigns each task and tracks individual output
- The Product Owner schedules each Developer's daily tasks
Correct answer: The team internally decides who does the work, what to work on, and how to do it
Self-managing means the team internally decides who does the work, what to work on, and how to do it. The 2020 Scrum Guide replaced self-organizing with self-managing to emphasize this internal authority over the work. It does not mean an external manager plans the work, the Scrum Master assigns tasks, or the Product Owner schedules each Developer's day.
- Which terminology change did the 2020 Scrum Guide make regarding how the Scrum Team governs its own work?
- It replaced self-organizing with self-managing to broaden the team's internal authority
- It replaced self-managing with manager-directed
- It removed the idea of teams governing their own work entirely
- It renamed self-organizing to externally coordinated
Correct answer: It replaced self-organizing with self-managing to broaden the team's internal authority
The 2020 Scrum Guide replaced self-organizing with self-managing to broaden the team's internal authority over not just how it organizes but who does the work, what it works on, and how. It did not move toward manager-directed work, remove the concept, or rename it to externally coordinated; the change strengthened the team's autonomy.
- A traditional manager wants to start assigning specific tasks to individual Developers each morning to boost efficiency. Why does this undermine the Scrum Team?
- Because the Scrum Master is the only one allowed to assign tasks
- Because task assignment must come from stakeholders instead
- Because self-managing teams choose internally who does what, and external assignment erodes that autonomy
- Because Developers are not permitted to work on more than one task at a time
Correct answer: Because self-managing teams choose internally who does what, and external assignment erodes that autonomy
It undermines the team because self-managing teams choose internally who does what, and external assignment erodes that autonomy and accountability. The fix is not to move task assignment to the Scrum Master or stakeholders, since neither should be directing the Developers' work, and Scrum places no limit on working a single task at a time. The decision belongs to the team itself.
- How does genuine self-management tend to improve the quality of decisions about how work gets done?
- It centralizes decisions with the most senior person for speed
- The people closest to the work make the decisions and adapt quickly as they learn
- It defers all decisions to a change-control board
- It removes the team's need to inspect and adapt
Correct answer: The people closest to the work make the decisions and adapt quickly as they learn
Self-management improves decisions because the people closest to the work make the decisions and adapt quickly as they learn during the Sprint. Those doing the work have the most relevant context. Centralizing decisions with a senior individual, routing them to a change-control board, or removing inspect-and-adapt would all move decisions away from where the knowledge lives.
- Why does Scrum hold the Developers collectively, rather than individually, accountable for the Increment?
- Because individual hand-offs are always faster than collaboration
- Because shared accountability encourages them to integrate their skills and own the result together
- Because the Scrum Master assigns each person a separate deliverable
- Because the Product Owner prefers isolated specialists
Correct answer: Because shared accountability encourages them to integrate their skills and own the result together
Scrum holds the Developers collectively accountable because shared accountability encourages them to integrate their skills and own the result together, producing a cohesive Increment. It is not because individual hand-offs are faster, because the Scrum Master assigns separate deliverables, or because the Product Owner prefers isolated specialists; collective accountability builds a stronger, more capable team.
- Several Developers finish their selected items early while one teammate's work, critical to the Sprint Goal, is falling behind. Consistent with the Developers' accountability, what should they do?
- Wait for the Scrum Master to reassign the struggling teammate's work
- Pull unrelated new items from the Product Backlog to stay busy
- Collaborate to help with the at-risk work, since they are collectively accountable for the Increment and Sprint Goal
- End the Sprint early because their own items are complete
Correct answer: Collaborate to help with the at-risk work, since they are collectively accountable for the Increment and Sprint Goal
They should collaborate to help with the at-risk work, since the Developers are collectively accountable for the Increment and the Sprint Goal, not just their own items. Waiting for reassignment, pulling unrelated items, or ending the Sprint early all ignore the shared accountability that defines how Developers work together.
- How does the Scrum Guide describe the leadership style of the Scrum Master?
- A command-and-control manager who directs the team's work
- A true leader who serves the Scrum Team and the larger organization
- An administrative scheduler with no leadership role
- A technical lead who designs the solution for the team
Correct answer: A true leader who serves the Scrum Team and the larger organization
The Scrum Master is described as a true leader who serves the Scrum Team and the larger organization. This service-oriented leadership focuses on enabling others rather than directing them. It is not command-and-control management, a purely administrative scheduling role, or a technical lead designing the solution.
- A Scrum Master frequently steps in to make the team's decisions to keep things moving. Why does this conflict with serving as a true leader?
- Because true leaders are forbidden from attending Scrum events
- Because only the Product Owner is allowed to make any team decisions
- Because serving as a true leader means growing the team's ability to decide and act for itself, not deciding for it
- Because true leaders must make every decision personally and quickly
Correct answer: Because serving as a true leader means growing the team's ability to decide and act for itself, not deciding for it
It conflicts because serving as a true leader means growing the team's ability to decide and act for itself, not deciding for it. Repeatedly deciding for the team weakens its self-management. True leaders do attend events, decision-making is not reserved for the Product Owner, and a true leader does not aim to make every decision personally.
- A team has become highly capable and self-reliant over many Sprints. How should a true-leader Scrum Master most appropriately adjust their involvement?
- Increase day-to-day direction to keep tight control
- Begin assigning individual tasks again to stay relevant
- Stop attending the Scrum events entirely
- Shift toward broader coaching and removing organizational impediments while letting the team run its own work
Correct answer: Shift toward broader coaching and removing organizational impediments while letting the team run its own work
The Scrum Master should shift toward broader coaching and removing organizational impediments while letting the team run its own work. As capability grows, serving the team means stepping back from day-to-day matters it can handle. Increasing direction or reassigning individual tasks would reverse the team's growth, and abandoning the events is not appropriate.
- Which situation is an impediment the Scrum Master should most appropriately work to remove on the team's behalf?
- A required testing environment owned by another department has been unavailable for weeks, stalling the team
- The Developers disagree about a code formatting style
- A Developer wants to pick up a different task than originally planned
- The team wants to reorder a couple of items on its Sprint Backlog
Correct answer: A required testing environment owned by another department has been unavailable for weeks, stalling the team
A required testing environment owned by another department and unavailable for weeks is an organizational impediment beyond the team's reach, so the Scrum Master should work to remove it. Disagreements over formatting, a Developer choosing a different task, or reordering the Sprint Backlog are matters the self-managing team can resolve itself.
- Why is the Scrum Master's work to remove impediments framed as developing the team rather than only speeding up delivery?
- Because it makes the team permanently dependent on the Scrum Master
- Because it transfers the team's accountability for the Increment to the Scrum Master
- Because clearing blockers beyond the team's control protects its focus and lets it build capability and confidence
- Because it replaces the need for the Sprint Retrospective
Correct answer: Because clearing blockers beyond the team's control protects its focus and lets it build capability and confidence
Removing impediments develops the team because clearing blockers beyond its control protects its focus and lets it build capability and confidence over time. It is not meant to create permanent dependence on the Scrum Master, transfer the Developers' accountability for the Increment, or replace the Retrospective where the team inspects and adapts its own way of working.
- A team reports that a slow, manual access-request process owned by central IT blocks it nearly every Sprint. What is the Scrum Master's most fitting action?
- Tell the team to keep absorbing the delay indefinitely
- Cancel the Sprint until the process is fixed
- Lower the team's Definition of Done so the blocker no longer matters
- Engage central IT to streamline or remove the recurring blocker
Correct answer: Engage central IT to streamline or remove the recurring blocker
The most fitting action is to engage central IT to streamline or remove the recurring blocker, which is the Scrum Master serving the team on an impediment beyond its control. Telling the team to absorb it, cancelling the Sprint, or weakening the Definition of Done all fail to address the underlying organizational impediment.
- A team already has strong technical skills but routinely asks the Scrum Master to decide how it should approach its work. Which coaching focus best develops this team?
- Coach cross-functionality, since the team is missing skills
- Coach release planning, since the team needs a delivery schedule
- Coach self-management, helping the team learn to decide for itself how the work is done
- Coach stakeholder management, since the team lacks external contacts
Correct answer: Coach self-management, helping the team learn to decide for itself how the work is done
Because the team already has strong skills but defers decisions, the best focus is coaching self-management, helping the team learn to decide for itself how the work is done. Cross-functionality addresses missing skills the team already possesses, and release planning or stakeholder management do not address the habit of deferring its own decisions.
- Which approach best reflects a Scrum Master coaching a team toward greater cross-functionality over several Sprints?
- Personally performing the missing skill for the team each Sprint
- Permanently outsourcing the skill to an external vendor
- Removing all work that requires the missing skill from the backlog
- Encouraging pairing, knowledge-sharing, and deliberate skill growth so the team gradually covers the gap itself
Correct answer: Encouraging pairing, knowledge-sharing, and deliberate skill growth so the team gradually covers the gap itself
Coaching toward cross-functionality means encouraging pairing, knowledge-sharing, and deliberate skill growth so the team gradually covers the gap itself. Performing the skill for the team, outsourcing it permanently, or removing the work all leave the team dependent rather than building its own capability to create a complete Increment.
- A stakeholder emails individual Developers throughout the Sprint asking them to add new features directly to the Sprint Backlog. To keep value decisions coherent, where should such requests be directed?
- To the Product Owner, who decides how new requests affect the product and the Product Backlog
- To the Scrum Master, who approves or rejects each request
- To whichever Developer has spare capacity that day
- Into the Sprint Backlog immediately, since stakeholder needs come first
Correct answer: To the Product Owner, who decides how new requests affect the product and the Product Backlog
Such requests should be directed to the Product Owner, who decides how new requests affect the product and the Product Backlog, because the Product Owner is the single point of accountability for value. Routing approvals through the Scrum Master, letting any available Developer accept work, or dropping requests straight into the Sprint Backlog would fragment value decisions and bypass the one person accountable for them.
- Which activity is part of the Product Owner's accountability for the product?
- Writing the technical design for each Product Backlog item
- Setting the 15-minute timebox for the Daily Scrum
- Deciding the order of the Product Backlog and clearly communicating the Product Goal
- Assigning specific tasks to individual Developers each day
Correct answer: Deciding the order of the Product Backlog and clearly communicating the Product Goal
Deciding the order of the Product Backlog and clearly communicating the Product Goal is part of the Product Owner's accountability for maximizing value. Writing technical designs and assigning daily tasks belong to the self-managing Developers, and the Daily Scrum timebox is fixed by Scrum rather than set by the Product Owner. Ordering and goal communication are central to managing the product.
- An organization splits the Product Owner duties so that one person owns the budget, another owns priorities, and a third talks to customers, with no single accountable individual. Why does this work against agile product management?
- Because Scrum forbids anyone from talking to customers
- Because the budget owner must always outrank the others
- Because value decisions become fragmented and no single person is accountable for maximizing the product's value
- Because the Scrum Master must take over all three duties
Correct answer: Because value decisions become fragmented and no single person is accountable for maximizing the product's value
Splitting the duties this way works against agile product management because value decisions become fragmented and no single person is accountable for maximizing the product's value. Scrum does not forbid customer contact, does not rank a budget owner above others, and does not push these duties onto the Scrum Master. A single accountable Product Owner is what keeps value trade-offs coherent.
- How often does Product Backlog refinement occur in a healthy Scrum Team?
- As an ongoing activity throughout the Sprint, as much as the Scrum Team finds useful
- Exactly once per Sprint, in a dedicated mandatory event
- Only during the first Sprint of a project
- Only when the Product Owner is on leave
Correct answer: As an ongoing activity throughout the Sprint, as much as the Scrum Team finds useful
Refinement occurs as an ongoing activity throughout the Sprint, as much as the Scrum Team finds useful, because Scrum treats it as a continuous practice rather than a fixed ceremony. It is not a single mandatory event, not limited to the first Sprint, and certainly not tied to the Product Owner being away. Keeping refinement continuous ensures items are ready when needed.
- How much of the total Product Backlog does Scrum require a team to refine in detail at any given time?
- The entire backlog must be fully detailed before the project starts
- At least half of the backlog must always be refined
- Exactly one Sprint's worth of items and nothing more
- Only the higher-ordered items need finer detail; lower items can stay coarse
Correct answer: Only the higher-ordered items need finer detail; lower items can stay coarse
Only the higher-ordered items need finer detail, while lower-ordered items can stay coarse, reflecting the idea that detail emerges as items rise toward the top. Scrum does not require the entire backlog to be detailed up front, sets no fixed half-the-backlog rule, and does not cap refinement at exactly one Sprint's worth. Refining just-in-time as items approach selection avoids wasted effort.
- A team wants to know whether an item is ready to be selected for an upcoming Sprint. Which outcome of refinement best supports that judgment?
- The item has a code branch already created for it
- The item is understood well enough and sized so the Developers are confident they can complete it within a Sprint
- The item has been assigned a fixed deadline by a manager
- The item has been approved in writing by every stakeholder
Correct answer: The item is understood well enough and sized so the Developers are confident they can complete it within a Sprint
An item being understood well enough and sized so the Developers are confident they can complete it within a Sprint is the refinement outcome that signals readiness. A pre-created code branch, a manager-imposed deadline, or written stakeholder approval are not what make an item ready. Shared understanding and appropriate size are the practical markers of a refined, selectable item.
- Two competing features could each be built next. The Product Owner is unsure which delivers more value. Which approach best reflects empirical, value-maximizing product management?
- Release a small slice of the more promising feature, learn from real usage, and adjust ordering based on what is observed
- Build both fully so nothing is missed
- Always build the cheaper one first regardless of value
- Wait until the Product Goal is fully achieved before deciding
Correct answer: Release a small slice of the more promising feature, learn from real usage, and adjust ordering based on what is observed
Releasing a small slice of the more promising feature, learning from real usage, and adjusting ordering based on observation best reflects empirical, value-maximizing product management. Building both fully wastes effort, defaulting to the cheaper option ignores value, and waiting for the entire Product Goal stalls learning. Using real feedback to guide investment is how value is maximized under uncertainty.
- Which question is most central to a Product Owner trying to maximize the value of the product?
- How many lines of code did the team write this Sprint?
- Did every Developer attend the Daily Scrum on time?
- Are we building the things that will deliver the greatest benefit to customers and the organization?
- Did the burndown chart reach zero exactly on the last day?
Correct answer: Are we building the things that will deliver the greatest benefit to customers and the organization?
Asking whether the team is building the things that deliver the greatest benefit to customers and the organization is most central to maximizing value. Lines of code, perfect Daily Scrum attendance, and a tidy burndown chart measure activity or process, not whether the product is producing real benefit. Value maximization is fundamentally about choosing the right work.
- A Product Owner keeps adding every requested feature to maximize how much the product can do. Adoption metrics show users rely on only a few features. What does this most likely indicate about value?
- More features always equal more value, so the approach is sound
- The Developers must be working too slowly
- The Scrum Master should add the unused features to the Definition of Done
- Effort is being spent on features that deliver little value, so trimming and focusing could increase value
Correct answer: Effort is being spent on features that deliver little value, so trimming and focusing could increase value
Low usage of most features most likely indicates that effort is being spent on features delivering little value, so trimming and focusing could increase value. More features do not automatically mean more value, the pattern is not a developer-speed problem, and the Definition of Done is about quality, not feature volume. Concentrating on what users actually need raises value.
- What is the primary purpose of inviting stakeholders to the Sprint Review?
- To collect their approval signatures so the Increment can be released
- To collaborate on results and feedback so the Product Backlog can be adapted for future work
- To assign blame for anything the team did not finish
- To have them facilitate the event in place of the Scrum Master
Correct answer: To collaborate on results and feedback so the Product Backlog can be adapted for future work
The primary purpose of inviting stakeholders is to collaborate on results and feedback so the Product Backlog can be adapted for future work. The review is not an approval-signature gate, not a forum for assigning blame, and stakeholders do not take over facilitation. Their input feeds the inspect-and-adapt loop that shapes what the product should do next.
- At a Sprint Review, key customers consistently react far more positively to one capability than the team expected. How should the Scrum Team most appropriately respond?
- Ignore the reaction because the plan was already set
- Immediately promise a fixed delivery date for all related features
- Reflect that signal in the Product Backlog, potentially raising the priority of related work
- Ask the Scrum Master to overrule the Product Owner's ordering
Correct answer: Reflect that signal in the Product Backlog, potentially raising the priority of related work
The team should reflect that signal in the Product Backlog, potentially raising the priority of related work, since the Sprint Review exists to turn stakeholder feedback into backlog adaptation. Ignoring the reaction wastes the insight, promising fixed dates abandons empiricism, and the Scrum Master does not overrule the Product Owner's ordering. Acting on real reactions is the point of the collaboration.
- Which statement best captures the role of the Sprint Review in managing the product over time?
- It is a status meeting where the Scrum Master reports metrics to management
- It is the only time the Product Backlog is ever allowed to change
- It is a sign-off meeting that locks the next Sprint's scope
- It is a collaborative checkpoint where the Increment is inspected and the Product Backlog is adjusted based on what was learned
Correct answer: It is a collaborative checkpoint where the Increment is inspected and the Product Backlog is adjusted based on what was learned
The Sprint Review is a collaborative checkpoint where the Increment is inspected and the Product Backlog is adjusted based on what was learned. It is not a Scrum-Master-led management status report, not the sole moment the backlog can change, and not a meeting that locks future scope. Its value comes from collaboration that keeps the product on a valuable path.
- Why does Scrum favor delivering value in frequent, small Increments rather than one large release at the end?
- Because small releases are required by law in most industries
- Because frequent delivery enables faster feedback and earlier value, reducing the risk of building the wrong thing for a long time
- Because the Scrum Guide bans projects longer than one Sprint
- Because large releases are forbidden by the Definition of Done
Correct answer: Because frequent delivery enables faster feedback and earlier value, reducing the risk of building the wrong thing for a long time
Scrum favors frequent, small Increments because frequent delivery enables faster feedback and earlier value, reducing the risk of building the wrong thing for a long time. There is no legal mandate at play, Scrum does not ban multi-Sprint efforts, and the Definition of Done concerns quality, not release size. Incremental delivery is an empirical risk-reduction strategy.
- Who ultimately decides whether and when a Done Increment is released to customers?
- The Developers, by majority vote
- The Scrum Master, as part of facilitating the Sprint
- The Product Owner, as part of accountability for the product's value
- The stakeholders, collectively at the Sprint Review
Correct answer: The Product Owner, as part of accountability for the product's value
The Product Owner ultimately decides whether and when a Done Increment is released, as part of accountability for the product's value. Developers do not vote on releases, the Scrum Master facilitates rather than makes release calls, and stakeholders provide input but do not own the release decision. Release timing is a value decision that rests with the Product Owner.
- A team can technically produce a Done Increment every Sprint but chooses to release to customers only every few Sprints because of customer onboarding constraints. Is this compatible with Scrum?
- Yes, Scrum requires a usable Increment each Sprint but lets the Product Owner decide the actual release cadence
- No, Scrum requires releasing to customers at the end of every Sprint
- No, releasing less often than every Sprint violates the Definition of Done
- Yes, but only if the Scrum Master approves the slower cadence
Correct answer: Yes, Scrum requires a usable Increment each Sprint but lets the Product Owner decide the actual release cadence
This is compatible with Scrum, which requires a usable Increment each Sprint but lets the Product Owner decide the actual release cadence based on what makes sense for value. Scrum does not force a release to customers every Sprint, the Definition of Done governs quality rather than release frequency, and Scrum Master approval is not required for the cadence. Producing a releasable Increment and choosing when to release are distinct.
- When the Developers select Product Backlog items during Sprint Planning, how should that selected scope be understood?
- As a binding contract the team must complete exactly
- As the Product Owner's personal guarantee to stakeholders
- As a forecast of the work the Developers believe will achieve the Sprint Goal
- As a fixed list that cannot be discussed again until the next Sprint
Correct answer: As a forecast of the work the Developers believe will achieve the Sprint Goal
The selected scope should be understood as a forecast of the work the Developers believe will achieve the Sprint Goal. It is not a binding contract, not the Product Owner's guarantee, and not a frozen list, since scope can be renegotiated with the Product Owner as more is learned. Treating the selection as a forecast preserves the empiricism Scrum depends on.
- Midway through a Sprint, the Developers learn an item is far larger than expected and finishing everything selected now looks unlikely. What is the most appropriate response under Scrum?
- Hide the problem and hope to catch up by the deadline
- Cancel the Sprint immediately by Developer decision
- Drop the Sprint Goal and pick a new one without consulting anyone
- Collaborate with the Product Owner to renegotiate the scope while protecting the Sprint Goal
Correct answer: Collaborate with the Product Owner to renegotiate the scope while protecting the Sprint Goal
The most appropriate response is to collaborate with the Product Owner to renegotiate the scope while protecting the Sprint Goal, because the selected items are a forecast that can flex as learning occurs. Hiding the problem breaks transparency, Developers cannot cancel a Sprint, and quietly swapping the Sprint Goal ignores that the goal itself stays fixed. Renegotiating scope around a steady goal is the Scrum-aligned move.
- Why does Scrum treat the selected Sprint scope as a forecast rather than a firm promise?
- Because Developers are considered unreliable
- Because complex work carries inherent uncertainty that only becomes clearer as the work is done
- Because the Product Owner is not allowed to know the plan
- Because forecasts let the team avoid any accountability
Correct answer: Because complex work carries inherent uncertainty that only becomes clearer as the work is done
Scrum treats the selected scope as a forecast because complex work carries inherent uncertainty that only becomes clearer as the work is done. It is not a judgment that Developers are unreliable, it does not keep the Product Owner in the dark, and it is not a way to dodge accountability, since the team still commits to the Sprint Goal. Forecasting honestly reflects the unpredictability of complex product development.
- Under what circumstance does Scrum say a Sprint may be cancelled?
- When the Developers fall behind their forecast
- When a stakeholder is unhappy with progress
- When the Sprint Goal becomes obsolete
- When the burndown chart is not trending downward
Correct answer: When the Sprint Goal becomes obsolete
Scrum says a Sprint may be cancelled when the Sprint Goal becomes obsolete, meaning it no longer makes sense to pursue. Falling behind a forecast, stakeholder dissatisfaction, or an unfavorable burndown chart are not reasons to cancel, since the forecast can flex and metrics are not commitments. Cancellation is reserved for a goal that has lost its purpose.
- A Scrum Master, frustrated that a Sprint is going poorly, announces that the Sprint is cancelled. Why is this action improper?
- Because Sprints can never be cancelled for any reason
- Because a Sprint can only be cancelled at the Sprint Review
- Because the Developers must approve any cancellation by vote
- Because only the Product Owner has the authority to cancel a Sprint
Correct answer: Because only the Product Owner has the authority to cancel a Sprint
The action is improper because only the Product Owner has the authority to cancel a Sprint. Sprints can be cancelled under the right condition, so they are not uncancellable, cancellation is not restricted to the Sprint Review, and it does not require a Developer vote. A frustrated Scrum Master simply lacks the authority to make this call.
- Scrum notes that Sprint cancellations are uncommon. Why are they considered rare and often costly?
- Because cancelling a Sprint permanently deletes the Product Backlog
- Because Sprints are short, so a goal usually stays relevant for the brief duration, and cancellation consumes resources and disrupts the team
- Because the Scrum Guide charges a fee for each cancellation
- Because a cancelled Sprint must be repeated identically afterward
Correct answer: Because Sprints are short, so a goal usually stays relevant for the brief duration, and cancellation consumes resources and disrupts the team
Cancellations are rare and costly because Sprints are short, so a goal usually stays relevant for the brief duration, and cancellation consumes resources and disrupts the team. Cancelling a Sprint does not delete the Product Backlog, there is no fee, and a cancelled Sprint is not re-run identically. The short timebox is precisely why an obsolete goal is unusual.
- A Scrum Team uses velocity to forecast how much work it may take into the next Sprint. Where in the Scrum framework is velocity defined?
- It is listed as the fourth Scrum artifact
- It is the commitment attached to the Sprint Backlog
- It is not defined in Scrum at all; it is a complementary practice teams may choose to use
- It is a mandatory output of every Sprint Retrospective
Correct answer: It is not defined in Scrum at all; it is a complementary practice teams may choose to use
Velocity is not defined in Scrum at all; it is a complementary practice teams may choose to use. It is not a fourth artifact, the Sprint Backlog's commitment is the Sprint Goal rather than velocity, and it is not a required Retrospective output. Teams may adopt velocity to aid forecasting, but it sits outside the Scrum framework itself.
- Two Scrum Teams have very different average velocities. A manager wants to compare them to judge which team is more productive. Why is this misuse of velocity a problem?
- Because velocity values are defined identically across all teams
- Because only the Product Owner is allowed to view velocity
- Because each team estimates in its own way, so velocity is not comparable between teams and says little about real value delivered
- Because comparing teams automatically violates the Definition of Done
Correct answer: Because each team estimates in its own way, so velocity is not comparable between teams and says little about real value delivered
Comparing teams by velocity is a problem because each team estimates in its own way, so velocity is not comparable between teams and says little about real value delivered. Velocity values are not standardized across teams, viewing velocity is not restricted to the Product Owner, and such comparisons do not implicate the Definition of Done. Velocity is an internal forecasting aid, not a cross-team productivity score.
- A Scrum Master notices the team treats a high velocity number as the goal of each Sprint. What is the most accurate coaching point about value?
- Velocity is the true objective of a Sprint and should be maximized
- The Sprint Goal and delivering valuable outcomes matter more than the velocity number, which is only a forecasting aid
- Velocity should replace the Sprint Goal to simplify planning
- Velocity must increase every Sprint or the team has failed
Correct answer: The Sprint Goal and delivering valuable outcomes matter more than the velocity number, which is only a forecasting aid
The most accurate coaching point is that the Sprint Goal and delivering valuable outcomes matter more than the velocity number, which is only a forecasting aid. Velocity is not the objective of a Sprint, it should not replace the Sprint Goal, and it is not required to rise every Sprint. Keeping focus on value rather than the number prevents the metric from distorting behavior.
- A team currently has no way to visualize how much work remains in the Sprint and considers adding a burndown chart. Which statement is accurate about doing so?
- A burndown chart is one of the Scrum artifacts and must be maintained
- A burndown chart is forbidden because it is not named in the Scrum Guide
- A burndown chart can only be created by the Product Owner
- A burndown chart is an optional complementary tool that can support transparency without being required by Scrum
Correct answer: A burndown chart is an optional complementary tool that can support transparency without being required by Scrum
A burndown chart is an optional complementary tool that can support transparency without being required by Scrum. It is not one of the three Scrum artifacts, it is not forbidden simply for being absent from the Scrum Guide, and its creation is not limited to the Product Owner. Teams may use it when it helps, but Scrum does not mandate it.
- If a burndown chart shows remaining work flattening rather than declining toward the Sprint Goal, what is the most useful interpretation?
- The chart proves the team has failed the Sprint and must be cancelled
- It is a signal worth inspecting and discussing so the Developers can adapt their plan, since the chart itself is just a visualization
- The chart automatically resets the Sprint length
- The chart must be hidden from stakeholders to avoid concern
Correct answer: It is a signal worth inspecting and discussing so the Developers can adapt their plan, since the chart itself is just a visualization
A flattening burndown is a signal worth inspecting and discussing so the Developers can adapt their plan, since the chart itself is just a visualization of remaining work. It does not prove failure requiring cancellation, it cannot reset the Sprint length, and hiding it would undermine transparency. The chart's value lies in prompting inspection and adaptation, not in dictating outcomes.
- When ordering the Product Backlog, a Product Owner discovers that one valuable item depends on another item being completed first. How should this dependency influence ordering?
- Dependencies should be ignored because only raw value matters
- Both items must always be built in the same Sprint
- The prerequisite item should generally be ordered ahead so the dependent valuable item can be delivered
- The dependent item should be deleted to avoid complexity
Correct answer: The prerequisite item should generally be ordered ahead so the dependent valuable item can be delivered
The prerequisite item should generally be ordered ahead so the dependent valuable item can be delivered, because the Product Owner weighs dependencies alongside value when sequencing the backlog. Dependencies cannot simply be ignored, the two items need not be forced into one Sprint, and deleting valuable work to avoid complexity sacrifices value. Sequencing around dependencies keeps delivery feasible and value-focused.
- A Product Owner has not updated the Product Backlog ordering for several Sprints even though market conditions and stakeholder feedback have changed substantially. Why is this a concern for value-driven ordering?
- Because the ordering would no longer reflect current value and priorities, so the team may keep building lower-value work
- Because the Scrum Guide requires re-ordering the backlog exactly once per day
- Because only the Scrum Master is permitted to refresh the ordering
- Because an unchanged order automatically cancels the next Sprint
Correct answer: Because the ordering would no longer reflect current value and priorities, so the team may keep building lower-value work
A stale ordering is a concern because the order would no longer reflect current value and priorities, so the team may keep building lower-value work while higher-value opportunities wait. Scrum sets no daily re-ordering rule, ordering is the Product Owner's accountability rather than the Scrum Master's, and an unchanged order does not cancel a Sprint. Keeping the order current is how ordering serves value.
- A Product Owner asks a business analyst to maintain the day-to-day details of the Product Backlog. Under Scrum, what remains true about accountability for the backlog?
- The Product Owner remains accountable even though others may do the work
- The business analyst now holds the accountability for the Product Backlog
- Accountability is shared equally between the analyst and the Developers
- The Scrum Master becomes accountable once delegation occurs
Correct answer: The Product Owner remains accountable even though others may do the work
The Product Owner remains accountable even though others may do the work, because Scrum allows the Product Owner to delegate tasks like backlog maintenance while keeping sole accountability. Delegation does not transfer accountability to a business analyst, split it among the Developers, or hand it to the Scrum Master. The Product Owner stays the single accountable person for the product.
- For the Product Owner to succeed in maximizing product value, what does Scrum say the rest of the organization must do regarding the Product Owner's decisions?
- Override those decisions whenever a senior manager disagrees
- Respect those decisions rather than telling Developers to work from a different set of requirements
- Require a committee to ratify each ordering decision
- Limit the Product Owner to communicating only through the Scrum Master
Correct answer: Respect those decisions rather than telling Developers to work from a different set of requirements
The organization must respect the Product Owner's decisions rather than telling Developers to work from a different set of requirements, because that respect is what lets the Product Owner remain effective. Letting managers override at will, requiring committee ratification, or forcing all communication through the Scrum Master would all undermine the single accountable decision-maker. Visible decisions in the backlog must be honored across the organization.
- Two people in an organization both claim to be the Product Owner for the same product and issue conflicting priorities to the Developers. Why does Scrum consider this arrangement invalid?
- Because the Developers are not allowed to receive priorities from anyone
- Because two Product Owners would each need their own Scrum Master
- Because the Product Owner must be a single person, not a committee or a pair sharing the accountability
- Because a product is only permitted to have one Sprint at a time
Correct answer: Because the Product Owner must be a single person, not a committee or a pair sharing the accountability
The arrangement is invalid because the Product Owner must be a single person, not a committee or a pair sharing the accountability. The problem is not a missing second Scrum Master, a ban on Developers receiving priorities, or any rule about simultaneous Sprints. Having one accountable person is what keeps backlog ordering coherent and conflict-free.
- Who participates in Product Backlog refinement?
- Only the Product Owner, working alone
- Only the Scrum Master, who runs it as an official event
- Only external stakeholders invited by management
- The Product Owner and the Developers collaborating, with the Developers responsible for sizing
Correct answer: The Product Owner and the Developers collaborating, with the Developers responsible for sizing
The Product Owner and the Developers collaborate on refinement, with the Developers responsible for sizing the items they will work on. Refinement is not the Product Owner working alone, not a Scrum-Master-run event, and not something handed to external stakeholders. It is a shared activity where those who do the work judge the size.
- A team spends large blocks of an entire Sprint refining items that are far down the Product Backlog and unlikely to be worked on soon. What is the most accurate critique of this behavior?
- Detailing distant, low-ordered items risks wasted effort because those items may change or never be selected
- Refinement is forbidden during a Sprint, so all of it is wasted
- Only the Product Owner is allowed to refine, so the Developers should stop entirely
- Refinement must always consume a fixed percentage of every Sprint
Correct answer: Detailing distant, low-ordered items risks wasted effort because those items may change or never be selected
Detailing distant, low-ordered items risks wasted effort because those items may change or never be selected, so refinement should focus on items nearing selection. Refinement is not forbidden during a Sprint, it is not restricted to the Product Owner alone, and Scrum mandates no fixed percentage of effort for it. Just-in-time refinement of higher-ordered items is the efficient approach.
- During refinement, the Developers and Product Owner break a large Product Backlog item into several smaller items. What is the main benefit of doing this?
- It guarantees the team will finish the original item this Sprint
- It lets smaller, well-understood pieces be completed within a Sprint and delivered incrementally
- It removes the need to ever estimate the work
- It transfers ownership of those items to the Scrum Master
Correct answer: It lets smaller, well-understood pieces be completed within a Sprint and delivered incrementally
Breaking a large item into smaller pieces lets smaller, well-understood pieces be completed within a Sprint and delivered incrementally. It does not guarantee completion of the original whole, it does not eliminate estimation, and it does not move ownership to the Scrum Master. Decomposing work improves flow and the chance of finishing usable increments.
- A Product Owner must choose between two backlog items of similar cost: one delights a small set of paying customers and one slightly improves an internal report few people read. From a value-maximizing standpoint, which item should generally be ordered first?
- The internal report, because internal work is always safer
- Whichever item the Developers find more technically interesting
- The item that delights paying customers, because it delivers greater value for similar cost
- Neither, until every stakeholder has signed off in writing
Correct answer: The item that delights paying customers, because it delivers greater value for similar cost
The item that delights paying customers should generally be ordered first, because it delivers greater value for similar cost. Defaulting to internal work for safety, choosing by developer interest, or freezing the decision pending universal sign-off all ignore value. Comparing benefit against cost is how the Product Owner maximizes value.
- Which approach best helps a Product Owner judge whether delivered work actually produced value?
- Counting how many Product Backlog items were marked Done
- Confirming the burndown chart reached zero
- Measuring how many hours the Developers logged
- Gathering evidence of real outcomes, such as customer adoption or business results, after release
Correct answer: Gathering evidence of real outcomes, such as customer adoption or business results, after release
Gathering evidence of real outcomes, such as customer adoption or business results after release, best shows whether work produced value. Counting Done items, logging developer hours, or watching the burndown reach zero measure output and effort, not the value realized. Value is judged by outcomes, not by the volume of work completed.
- A stakeholder pressures the Product Owner to keep building features for a product line that data shows is steadily losing users and revenue. What value-focused response is most consistent with the Product Owner's accountability?
- Weigh the declining returns and consider reordering or stopping investment in favor of higher-value work
- Comply immediately, since stakeholder requests always take precedence
- Refer the entire decision to the Scrum Master to settle
- Hide the data so the stakeholder stays satisfied
Correct answer: Weigh the declining returns and consider reordering or stopping investment in favor of higher-value work
The Product Owner should weigh the declining returns and consider reordering or stopping investment in favor of higher-value work. Automatically complying ignores value, handing the decision to the Scrum Master misplaces accountability, and hiding data breaks transparency. Directing investment toward where it produces the most value is the heart of the role.
- Who, at minimum, should be present at a Sprint Review for it to serve its purpose well?
- Only the Scrum Master and a manager
- The Scrum Team together with key stakeholders invited by the Product Owner
- Only the Developers
- Only external auditors
Correct answer: The Scrum Team together with key stakeholders invited by the Product Owner
The Scrum Team together with key stakeholders invited by the Product Owner should attend, because the review is a working session to inspect the Increment and gather feedback. It is not just the Scrum Master and a manager, not the Developers alone, and not an audit. Bringing the team and the right stakeholders together is what makes the collaboration valuable.
- A Scrum Team turns its Sprint Review into a one-way slideshow where the Product Owner presents and stakeholders simply watch. Why does this weaken the event?
- Because only the Scrum Master is allowed to present at the review
- Because slideshows are explicitly banned by the Scrum Guide
- Because the review is meant to be a collaborative working session that gathers stakeholder feedback, not a passive presentation
- Because the review must always run the full four-hour timebox
Correct answer: Because the review is meant to be a collaborative working session that gathers stakeholder feedback, not a passive presentation
A one-way slideshow weakens the event because the review is meant to be a collaborative working session that gathers stakeholder feedback, not a passive presentation. Slideshows are not specifically banned, the Scrum Master is not the required presenter, and the four-hour figure is a maximum, not a required duration. Two-way collaboration is what feeds backlog adaptation.
- How should the feedback gathered from stakeholders during a Sprint Review most directly affect the product?
- It is recorded for compliance but rarely acted upon
- It is sent only to management and withheld from the Scrum Team
- It automatically becomes the next Sprint Backlog without discussion
- It informs adjustments to the Product Backlog that shape upcoming work
Correct answer: It informs adjustments to the Product Backlog that shape upcoming work
Stakeholder feedback should inform adjustments to the Product Backlog that shape upcoming work, which is the point of inspecting the Increment together. It is not merely filed for compliance, it does not bypass discussion to become the next Sprint Backlog, and it is not hidden from the Scrum Team. Feedback closing the loop into the backlog keeps the product valuable.
- How does Scrum treat formal, fixed long-term release plans created entirely up front?
- It favors empirical, adaptive release decisions that evolve as the product and feedback evolve
- It mandates a detailed twelve-month release plan before any Sprint begins
- It forbids any planning beyond the current Sprint
- It requires the Scrum Master to approve every release date in advance
Correct answer: It favors empirical, adaptive release decisions that evolve as the product and feedback evolve
Scrum favors empirical, adaptive release decisions that evolve as the product and feedback evolve, rather than locking everything up front. It does not mandate a fixed twelve-month plan, does not forbid looking beyond the current Sprint, and does not make the Scrum Master a release-date approver. Release planning is treated as an ongoing, evidence-driven activity.
- A new product team wants to start getting real customer feedback as early as possible. Which release approach best supports that goal under Scrum?
- Hold all work back and release one complete product after a year
- Release a small but valuable slice early, then expand based on what customers do
- Release only after every planned feature is fully built
- Avoid releasing until the Product Backlog is empty
Correct answer: Release a small but valuable slice early, then expand based on what customers do
Releasing a small but valuable slice early, then expanding based on what customers do, best supports getting early feedback. Holding everything for a single yearly release, waiting until every feature is built, or waiting for an empty backlog all delay learning. Early incremental delivery surfaces real-world feedback when it is most useful.
- What is the relationship between producing an Increment each Sprint and releasing to customers?
- Every Increment must be released to customers the moment the Sprint ends
- Increments are never released; only the final product is
- An Increment must be usable each Sprint, but the timing of release is a separate value decision
- Releasing is required only when the Scrum Master schedules it
Correct answer: An Increment must be usable each Sprint, but the timing of release is a separate value decision
An Increment must be usable each Sprint, but the timing of release is a separate value decision belonging to the Product Owner. Increments need not all be released the moment a Sprint ends, they are not withheld until a single final product, and release timing is not the Scrum Master's call. Building a releasable Increment and choosing when to release are distinct concerns.
- A manager insists the Developers sign a guarantee that every item pulled into Sprint Planning will be completed. How does this conflict with Scrum?
- It does not conflict; Scrum requires such completion guarantees
- It conflicts because Developers are never allowed to select any items
- It conflicts because only the Product Owner may pull items into the Sprint
- It conflicts because selected items are a forecast, not a guaranteed contract of completion
Correct answer: It conflicts because selected items are a forecast, not a guaranteed contract of completion
Demanding a completion guarantee conflicts with Scrum because selected items are a forecast, not a guaranteed contract of completion. Developers do select items, the Developers (not only the Product Owner) decide how many to take on, and Scrum does not require completion guarantees. Treating the selection as a forecast preserves the empiricism Scrum relies on.
- By the end of a Sprint, the Developers completed fewer Product Backlog items than forecast, but achieved the Sprint Goal. How should this outcome be viewed?
- As an acceptable outcome, since the Sprint Goal was met and the item list was only a forecast
- As a failed Sprint because the forecast was not fully met
- As grounds to cancel the next Sprint
- As proof the Developers should no longer be allowed to forecast
Correct answer: As an acceptable outcome, since the Sprint Goal was met and the item list was only a forecast
This is an acceptable outcome, since the Sprint Goal was met and the item list was only a forecast rather than a fixed promise. It is not a failed Sprint, not grounds to cancel the next Sprint, and not a reason to strip the Developers of forecasting. Meeting the goal matters more than completing every forecast item.
- Beyond raw business value, which factors does the Product Owner legitimately consider when ordering the Product Backlog?
- Only the alphabetical order of item titles
- Risk, dependencies, and the need for early learning, in addition to value
- Only how long each item has sat in the backlog
- Only the personal preferences of the Developers
Correct answer: Risk, dependencies, and the need for early learning, in addition to value
The Product Owner legitimately considers risk, dependencies, and the need for early learning, in addition to value, when ordering the backlog. Alphabetical order, age in the backlog alone, or developer preference are not the basis for ordering. Balancing value with risk, dependencies, and learning produces a sound order.
- A risky technical assumption underlies several high-value items, and the team is unsure it will work. From an ordering standpoint, why might the Product Owner pull a small item that tests this assumption near the top?
- Because the Scrum Master requires risky work to go first
- Because risky items must always be ordered last
- Because tackling the risk early can validate or invalidate the assumption before more is invested
- Because ordering has nothing to do with risk
Correct answer: Because tackling the risk early can validate or invalidate the assumption before more is invested
The Product Owner might order the risk-testing item near the top because tackling the risk early can validate or invalidate the assumption before more is invested. Risky items are not required to go last, ordering is not dictated by the Scrum Master, and risk is a legitimate ordering factor. Reducing uncertainty early protects the value of dependent work.
- When may the Product Owner change the order of the Product Backlog?
- Only during Sprint Planning
- Only with written approval from the Developers
- Only once per release
- At any time, since the Product Backlog is dynamic and continuously refined
Correct answer: At any time, since the Product Backlog is dynamic and continuously refined
The Product Owner may change the order at any time, since the Product Backlog is dynamic and continuously refined. Reordering is not confined to Sprint Planning, not limited to once per release, and not gated on written Developer approval. Keeping the order responsive to new information is part of maximizing value.
- After a Sprint is cancelled, what happens to any completed and Done Product Backlog items from that Sprint?
- Any Done items may be reviewed and potentially accepted, while incomplete items are re-estimated and returned to the Product Backlog
- They are discarded along with the cancelled Sprint
- They are automatically released to customers without review
- They must be rebuilt from scratch in the next Sprint
Correct answer: Any Done items may be reviewed and potentially accepted, while incomplete items are re-estimated and returned to the Product Backlog
When a Sprint is cancelled, any Done items may be reviewed and potentially accepted, while incomplete items are re-estimated and returned to the Product Backlog. Completed work is not simply discarded, not auto-released without review, and not needlessly rebuilt. Cancellation preserves usable work and recycles the rest into the backlog.
- A senior executive outside the Scrum Team orders a Sprint cancelled because priorities shifted. Within Scrum, how should this be handled?
- The executive's order automatically cancels the Sprint
- The decision rests with the Product Owner, who may cancel the Sprint if the Sprint Goal has become obsolete
- The Scrum Master must cancel it on the executive's behalf
- The Developers vote on whether to honor the order
Correct answer: The decision rests with the Product Owner, who may cancel the Sprint if the Sprint Goal has become obsolete
The decision rests with the Product Owner, who may cancel the Sprint if the Sprint Goal has become obsolete. An executive's order does not automatically cancel a Sprint, the Scrum Master cannot do it on their behalf, and there is no Developer vote. Even with shifted priorities, only the Product Owner holds the cancellation authority.