User Story Acceptance Criteria

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.

ICS/OT Cybersecurity Fundamentals — Security Built for Industrial Systems

Industrial control systems cannot be secured like ordinary IT. A forced reboot, aggressive scan, or incompatible patch can interrupt production and create real safety consequences. Effective OT security begins with understanding the systems, constraints, and risks unique to industrial environments.

This course gives IT professionals, engineers, operators, and security practitioners a practical foundation in ICS threats, zone and conduit design, risk assessment, passive asset visibility, and vendor evaluation. You will learn how IEC 62443, NIST CSF, and MITRE ATT&CK for ICS apply where availability and safety come first.

Eight reconstructed incidents—including Stuxnet, Triton, Ukraine 2015, Colonial Pipeline, and PIPEDREAM—show how attackers move through OT environments, what they target, and which defenses could have changed the outcome.

Watch the course preview, then build the vocabulary, frameworks, and judgment needed to take credible first steps in ICS/OT cybersecurity.

Explore the Course


ICS/OT Cybersecurity Fundamentals course preview

Advance your Lean Six Sigma expertise!

HK School of Management helps you take Lean Six Sigma to the next level—without the overwhelm. Master advanced statistical tools, Excel-based analysis, and real-world improvement techniques to solve complex problems with confidence. For the price of lunch, you get practical templates, guided examples, and hands-on project experience you can use immediately at work. Backed by our 30-day money-back guarantee—zero risk, real impact.

Learn More