Who writes acceptance criteria?

Acceptance criteria are typically written by the product owner in collaboration with the development team and testers (often called the "three amigos" approach). The product owner ensures business requirements are captured, developers flag technical considerations, and testers identify edge cases and test scenarios.

How many acceptance criteria should a user story have?

A user story typically has 3-8 acceptance criteria. If there are more than 8-10, the story may be too large and should be split into smaller stories. Too few criteria may indicate the story is not well-understood. Each criterion should add meaningful definition to the story.

What is the difference between acceptance criteria and the definition of done?

Acceptance criteria are specific to a particular user story and define the conditions for that story to be accepted. The definition of done is a shared checklist that applies to all work items (e.g., code reviewed, tests passing, documentation updated). Both must be satisfied for work to be considered complete.

Book Free Assessment Calculator

Acceptance Criteria

Also known as:conditions of satisfactiondone criteriaAC

A set of predefined conditions that a deliverable must meet to be accepted by the project stakeholders, defining the boundaries of a user story or feature.

In-Depth Explanation

Acceptance criteria are specific, testable conditions that define when a piece of work is complete and ready for acceptance. They bridge the gap between what is requested and what is delivered, reducing ambiguity and ensuring shared understanding.

Characteristics of good acceptance criteria:

Specific: Clear enough that anyone can determine if they are met
Testable: Can be verified through testing or inspection
Independent: Each criterion can be evaluated on its own
Achievable: Realistic within the scope of the work item
Relevant: Directly related to the user story or requirement

Formats for acceptance criteria:

Given/When/Then (Gherkin): "Given [context], When [action], Then [expected outcome]"
Checklist format: Simple list of conditions that must be satisfied
Rule-based format: Business rules that must be implemented
Scenario-based: Specific usage scenarios that must work correctly

Writing effective acceptance criteria:

Involve the product owner, developer, and tester (three amigos)
Write from the user's perspective
Include both positive and negative scenarios (what should and should not happen)
Define performance and quality requirements where relevant
Keep criteria focused on "what" not "how"
Include edge cases and boundary conditions

Common mistakes:

Too vague ("the page should load quickly" - how quickly?)
Too detailed (specifying implementation rather than outcomes)
Missing criteria discovered during development
Not including non-functional requirements (performance, accessibility)

Business Context

Clear acceptance criteria reduce rework, prevent scope disagreements, and ensure that delivered work meets business expectations the first time.

How Clever Ops Uses This

Clever Ops uses rigorous acceptance criteria in all client projects, ensuring that every deliverable is clearly defined, testable, and aligned with business objectives. We help Australian businesses adopt this practice to improve their own project delivery quality.

Example Use Case

"A user story "As a customer, I want to filter products by price" has acceptance criteria: "Given I am on the product listing page, When I set a price range of $50-$100, Then only products within that range are displayed, sorted by price ascending.""