Three artifacts, three different questions
Scrum makes work and its commitments inspectable through the Product Backlog, Sprint Backlog and Increment. Their commitments are the Product Goal, Sprint Goal and Definition of Done respectively. The Product Goal provides a direction for the product. The Sprint Goal gives the Sprint a single objective. The Definition of Done supplies the quality boundary used to understand an Increment. These commitments do not promise that every selected feature will be completed exactly as first imagined. Keep the questions separate: Where is the product heading? Why are we undertaking this Sprint? What quality state has the completed work actually reached?
Feature examples do not replace product quality
A team may write acceptance examples or acceptance criteria to clarify a particular item. These can describe a user-visible result or an important business rule. The Scrum Guide does not prescribe acceptance criteria as an additional artifact or commitment. They are a local practice, not a universal second checklist mandated by Scrum. If a team uses them, compare them with the product-wide Definition of Done rather than treating them as synonyms. Passing a feature example can coexist with failing a required integration, accessibility or other quality check. Never infer completed quality from only the easiest visible demonstration.
Worked example: a useful feature with unfinished quality work
Fictional case: a venue’s ticketing product adds a waiting-list notification. The agreed feature example checks that a subscriber receives a message when seats reopen. That example passes, but an organization-required security check has not run. First identify the stated quality boundary; do not decide the technical check is optional because the example looks convincing. Second compare evidence against that boundary. Third describe the item as unfinished and return it to the Product Backlog for future consideration if it still fails Done at Sprint end. The Product Owner and Developers can discuss future scope, but nobody should relabel the missing check as completed.
Shared boundaries and release timing
If the organization provides a Definition of Done standard, teams follow it as a minimum. If it does not, the Scrum Team establishes an appropriate Definition of Done. Multiple Scrum Teams working on one product must mutually define and follow the same Definition of Done. The Developers conform to that boundary while creating Increments. Once work genuinely meets it, do not invent an extra Scrum rule that release must wait for Sprint Review. Multiple Increments may exist in one Sprint, and delivery can happen before Sprint end. Product, legal or operational decisions may still influence actual release timing; the Guide’s statement does not make those concerns disappear.
Transfer check and next practice
Try a changed case without looking back: a reporting item meets all required quality measures on day six, but a stakeholder asks the team to wait for a coordinated announcement. Is the item unfinished solely because it has not yet been released? No. Release timing and the Definition of Done are different decisions. Now change the premise again: a required integration check fails. That is a quality-boundary problem, so the work is not part of a Done Increment. Practice the four linked questions, retrieve the associated cards, and explain which explicit premise changes the conclusion. The goal is a defensible explanation, not recall of a preferred answer position.
A ticketing product has an organizational Definition of Done requiring a security check. One Scrum Team agrees that a particular low-risk change can skip that check to meet a requested launch date. Which response best respects the Scrum Guide?
- The scenario explicitly makes the security check part of the organizational Definition of Done. That standard remains a minimum for every Scrum Team. A value or scheduling decision does not turn unfinished quality work into a Done Increment. The team can discuss scope and delivery options, but it must not claim that the unchanged quality boundary has been met. No conclusion about the actual technical risk of this fictional change is required.
Compare the other answer choices
The Product Owner is accountable for value, but this does not authorize waiving the organizational Definition of Done.
Self-management operates within applicable constraints. A local vote does not replace the stated organizational minimum.
Splitting off the missing check does not make the original item satisfy the quality boundary; the Done claim would be misleading.
Try it, then explain it.
Complete a short set without looking at the example. After each answer, explain which evidence or rule supports your decision and why the alternatives do not fit.
Sources & authorship
Original OpenExam explanations and examples. References support the concepts; they are not the source of copied questions. Independent educator review is pending.
The Scrum Guide — November 2020