Original cases distinguish optional feature acceptance examples from the Increment’s quality commitment and from the choice of release timing.
Ask which decision a statement controls
Teams often use the word accepted when they mean several different things: a feature behaves as discussed, the product meets required quality measures, or a stakeholder wants to release it now. A useful conversation first names the decision. Does a particular item deliver the expected behavior? Is the work in a state that qualifies as part of the Increment? Is now a suitable moment to deliver it? These questions interact, but an answer to one is not sufficient evidence for the others. This distinction helps prevent a convincing demonstration from hiding unfinished quality work.
The Scrum Guide defines the Definition of Done as the quality state associated with the Increment. It also connects Product Goal and Sprint Goal to the Product Backlog and Sprint Backlog. Acceptance criteria are not another mandatory artifact or commitment in that Guide. Teams may use item-specific examples to clarify intended behavior. That can be helpful, but the usefulness of a local practice does not make its terminology a rule imposed on every Scrum Team.
Compare two boundaries using a concrete item
Consider an original fictional booking feature: a library member can reserve a study room and cancel before the session starts. The team writes examples for successful reservation, a conflicting booking and cancellation. Those examples focus on this item’s behavior. The product’s Definition of Done requires integration verification and an accessibility check. The team must examine those product quality measures as well when deciding whether the work is part of an Increment.
Suppose the booking examples pass but the required accessibility check is incomplete. Calling the item accepted does not settle whether it is Done. State the missing evidence, keep the quality boundary visible and avoid presenting the item as completed Increment work. At Sprint end, an item that does not meet the Definition of Done returns to the Product Backlog for future consideration. That phrase does not predetermine its order or automatically select it for the next Sprint. Future choices depend on product needs and what the team learns.
Challenge an attractive shortcut
A manager suggests separating the missing check into a new item so that the booking work can count as finished. Creating a tracking record may help make unfinished work visible, but it does not change the original quality requirement. If the feature still fails the Definition of Done, renaming or moving the work has not made it Done. Likewise, stakeholder enthusiasm or a Product Owner’s value priority does not make a failed quality measure pass.
A different shortcut is to assume that every local acceptance example should become part of the Definition of Done. Some examples express item-specific business behavior rather than a quality standard appropriate across the product. Discuss the distinction and choose practices that produce clear evidence. Do not mechanically expand a product-wide checklist with every feature detail. The Guide supplies the quality commitment; this article’s way of organizing a comparison is editorial teaching advice, not a required Scrum template.
Keep common standards common
When an organizational Definition of Done standard applies, Scrum Teams follow it as a minimum. Where there is no such standard, the Scrum Team creates an appropriate definition for the product. When several Scrum Teams work on the same product, they mutually define and comply with the same Definition of Done. An isolated team should not claim a weaker standard simply because its local demonstration seems satisfactory.
Shared quality does not imply that every item has identical behavior examples. Two items can need different examples while remaining subject to the same product quality boundary. Inspect both the specific behavior and the quality evidence when those practices are used. If a requirement is unclear, resolve the uncertainty transparently rather than treating a missing definition as permission to declare completion.
Separate Done from release permission
Now change the fictional case: the booking item satisfies its applicable Definition of Done on Wednesday. A marketing announcement is planned for Friday. The item does not become unfinished merely because delivery is scheduled later. Conversely, a desired Friday announcement cannot turn incomplete work into a Done Increment. The quality state and the delivery decision should be recorded separately.
The Scrum Guide permits delivery before Sprint end and does not make Sprint Review a release gate. That does not establish that every product has no other release constraints. Keep applicable legal, operational and business considerations explicit. Use the diagram to ask the questions in order: identify the promised behavior, inspect the actual quality evidence, then discuss delivery timing. If evidence fails at the quality step, return to the unfinished work instead of seeking a meeting that can relabel it.
Apply the guide
A local acceptance example passes but a required product quality check fails. Can a stakeholder approval make the item Done? Explain.Reveal explanation
No. Approval does not supply the missing quality evidence or satisfy the unchanged Definition of Done. The item remains unfinished.
An item meets Done on Tuesday and delivery is scheduled for Thursday. Does the schedule alone mean it is unfinished?Reveal explanation
No. Meeting the quality boundary and choosing the delivery time are separate. Sprint Review is not a required release gate.
Turn the idea into practice.
Apply the rule to a new case, then explain your choice.
Practice this skillSources & authorship
Scrum Guide November 2020 supports the quality and delivery rules. Acceptance examples are described as optional local practice. Archived material was used privately to identify confusion and was checked against the Guide.
Original OpenExam cases, explanation and SVG; no examination items reproduced.
Independent educator review is pending. This guide is not an official exam paper or a video transcript.
The Scrum Guide — November 2020