Anatomy of a User Story: Acceptance Criteria

In the first article of this series, we examined the narrative of a user story. The narrative establishes who the user is, what they need, and why. But the narrative alone doesn't tell the development team when the story is "done." That's where acceptance criteria come in.

What are acceptance criteria?

Acceptance criteria are the specific conditions that a user story must satisfy to be considered complete. They define the boundaries of the story, clarifying what's included and what's not. Well-written acceptance criteria eliminate ambiguity and provide a clear checklist for development and testing.

Characteristics of good acceptance criteria

• Testable: Each criterion can be verified as met or not met
• Clear: Written in plain language that all team members understand
• Independent: Each criterion stands on its own without depending on others
• Concise: Focused on the what, not the how

Writing acceptance criteria

The most common format is a simple checklist of conditions. For example: "User can sort the table by any column header," "Sort order toggles between ascending and descending on repeated clicks," "Current sort column and direction are visually indicated."

The bridge to testing

Acceptance criteria serve as the foundation for test cases. Each criterion becomes a test that validates whether the story has been properly implemented. This direct mapping ensures that testing covers the requirements and nothing falls through the cracks.

Common pitfalls

Avoid writing acceptance criteria that are too vague ("system performs well"), too technical ("API returns 200 status"), or too numerous (which may indicate the story needs splitting). The goal is to capture the essential conditions for business value.