At sprint review, the product owner refuses to accept the payment module. It ran flawlessly in the demo — but regression tests never executed, and the developers insist testing "wasn't in scope this sprint." The exam expects you to name what this team is missing, and it isn't effort or talent. It's a definition of done. Artifact and event questions all work this way: a dysfunction appears, and the correct answer identifies which agile mechanism should have prevented it — then repairs the mechanism, not just the symptom.
Two backlogs, two owners, two change rules
The product backlog is the single ordered list of everything the product might need. Anyone can propose items; only the product owner controls content and order. It is deliberately emergent — refined continuously, detailed near the top, coarse further down. Options that freeze it, fork it into side lists, or hand its ordering to a project manager or sponsor are distractors.
The sprint backlog belongs to the developers: the sprint goal, the selected items, and their plan. During the sprint, the developers adapt it as they learn. Nobody pushes work into it mid-sprint — not the PM, not the sponsor, not even the product owner, who negotiates scope with the developers as long as the sprint goal survives. When a stem asks "who can change X mid-sprint," you're being tested on exactly this boundary.
75 free questions, scored against the new domain weights. No card required.
DoD vs. DoR: exit gate vs. entry bar
The definition of done is the quality standard every increment must meet before it counts — tested, integrated, documented, compliant with organizational standards. It applies at the exit: work that hasn't met it isn't "mostly done," it's not done. The definition of ready is the opposite door: an agreement on what a backlog item needs before the team pulls it into a sprint — clear enough, small enough, testable. (DoR is common practice rather than core Scrum, but exam stems use the concept.)
The diagnostic rule that answers most of these questions: quality escaping outward is a DoD problem; churn flowing inward is a readiness problem. Defects reaching production, "done" work that needs rework, undone testing — strengthen and enforce the DoD. Sprints derailed by vague, bloated stories — improve refinement and the readiness bar. One caution the exam occasionally pokes: a rigid DoR enforced as a phase gate recreates mini-waterfall, so the strongest answers improve refinement rather than erect paperwork.
Review vs. retrospective: product loop vs. process loop
The sprint review inspects the product with stakeholders in the room; its output is an adapted backlog. The retrospective inspects the process with only the team; its output is concrete improvement actions. The exam tests the boundary with wrong-venue distractors: interpersonal friction aired at the review (belongs in the retro), stakeholder feedback collected through status reports (belongs in the review), quality standards fixed by adding a manager sign-off (belongs in the retro as a DoD change). And when schedule pressure tempts a team to skip retrospectives, the exam-correct answer keeps the improvement loop running — pressure is when you need it most.
Two exam-style scenarios
Scenario 1. For three consecutive releases, an insurance platform team has shipped increments that pass the demo but produce customer-reported defects within days. What should the project manager do first?
- A. Add a hardening sprint before each release to catch defects
- B. Bring the pattern to the retrospective and strengthen the definition of done to include automated regression coverage
- C. Introduce a dedicated QA stage that reviews all work after each sprint
- D. Review each increment personally before it reaches the sprint review
Answer: B. The defect pattern means "done" is defined too loosely, and the retrospective is the team's mechanism for changing its own standard. A institutionalizes late quality instead of building it in. C adds a handoff and a queue — quality by inspection rather than by construction. D makes the PM a bottleneck and quietly confiscates the team's ownership of quality.
Scenario 2. A regional operations director complains that the last two releases "solve problems we don't have." She has never attended a sprint review, relying instead on the monthly steering report. What should the project manager do?
- A. Expand the steering report with detailed feature descriptions
- B. Require her sign-off on requirements before each sprint begins
- C. Get her (or her delegate) into sprint reviews and feed her input into backlog refinement
- D. Schedule a private demo for her after each release ships
Answer: C. The review is the feedback mechanism she's missing — inspecting the actual increment early enough for the backlog to change course. A substitutes documents for interaction; she'll misread features on paper just as she does now. B bolts a predictive approval gate onto an adaptive flow and delays feedback rather than improving it. D delivers her feedback after release, when adapting is most expensive — the right instinct at the wrong point in the loop.
Study the mechanisms, not the glossary
Notice the pattern across both scenarios: name the broken mechanism, repair it inside the team's own events, keep ownership where it belongs. That's the skeleton under our Scrum-for-the-exam guide as well, and it's how these concepts arrive inside the exam's formats — multiple response, matching, drag-and-drop — which we cover in the 2026 question types guide. When you're ready to test the reflex, ExamElephant's 75 free questions lean hard on artifact-and-event judgment, and the retest engine replays your misses at 3 and 7 days until they're mastered rather than merely familiar.
Paid passes are coming soon
The full 2,100-question bank, timed 180-question mock exams and unlimited tutoring. Leave your email and we'll tell you the day they open. Unsubscribe anytime. Privacy
FAQ
Is the definition of ready an official Scrum artifact?
No — the Scrum Guide defines DoD but not DoR. DoR is widespread practice, and the exam may reference it; treat it as an entry agreement for sprint planning, never a bureaucratic gate.
Who is allowed to change the sprint backlog during a sprint?
The developers. They adapt their plan as they learn. Scope negotiations with the product owner are possible if the sprint goal isn't endangered, but nothing gets pushed in from outside.
Is the sprint review just a demo?
The demo is one ingredient. The review is a working session: stakeholders inspect the increment, discuss progress and market changes, and the product backlog adapts. An option that reduces it to a presentation is usually a distractor.
Can the definition of done change during a project?
Yes — teams strengthen it as they mature, typically via retrospectives. It should never be weakened mid-sprint to make unfinished work count as done.