“Customers can apply a discount code at checkout” leaves several decisions open. The team still needs to know which codes are eligible, whether discounts can be combined and what happens when a promotion expires while someone is paying. Acceptance criteria make those decisions explicit enough for Product, Engineering and QA to examine the same behaviour before implementation.
For a Product Owner, the useful starting point is the outcome a person needs and the rules that constrain it. A criterion should provide enough context to decide whether the agreed behaviour has been achieved. That takes a conversation about actual cases; adding “works correctly” to a ticket leaves the original uncertainty in place.
What an acceptance criterion needs to settle
Acceptance criteria describe the conditions under which a particular piece of work meets the agreed expectations. They can cover a successful action, a restriction, a failure or a measurable quality requirement. Their wording should connect an identifiable situation with an observable result, so that two people reviewing the same case can discuss evidence rather than different interpretations.
The Product Owner brings the intended value and business rules to that discussion. Developers contribute constraints and implementation questions, while QA helps identify missing cases and ways to verify them. The person who records the result may vary. Scrum does not prescribe an acceptance-criteria template or require the Product Owner to write every criterion alone.
A checkout example: making the discount rules visible
In this hypothetical example, Mercato is an online shop introducing a code called SAVE10. The team agrees that it gives a 10% reduction on the eligible merchandise subtotal before shipping, requires a subtotal of at least €50 and cannot be combined with another promotion. Those are assumptions for this example, not universal rules for discounts; tax treatment and rounding would need an explicit agreement with the relevant specialists.
The following criteria turn those agreements into cases that can be checked. They deliberately separate eligibility, calculation and changes to the basket, because a code that succeeds once may become invalid after the customer removes an item.
- For €100 of eligible merchandise with no other promotion, applying SAVE10 displays a €10 discount and a €90 merchandise subtotal before shipping.
- With an eligible subtotal below €50, the code is not applied and the customer sees the minimum-spend requirement.
- An expired or unknown code leaves the total unchanged and displays a message explaining that the code cannot be used.
- When another promotion is already applied, the product explains the incompatibility and does not silently remove the existing promotion.
- If the customer changes the basket, eligibility and the discount are recalculated before the order is confirmed.
The boundary deserves its own check: a €50 subtotal should qualify under the stated rule, while €49.99 should not. The team must also settle when expiry is evaluated and which time zone applies. These details may change the scope of the work. Recording them during refinement avoids leaving a business decision to whoever happens to implement the last validation.
When Given–When–Then helps
Given–When–Then separates the initial context, an action or event, and the expected outcome. It is useful when a condition changes the result, such as a customer's permissions or the state of an order. A short checklist can be clearer for independent rules; forcing every sentence into a scenario can make a simple agreement harder to read.
Given an eligible basket worth €100 with no active promotion, when the customer applies SAVE10, then checkout displays a €10 discount and a €90 merchandise subtotal before shipping.
This wording follows the structure used by Gherkin, the language supported by tools such as Cucumber. A sentence written in this style is not automatically an automated test: executable scenarios also need test code, suitable data and a maintained environment. Agreeing on examples can still be useful when the initial verification is manual.
An integration example: confirmation can be uncertain
Mercato now sends a confirmed order to a fulfilment provider through an API. “The order is sent successfully” leaves the visible status and recovery behaviour undefined. A slow response can mean that the provider never received the request, or that it processed the order but its response was lost. If the product treats both cases as a definite failure and blindly resends the order, it may create duplicate work.
- When the provider confirms receipt, the order records the provider's reference and shows the agreed fulfilment status.
- If the response times out, the order shows that confirmation is pending; it is not shown as a confirmed rejection.
- Before a further submission, the integration checks whether the provider already has the order, or uses a duplicate-prevention mechanism supported by that provider.
- A user without the required fulfilment permission cannot trigger submission or read another merchant's order details.
These criteria require a review of the provider's actual capabilities. If it offers neither a reliable lookup nor a supported way to avoid duplicates, the team needs to agree a different recovery process before promising an automatic retry. The practical guide to APIs explains the request and response concepts behind this discussion; authentication and authorization covers the distinction between identifying a user and allowing an operation.
Acceptance criteria and Definition of Done cover different ground
Acceptance criteria specify expectations for the particular change, such as which discount applies or what a pending confirmation means. The Definition of Done establishes the quality measures the Increment must satisfy. A discount can calculate correctly while the implementation still lacks checks required by the team's Definition of Done. The reverse is also possible: shared engineering checks can pass while an agreed discount rule is wrong.
In Scrum, work that does not meet the Definition of Done cannot be considered part of the Increment. Passing the acceptance criteria also does not, by itself, settle a launch decision: rollout arrangements, external dependencies and operational readiness may still need review. The difference between deploying a change and releasing it to users helps frame that separate conversation.
Reviewing criteria before implementation
A useful review asks someone who did not draft the criterion to explain how they would verify it. If they need to guess the initial state, invent a test value or choose what “quickly” means, the agreement needs more detail. For performance expectations, that means agreeing a threshold together with the workload and measurement conditions; the threshold alone says little about the experience being promised.
Some questions remain open because a provider's behaviour is unknown or a business rule has not been decided. Make that uncertainty visible and assign the investigation instead of hiding it inside a confident sentence. As the team learns, it can update the examples and discuss whether the change affects scope. A requirement discovered late should be examined explicitly, including its effect on work already agreed.
The book Testing, Bugs, and QA for Product Managers develops the relationship between acceptance criteria, test results and quality decisions for both Product Managers and Product Owners. For the integration case, APIs for Product Managers provides further context on errors, permissions and dependencies.
References
- The Scrum Guide: Product Owner, Product Backlog and Definition of Done.
- Scrum.org: distinguishing Definition of Done and acceptance criteria.
- Cucumber: Gherkin reference and Given–When–Then.