Write Acceptance Criteria with Concrete Examples
Turn a user need into observable acceptance criteria, including failure cases and boundaries, without prescribing every implementation detail.
Start with the behavior
Acceptance criteria describe the conditions an individual item must satisfy. Begin with the user's action and an observable result. “The form is intuitive” leaves too much room for interpretation. “When a required field is empty, submission is prevented and that field has an explanatory message” gives design, engineering, and testing a shared example. Discuss the outcome before choosing a technical implementation.
Cover a normal example
For an illustrative appointment feature, describe a user selecting an available time, confirming the appointment, and seeing the agreed confirmation details. Specify relevant boundaries such as the displayed time zone. Use concrete examples to uncover ambiguity, then generalize the rule where appropriate. Do not turn every possible input into a separate criterion when a clear rule and representative examples would be easier to maintain.
Explore failure and boundary cases
Ask what should happen if the chosen slot is taken before confirmation, the request fails, or the user submits twice. Decide which cases belong in this item and which require separate work. The vertical story-slicing guide can help keep a useful end-to-end result while controlling scope. Record unresolved questions visibly instead of letting developers and testers make incompatible assumptions independently.
Review before committing
Read the criteria with the people who will implement and verify the work. Ask each person to describe a passing and failing example. Disagreement is useful evidence that the requirement needs refinement. After delivery, review whether the criteria captured the intended behavior and whether the user need was met. Passing a checklist demonstrates conformance to that checklist; product value still requires evidence from actual use.
Published by AgilePro.info under our Editorial Policy. Guidance is based on established delivery practice and is general information, not professional advice for a specific project.