Writing effective acceptance criteria: clarity before development begins

What are good acceptance criteria?

Acceptance Criteria describe the conditions a User Story or backlog item must meet to be considered ‘Done’. They are concise, clear, and testable, so that both the team and the Product Owner know exactly when a story is complete. Well-formulated criteria prevent misunderstandings, reduce rework, and form the basis for test scenarios.

‍

Examples of good acceptance criteria

• Clear: “When I click the ‘Order’ button, I receive a confirmation email with a summary of my order within 1 minute.”
• Testable: “If I enter a valid discount code, a 10% discount is applied to the total amount, and this is visible at checkout.”

‍

Who defines acceptance criteria? (Role of PO and team)

The Product Owner is responsible for the content and value of the backlog item, so they often draft the initial version of the acceptance criteria. However, the ideal scenario is for the PO and the development team to collaborate. After all, the team can indicate which criteria are technically feasible and which edge cases are relevant. This creates a shared definition of ‘done’.

‍

Avoiding pitfalls in acceptance criteria

• Too vague or too broad: “User must be able to register.” But how? What are the fields? What is the validation?
• Too technical: “Database schema needs to be updated.” This might be an internal task, but it says little about customer value.
• No edge cases: “What happens if the user enters an invalid email address or loses their connection?”
• No clear testing method: Without a measurable condition, it's difficult to verify if the story is truly ‘Done’.

‍

Common mistakes with acceptance criteria

1. No realistic scenario: Criteria that don't account for what can actually happen (e.g., spaces, special characters, network outages).
2. Copy-paste criteria: Giving every item the same criteria provides no relevant information.
3. Discussed too late: Criteria that only emerge during the sprint can cause delays.
4. No consensus: If the PO and the team don't review acceptance criteria together, misinterpretation is a risk.

‍

Checklists and templates for clear acceptance criteria

A practical format is to describe each criterion as Given, When, Then:

• Given: The initial state (e.g., “User is logged in and on the checkout page”).
• When: The action (“User clicks ‘Pay with iDEAL’”).
• Then: The expected outcome (“User sees a confirmation page with order number and payment status”).

‍

Practical example

Criterion 1: “Given I am on the checkout page, when I enter a valid discount code, then I immediately see the reduced total price with X% discount.”

‍

Conclusion

Acceptance criteria bring focus and clarity to your User Stories. They help the team understand when something is truly 'done' and prevent ambiguity. By discussing criteria together, developing good scenarios, and formulating measurable conditions, you work step-by-step towards a product that meets customer needs. Remember that acceptance criteria evolve—keep them current and continue to discuss them in refinement and planning sessions.