Defining acceptance criteria

Acceptance criteria define when a user story is complete. They create a shared understanding between product managers, developers, and QA teams about what success looks like. Without clear criteria, teams waste time debating whether features are "done."^[1] Keep in mind that acceptance criteria usually cover functional requirements (what the user story should achieve). Non-functional requirements, like security, scalability, localization, or production readiness, aren’t always listed in the story. Instead, these are included in a team-wide definition of done (DoD) statement.

Write acceptance criteria as testable statements. Use formats like "Given [context], when [action], then [result]." For example: "Given a user has items in their cart, when they click checkout, then they see a payment form with their cart total."

Include both positive and negative scenarios. Define what should happen in normal use cases and edge cases. Consider error states, empty states, and boundary conditions. This prevents surprises during development and testing.