Acceptance criteria
Acceptance criteria are verifiable conditions that a requirement, feature, or deliverable must satisfy to be considered acceptable or complete.
BDD in Action, Second Edition
An acceptance criterion is a condition that a feature or user story must satisfy to be accepted as complete.
- How it is used
- Defines observable conditions for accepting a feature or User Story and gives stakeholders, testers, and developers a shared target.
- How deep it goes
- Traces provisional notes through collaborative examples, scenarios, automation, test-level choices, and maintenance without requiring every criterion to be automated.
- Examples
- Uses password-strength tables, train-departure scenarios, and pending authentication scenarios to expose boundaries, changes, and unfinished work.
- What you can do after
- Practice/perform collaborative refinement of criteria, then use scenarios to judge completion and identify gaps when requirements change.
Read how BDD in Action, Second Edition explains acceptance criteria →
Collaborative Software Design: How to facilitate domain modeling decisions
Acceptance criteria are business conditions that an implementation must satisfy for a requirement or user story to be accepted.
- How it is used
- Uses concrete examples to discover business conditions and constraints for user stories or use cases.
- How deep it goes
- Explains a structured mapping process from story to rules to examples, then shows how discussion reveals additional rules and concepts.
- Examples
- Uses seat reservations, one-ticket-per-seat rules, adjacent-seat constraints, and corridor discovery as concrete examples.
- What you can do after
- Apply it via Example Mapping to turn a stakeholder’s story into rules, examples, constraints, and acceptance criteria.
Delivering Machine Learning Projects: From design to deployment
Acceptance criteria are conditions that a delivered system or project result must satisfy to be accepted.
- How it is used
- Uses stakeholder user stories during project validation to identify requirements and candidate acceptance criteria before deeper delivery work.
- How deep it goes
- Identifies candidate criteria through stakeholder scenarios but defers fleshing them out in detail until funding and project resources exist.
- Examples
- Uses first use, normal use, and system exit across sponsors, users, customers, and affected persons as requirement-revealing scenarios.
- What you can do after
- Evaluate candidate requirements by translating stakeholder stories into functionality, avoided harms, corner cases, model behavior, and data needs.
Build Financial Software with Generative AI (From Scratch)
Conditions that define when a software feature or project outcome is considered complete and acceptable.
- How it is used
- Aligns Agile sprint work with expected story outcomes and sprint-goal delivery.
- How deep it goes
- Explains criteria through user stories and given/when/then scenarios, but does not provide a general checklist for every feature.
- Examples
- Uses transaction search stories and an ACH batch-header parsing scenario as concrete acceptance examples.
- What you can do after
- Evaluate completion by turning desired behavior into stakeholder-readable BDD scenarios and executable tests.
Read how Build Financial Software with Generative AI (From Scratch) explains acceptance criteria →
Effective Platform Engineering
Acceptance criteria are conditions that a software change must satisfy to be considered acceptable.
- How it is used
- Defines measurable success conditions for platform work and carries them from planning through production verification.
- How deep it goes
- Explains definition, timing, experiments, automated tests, and pipeline verification, but does not provide specific metric templates.
- Examples
- Uses new platform capabilities, incremental experiments, usage evidence, automated tests, and end-to-end pipeline checks as examples.
- What you can do after
- Evaluate/understand whether platform changes satisfy measurable success conditions before sustained implementation.
Read how Effective Platform Engineering explains acceptance criteria →
Prompt Engineering in Practice
Defined conditions that a result must satisfy to be considered acceptable.
- How it is used
- Defines how a prompt’s result will be judged as good or bad within a specification.
- How deep it goes
- Frames criteria as testable review questions without detailing a scoring procedure.
- Examples
- Uses a feature-proposal analysis prompt with specified dimensions, recommendation, and confidence level.
- What you can do after
- Evaluate whether prompt criteria make good results distinguishable and testable.
Read how Prompt Engineering in Practice explains acceptance criteria →
Related concepts
- definition of doneused by · A definition of done is an agreed set of criteria that work must satisfy to be considered complete.
- user storypart of · A user story is a concise requirement describing a desired software capability, interaction, or outcome from a user’s or stakeholder’s perspective.
- business ruleequivalent to · A business rule is a domain-specific policy, condition, or constraint that governs valid data, decisions, actions, or behavior in an organization or its systems.
- capabilitymeasures · A capability is an ability or permitted function that enables a person, organization, or system to perform an activity or achieve an outcome.
- business contextpart of · Business context is the organizational, operational, market, and strategic circumstances, objectives, and constraints that shape the meaning and priorities of a business activity or decision.
- executable specificationproduces · An executable specification is a machine-runnable description of expected system behavior that can automatically verify whether an implementation satisfies its requirements.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.