User Stories Acceptance Criteria
User Stories Acceptance Criteria are clear, testable conditions that a user story must meet for the Product Owner to accept it. Created collaboratively during backlog refinement and confirmed before sprint commitment, they guide estimation, development, testing, and review. In SBOK, they accompany the story as an output of creating user stories and an input to estimation, tasking, and validation processes.
Key Points
- Concise, testable conditions that prove a user story fulfills its intended value.
- Co-created by the Product Owner and the Scrum Team during refinement and finalized prior to sprint commitment.
- Drive estimation, task breakdown, acceptance tests, and serve as a Definition of Ready checkpoint.
- Used throughout the sprint to verify progress and at the Sprint Review to accept or reject the story.
- Include functional and non-functional needs (performance, security, usability) where relevant.
- Linked in SBOK to Create User Stories (output), Approve-Estimate-Commit User Stories (input), Create Tasks (input), and Demonstrate and Validate Sprint (acceptance).
Purpose
Acceptance criteria align expectations between stakeholders and the team, making scope explicit and measurable. They reduce ambiguity, support better estimates, and enable objective acceptance at the end of the sprint.
They also seed acceptance tests (manual or automated), making quality visible and helping prevent rework and scope creep.
Key Terms & Clauses
- Given-When-Then: A common format for writing testable scenarios (context, action, expected result).
- Definition of Ready (DoR): A team checklist; having clear acceptance criteria is often a DoR item for pulling a story into a sprint.
- Definition of Done (DoD): Quality bar for increments; acceptance criteria are story-specific, while DoD is universal for all work.
- Non-functional criteria: Constraints such as performance, security, accessibility, and reliability included when they matter.
- Business rules: Domain rules that must be reflected in the acceptance criteria for correctness.
- Acceptance tests: Test cases derived directly from acceptance criteria to prove compliance.
How to Develop/Evaluate
- Collaborate early: During backlog refinement, the Product Owner, developers, and testers draft criteria together.
- Use examples: Capture realistic scenarios, including edge cases and negative paths.
- Prefer Given-When-Then: Write each condition as an observable outcome with clear inputs and results.
- Cover non-functional needs: Add measurable thresholds (e.g., response time, security checks) where relevant.
- Check quality: Ensure criteria are clear, unambiguous, testable, and minimal yet sufficient.
- Confirm readiness: Before Sprint Planning commitment, verify criteria meet DoR and are understood by the team.
How to Use
Use acceptance criteria to size the story, identify tasks, and write acceptance tests. During the sprint, they guide development and validation; at the Sprint Review, they provide the pass/fail basis for acceptance.
- SBOK linkage - Output: Created in Create User Stories as part of each PBI.
- SBOK linkage - Input: Refined in Approve, Estimate, and Commit User Stories to support estimation and commitment.
- SBOK linkage - Input: Feed Create Tasks and Create Sprint Backlog, shaping development and testing work.
- SBOK linkage - Input: Used in Demonstrate and Validate Sprint to determine acceptance and in Accept Deliverables for final confirmation.
Example Snippet
User story: As a user, I want to reset my password so I can regain access.
- Given a registered email, when I request a reset, then a one-time link is sent within 1 minute.
- Given an unregistered email, when I request a reset, then I see a generic message without revealing account existence.
- Given a valid reset link, when I set a new password, then I am prompted to log in with the new password.
- Given a reset link, when 30 minutes have passed, then the link is invalid and I must request a new one.
- The process complies with password policy and logs events for audit.
Risks & Tips
- Risk - Ambiguity: Vague criteria lead to rework; mitigate by using concrete examples and measurable outcomes.
- Risk - Over-specification: Prescribing design limits options; state outcomes, not implementation.
- Risk - Scope creep: New conditions mid-sprint disrupt flow; manage via backlog refinement and change control.
- Tip: Keep criteria minimal yet complete; 3-7 well-formed conditions is typical for a small story.
- Tip: Pair the Product Owner with QA or a developer to draft and review criteria before commitment.
- Tip: Trace each criterion to one or more acceptance tests and automate where feasible.
PMP/SCRUM Example Question
During Sprint Planning, the team finds several high-priority user stories without clear acceptance criteria. What should the Scrum Master encourage the team to do next?
- Start development and clarify acceptance criteria during the Daily Standup.
- Ask the Scrum Master to write the acceptance criteria so the team can proceed.
- Collaborate with the Product Owner to define and agree on acceptance criteria before committing to the stories.
- Add a note to the Sprint Backlog that criteria will be finalized at the Sprint Review.
Correct Answer: C — Collaborate with the Product Owner to define and agree on acceptance criteria before committing to the stories.
Explanation: Clear, testable acceptance criteria are an input to estimation and commitment. Stories should meet the team’s Definition of Ready before entering the sprint.
HKSM