HKSM
User Story Acceptance Criteria
Each user story includes specific, testable conditions that remove ambiguity and make the outcome measurable. These acceptance criteria define the pass/fail standards used at Sprint Review to decide if the story is Done or not Done and clarify exactly what the team must deliver.
Key Points
- Every user story must have clear, testable acceptance criteria.
- They convert subjective intent into objective pass/fail conditions.
- Agreed by the product owner and team before implementation and used to guide development and testing.
- Checked at Sprint Review to decide Done/Not Done and complement (not replace) the Definition of Done.
Example
Story: As an online shopper, I want to save items to a wishlist so I can purchase them later. Acceptance criteria: user can add an item to the wishlist from the product page; the wishlist persists after logout/login; removing an item updates the count immediately; the feature works on mobile and desktop; and all criteria are verified by functional tests. These criteria let the team decide objectively at Sprint Review whether the story is Done.
PMP Example Question
What is the primary purpose of acceptance criteria for a user story?
- To document the technical design and architecture of the solution
- To define objective conditions of satisfaction used to determine if the story is Done
- To replace the Definition of Done for the product
- To assign tasks to individual developers during the sprint
Correct Answer: B — Objective conditions of satisfaction to determine if the story is done
Explanation: Acceptance criteria make the story measurable and binary (pass/fail) at Sprint Review; they do not capture design, replace the Definition of Done, or allocate tasks.
