Product Discovery
Write acceptance criteria with concrete examples
Acceptance criteria should let business and delivery teams recognize the same result. Use concrete starting conditions, actions, and observable outcomes to expose ambiguous rules before they turn into disputed acceptance decisions.
A requirement such as users can update orders sounds clear until two people disagree about which orders, which changes, and what happens afterward. Acceptance criteria turn that broad intention into observable behavior. Concrete examples help the buyer and the delivery team discover disagreements while changes are still relatively easy to discuss.
Start with the rule and its boundary
Name the business rule before describing a screen. Specify the actor, the relevant state, and the condition that permits an action. Distinguish a customer request from an authorized change. Decide whether the rule applies to imported records and staff actions as well.
Use a simple structure: given a known condition, when a named actor acts, then an observable result follows. This is a writing recommendation, not a requirement to adopt a particular testing tool. Keep internal implementation details out unless they are genuinely part of the acceptance obligation.
Add examples that force a decision
For each important rule, write an ordinary case, a boundary case, and a prohibited case. Replace words such as promptly or valid with a condition the reviewers can assess. If a threshold remains unknown, name its decision owner rather than inventing a number.
Where a rule controls access, include denied actions as well as successful ones. OWASP recommends tests that validate the permissions defined during design.[6] Ask what state remains after a denial, not only which message appears. An error message alone does not prove that no change occurred.
Hypothetical example: changing a dispatch address
A hypothetical stationery supplier allows customers to change an address before warehouse release. One example starts with an unreleased order and an authorized customer. After a valid change, the order shows the revised address and the previous value remains available to permitted staff.
A contrasting example starts after warehouse release. The direct edit is refused, the dispatch address remains unchanged, and the customer receives the agreed support route. The team still must decide what warehouse release means and how the system learns that state.
Review examples with this checklist
Walk through the examples with the business owner, a user representative, and the delivery team. Resolve different interpretations before treating the criteria as ready.
- State the starting record, actor, permissions, and relevant business state.
- Identify the single action under review.
- Describe the observable result and any state that must remain unchanged.
- Include one boundary or prohibited case for each important rule.
- Assign unresolved terminology to a named decision owner.
Keep acceptance and shared quality distinct
In Scrum, the Definition of Done describes the quality state required for an Increment.[5] Feature acceptance examples do not replace that broader agreement. They describe specific behavior, while shared checks can cover concerns that apply across features.
Exhaustive examples are impossible for a complex workflow. Prioritize cases that distinguish competing interpretations and carry meaningful consequences. Keep criteria understandable enough for business review, then let technical tests cover additional combinations without turning the acceptance conversation into an unreadable specification.
