HKSM

Specific, testable conditions that a user story must meet for the Product Owner to accept it. They clarify scope, guide development and testing, and form the basis for acceptance during the Sprint Review. In SBOK, they are created and refined during backlog grooming and Sprint Planning and used as inputs to tasking, estimation, and validation.

Key Points

• Owned by the Product Owner but created collaboratively with the team and stakeholders.
• Written as clear, measurable, pass-or-fail conditions for a single user story.
• Input to estimation, tasking, acceptance testing, and Sprint commitment decisions.
• Output from Create User Stories and Approve, Estimate, and Commit User Stories processes in SBOK.
• Used during Create Deliverables and Demonstrate and Validate Sprint to confirm acceptance.
• Complement the Definition of Done; they specify story-level behavior, not general quality bars.

Purpose

Acceptance criteria ensure a shared understanding of what is in scope and what success looks like for a user story. They reduce ambiguity, align expectations, and prevent rework by translating needs into verifiable outcomes.

They also enable reliable estimation, support test-first approaches, and provide a clear basis for Product Owner acceptance in the Sprint Review.

Key Terms & Clauses

• Given-When-Then: A simple behavior format to express preconditions, action, and expected outcome.
• Functional and non-functional: Include behavior, performance, security, usability, and reliability conditions.
• Out-of-scope clause: States what is explicitly excluded to avoid gold-plating.
• Assumptions and data boundaries: Define inputs, ranges, formats, and constraints.
• Definition of Done vs acceptance criteria: DoD is global; acceptance criteria are story-specific checks.

How to Develop/Evaluate

1. Collaborate: Product Owner, Developers, and testers discuss the story during refinement and Sprint Planning.
2. Draft criteria: Write 3–7 concise, testable conditions using plain language or Given-When-Then.
3. Cover NFRs: Add performance, security, accessibility, and usability as applicable.
4. Make measurable: Use concrete thresholds, data values, and pass-or-fail results.
5. Evaluate quality: Check INVEST, clarity, and testability; peer review with the team.
6. Confirm readiness: Treat strong acceptance criteria as part of the Definition of Ready before commitment.

How to Use

• Backlog refinement: Update and split stories based on acceptance criteria to improve sizing and ordering.
• Sprint Planning: Use criteria to decide commitment, clarify scope, and derive tasks and test cases.
• Development and testing: Implement only what is needed to pass the criteria; create automated checks where feasible.
• Demonstrate and Validate Sprint: Show evidence that each criterion passes; Product Owner accepts or rejects the story.
• Learning loop: Capture gaps in Retrospect Sprint and improve how criteria are written next sprint.

Example Snippet

User story: As a user, I want to reset my password so that I can regain access to my account.

• 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 success message and no email is sent.
• Given a valid reset link, when I set a new password, then the old password no longer works.
• Reset link expires after 15 minutes or after first use.
• Password must meet defined complexity and provide inline feedback.

Risks & Tips

• Risk: Vague criteria cause rework. Tip: Use concrete data, thresholds, and observable outcomes.
• Risk: Over-specifying technical design. Tip: Describe behavior, not implementation.
• Risk: Ignoring non-functional needs. Tip: Add performance, security, and accessibility checks.
• Risk: Mid-sprint changes. Tip: Negotiate scope; split or move changes to a new story if impact is significant.
• Risk: Too many criteria. Tip: Keep to essentials and split the story if criteria grow beyond a small set.
• Risk: Criteria not visible. Tip: Keep them with the backlog item and link to acceptance tests.

PMP/SCRUM Example Question

During Sprint Planning, the team finds a selected user story has vague acceptance criteria. What should the Scrum Master do?

1. Proceed with the story and let developers draft criteria during the sprint.
2. Facilitate a conversation between the Product Owner and team to define clear, testable acceptance criteria before commitment.
3. Add detailed technical design steps to the acceptance criteria to remove ambiguity.
4. Split the story into tasks first and estimate later during the sprint.

Correct Answer: B — Facilitate a conversation between the Product Owner and team to define clear, testable acceptance criteria before commitment.

Explanation: Acceptance criteria should be clear and testable before the team commits. This supports reliable estimation and ensures a shared understanding of scope.