How to Get a Job For Project Managers

Learn how to write resume and interview

Leadership for Project Managers

Learn how to lead and drive project success.

Project Management with AI

From a beginner to project management professional.

Agile Project Management and SCRUM with AI

Learn to run Scrum and Agile with AI.

User Stor y Acceptance Criteria

User story acceptance criteria are clear, testable conditions that a user story must satisfy for the Product Owner to accept it. Created collaboratively during backlog refinement and finalized by Sprint Planning, they guide development, testing, and validation. In SBOK, they act as inputs for estimating and committing stories and as the basis for acceptance during Demonstrate and Validate Sprint.

Key Points

  • Defines the minimum conditions for a user story to be accepted by the Product Owner.
  • Written in clear, testable language that enables objective verification.
  • Co-created by Product Owner and team during backlog refinement; confirmed in Sprint Planning.
  • Acts as input for estimating, task creation, and test case design.
  • Used in Sprint Review to validate done and in SBOK to support Accept Deliverables.
  • Different from Definition of Done, which applies across stories; acceptance criteria are story-specific.

Purpose

The purpose of acceptance criteria is to align stakeholders and the Scrum Team on what success looks like for a specific user story. They remove ambiguity, enable precise estimation, and support effective testing and acceptance.

In SBOK-driven Scrum, they provide a clear handshake between business expectations and technical delivery, improving flow from Create User Stories through Demonstrate and Validate Sprint and Accept Deliverables.

Key Terms & Clauses

  • Given-When-Then: A structured, behavior-focused way to express conditions and outcomes.
  • Functional behavior: Observable outcomes when a user interacts with the system.
  • Nonfunctional constraints: Performance, security, usability, and compliance conditions.
  • Negative paths: Error handling, invalid inputs, or boundary cases to prevent surprises.
  • Edge conditions: Limits for inputs, dates, ranges, and precision rules.
  • Traceability: Each criterion maps back to the user story and test cases.
  • DoD vs acceptance criteria: DoD is a shared quality bar across work; acceptance criteria are unique to a story.

How to Develop/Evaluate

  1. Collaborate early: During backlog refinement, the Product Owner drafts criteria with input from developers and testers.
  2. Focus on outcomes: Describe customer-visible behavior, not internal implementation.
  3. Make them testable: Each criterion must be verifiable via a test case or demonstration step.
  4. Use structured language: Prefer Given-When-Then or clear bullet statements for consistency.
  5. Cover unhappy paths: Include errors, permissions, boundary inputs, and performance targets where relevant.
  6. Right-size for estimation: Ensure criteria are specific enough to support accurate sizing before commitment.
  7. Review in Sprint Planning: Confirm feasibility and shared understanding before the team commits.

How to Use

  • As an Output: From Create User Stories and Refine Prioritized Product Backlog, acceptance criteria are documented alongside the story in the Product Backlog.
  • As an Input: To Estimate User Stories and Commit User Stories, the team relies on criteria to understand scope and complexity.
  • As an Input: To Create Tasks, criteria inform development and testing tasks and acceptance test design.
  • As an Input: During the Sprint and Daily Standup, criteria guide progress checks and clarify done for the story.
  • As an Input: In Demonstrate and Validate Sprint, criteria drive the Sprint Review demonstration and Product Owner acceptance.
  • As Support: For Accept Deliverables and Ship Deliverables, criteria help confirm that increments meet business needs.

Example Snippet

Example acceptance criteria for a generic user story:

  • Given a valid user is logged in, when they submit the form with required fields, then the system saves the data and shows a confirmation message.
  • Given an invalid input in any required field, when the user submits, then the system prevents save and shows a specific error message near the field.
  • Given normal network conditions, when the user submits, then the response time is under 2 seconds for 95 percent of requests.

Risks & Tips

  • Risk: Vague criteria cause rework and disputes in Sprint Review. Tip: Use concrete, measurable language.
  • Risk: Overly technical criteria hide customer value. Tip: Describe behavior from the user’s perspective.
  • Risk: Missing edge cases. Tip: Add negative paths and boundary values during refinement.
  • Risk: Scope creep mid-sprint. Tip: Freeze criteria at commitment; handle new ideas as new backlog items.
  • Risk: Criteria not testable. Tip: Pair with QA to ensure each criterion maps to at least one test.
  • Risk: Confusion with Definition of Done. Tip: Keep a visible DoD and link story-specific criteria to it.

PMP/SCRUM Example Question

During Sprint Planning, the team cannot size a user story because expected behavior is unclear. What should they request to proceed confidently?

  1. A detailed technical design from the lead developer.
  2. User story acceptance criteria defined with the Product Owner.
  3. A longer sprint to allow for discovery and build.
  4. An updated Definition of Done specific to this story.

Correct Answer: B — User story acceptance criteria defined with the Product Owner.

Explanation: Acceptance criteria provide testable conditions that clarify scope and enable estimation and commitment. A technical design or longer sprint does not replace clear, story-level acceptance conditions; the DoD is shared, not story-specific.

AI for Agile Project Managers and Scrum Masters

Become an AI-first leader and transform your agile practice by leveraging artificial intelligence as your most powerful co-pilot. This course is designed to help you drive efficiency, insight, and innovation, ensuring you stay at the forefront of a rapidly evolving project management landscape.

This isn't about replacing human intuition—it's about augmenting it. You'll master prompt engineering to automate mundane tasks, freeing up your time for high-impact strategic leadership and creative problem-solving. Learn to refine backlogs, create strategic roadmaps, and integrate AI seamlessly into your agile ceremonies.

Gain predictive power by using AI-driven insights to anticipate project risks and seize new opportunities for more reliable outcomes. We deliver practical, prompt-based workflows and proven strategies built around real-world agile challenges that you can implement immediately within your framework.

Master foundational AI concepts specifically relevant to Scrum environments while developing advanced skills to handle diverse agile scenarios. You will learn to champion an AI-enabled culture within your organization, fostering a dynamic environment of continuous improvement and superior team delivery.

Learn alongside professionals around the world working in project leadership and delivery.

Explore the Course


Build an ICS/OT cybersecurity foundation that fits the real environment

Standard IT controls can disrupt the industrial systems they are meant to protect. Learn how to assess OT risk, design zones and conduits, apply IEC 62443 security levels, use MITRE ATT&CK for ICS, and establish passive asset visibility without risking production. Eight reconstructed incidents connect attacker techniques to the controls that failed, giving you the vocabulary and judgment to make credible security decisions from day one.

Explore the Course