Acceptance criteria define the conditions that show whether a feature or project outcome is complete and acceptable. During sprint planning, they make user stories more precise, align expected work with stakeholders, and provide a basis for deciding whether a sprint goal has been delivered. section 9.1 section 9.6
Useful acceptance criteria connect a requested capability to observable behavior:
- Start with a user story, such as: “As a user, I want to search for transactions, so that I can better research customer inquiries.” section 9.1
- Express the expected behavior as a scenario that stakeholders can read and developers can test. section 2.4.4
- Use the result to judge completion rather than trusting that an implementation works without evidence. section 9.6
BDD acceptance scenario
For an ACH batch-header parser, a human-readable feature file can state: “When we parse the batch header, then the record type should be 5.” The corresponding step verifies the parsed record type, turning the requirement into a runnable acceptance check. section 2.4.4
Listing 2.9 Parsing an ACH batch header
Feature: Parsing a Nacha Batch Header
Scenario: We have a record type of 5
When We parse the batch header
➥"5200Company name DiscretionaryData Company
IDARCComp desc 0216232302160471061000010000001"
➥ Then The record type should be 5
Browse the complete feature-file example for the batch-header acceptance scenario, then use the linked implementation to see how the expected behavior is verified. section 2.4.4
