A story such as “require a secure password” sounds clear until the team asks which passwords count as secure and what happens when one is rejected. Acceptance criteria turn such questions into conditions that stakeholders, testers, and developers can use to decide whether a feature is complete. They clarify the story’s scope and boundaries, expose assumptions, and give implementation and testing a shared target. section 5.2.3 section 6.2
Start with a short, provisional list of criteria on a story card or backlog item; do not expect it to be exhaustive. Shortly before implementation, discuss examples and counterexamples with business stakeholders, testers, and developers. Use their answers to refine the rules and agree on observable outcomes. The criteria can then become scenarios: Given a context, When something happens, Then an expected outcome follows. section 5.2.3 section 6.0 section 3.4
A password rule changes under scrutiny
An initial list requires at least eight characters, a digit, punctuation, and an error message for insecure passwords. Discussion raises questions about letter case and what feedback is useful. A table of proposed passwords and expected results helps the team test its assumptions; a later table distinguishes weak, medium, strong, and very strong passwords, and marks which are acceptable. The examples make the rule more precise than the initial bullets. section 6.2
Compare password examples by both assessed strength and acceptability; the rows make the intended boundary available for discussion. section 6.2
Where worthwhile, automate agreed scenarios as executable specifications. They guide development, check completion, and run again after changes to catch regressions. Automation is a choice, not a requirement for every criterion: some scenarios remain manual, while others fit unit or integration tests better. Choose a test level that matches the behavior: visible password-strength feedback suits a web test, whereas classifying many passwords suits a code-level test. section 2.3.6 section 8.0 section 10.2.3
Keep criteria current when requirements change. If users now need four upcoming trains rather than two, change the scenario first: its failure shows the gap between requested and implemented behavior. For a missed bug, add a criterion that reproduces it before fixing it. Passing tests can show implemented criteria, but green results alone do not prove an entire feature is ready when other criteria remain pending or unautomated. section 3.7 section 16.2.2
