Writing Strong Acceptance Criteria: A Field Checklist
Acceptance criteria are the conditions a user story must satisfy for the team to consider it complete. They sit at the intersection of requirements, design, and testing — and when they are written well, they eliminate ambiguity before development starts rather than discovering it during a sprint review. When they are written poorly, they generate rework, testing gaps, and disputes between product owners and developers about what "done" actually means.
The Given/When/Then (Gherkin) Format
The most widely used format for writing acceptance criteria is Given/When/Then, sometimes called Gherkin after the syntax used in behaviour-driven development tools. The structure is straightforward: Given describes the pre-condition or context, When describes the action the user takes, and Then describes the expected outcome. For example: Given a registered user is on the login page / When they enter a valid email and password and click Sign In / Then they are redirected to their dashboard and their name appears in the navigation header. This format makes each criterion testable, specific, and readable by both technical and non-technical stakeholders.
Checklist for Good Acceptance Criteria
Specific and testable. Every criterion should be verifiable with a clear pass or fail result. "The page loads quickly" is not testable; "The page loads in under two seconds on a standard broadband connection" is.
Written before development starts. Acceptance criteria written after coding begins are not criteria — they are a rationalisation of what was built. The point of writing them in advance is to surface disagreements before they become expensive.
Shared understanding confirmed with the team. A product owner writing criteria in isolation and handing them to developers as a finished product defeats the purpose. Walk through each criterion with the development team and tester before the sprint starts. Misunderstandings surface in minutes in a conversation; they surface in days in code review.
Covers the happy path AND edge cases. The happy path is what happens when everything goes as expected. Edge cases cover boundary conditions, error states, and unusual but valid inputs. A login story that only defines the successful login scenario is incomplete; it should also define what happens when the password is incorrect, when the account is locked, and when the user has forgotten their email.
Does not prescribe implementation. Acceptance criteria define what the system should do, not how it should do it. Specifying technical implementation in acceptance criteria removes design decisions from the developers and testers who are best placed to make them.
Common Mistakes to Avoid
Too vague: "The system should handle errors gracefully" tells the team nothing actionable.
Too technical: "The API should return a 401 status code" is a test case, not an acceptance criterion — it belongs in the test plan.
Written after coding: if developers are asking what "done" means after they have started building, the criteria are too late.
Confused with test cases: acceptance criteria define the conditions of satisfaction; test cases define how you verify them. They are related but distinct.
Worked example — User Story: "As a frequent shopper, I want to save items to a wish list so that I can purchase them later." Acceptance criteria: (1) Given a logged-in user is viewing a product page, When they click Save to Wish List, Then the item is added to their wish list and a confirmation message is displayed. (2) Given a logged-in user navigates to their wish list, When the page loads, Then all saved items are displayed with their current price and availability. (3) Given a guest user clicks Save to Wish List, When the action is triggered, Then they are prompted to log in or create an account before the item is saved.
XNM Consulting helps Scrum teams build delivery practices that translate good intentions into shipped software. Learn more about our program and project delivery services.