What Is Acceptance Criteria? How to Write It and Why It Matters
Acceptance criteria are the specific, testable conditions that a user story, feature, or product increment must satisfy for it to be considered complete and ready for release. They define, in precise and observable terms, what “done” means for a specific piece of work — establishing the shared standard against which delivery is evaluated.
In agile development, acceptance criteria are written collaboratively between the product owner and development team, typically during backlog refinement or sprint planning. They form the contract between product requirements and engineering implementation: the product owner confirms that the criteria represent the required behavior; engineering confirms that they can build to those criteria.
Why Acceptance Criteria Are Essential
They Eliminate Ambiguity
User stories describe user goals at a high level: “As a user, I want to reset my password.” What does this mean exactly? When does the password reset expire? What complexity rules apply? What should happen if the email isn’t found? Acceptance criteria answer these questions precisely — before development begins, not after the feature is built and the questions can no longer be ignored cheaply.
They Create Testability
Criteria that are written in observable, verifiable terms can be directly converted into test cases. Well-written acceptance criteria are effectively a test plan written in business language. This is why the shift-left testing philosophy places acceptance criteria writing before development — criteria-driven test cases catch issues while code is still malleable.
They Build Shared Understanding
The process of writing acceptance criteria — where product, engineering, and QA discuss what the feature must do in specific scenarios — surfaces different assumptions before they become conflicts. Developers often think of edge cases the product manager didn’t consider; product managers often have intent that wasn’t clear from the story title alone. This conversation, facilitated by acceptance criteria writing, is one of the most valuable quality investments available.
How to Write Good Acceptance Criteria
The Given-When-Then Format
The most widely used format for acceptance criteria follows a structured pattern:
Given [a precondition or context] When [an action is taken] Then [the expected observable outcome]
Example (for a password reset feature):
- Given I am on the login screen, When I click “Forgot Password,” Then I see a form asking for my email address
- Given I enter a valid email address, When I submit the form, Then I receive an email containing a password reset link within 2 minutes
- Given I receive a reset link, When I click it after 24 hours, Then I see a message explaining the link has expired and I can request a new one
- Given I enter a new password that doesn’t meet complexity requirements, When I submit the form, Then I see an error message describing the specific requirement that isn’t met
What Makes Acceptance Criteria Good
Observable: Each criterion should describe something that can be directly verified — not “the feature performs well” but “the page loads in under 2 seconds under normal load.”
Specific: Vague criteria allow interpretation. Specific criteria prevent it. “The form validates input” is vague. “If the email field is empty when submitted, an inline error message reading ‘Email address is required’ appears below the field” is specific.
Complete: Cover the happy path (everything goes right), error paths (invalid input, system errors), and edge cases (unusual but valid scenarios). The unhappy paths are where most usability problems live.
Independent: Each criterion should be independently testable without requiring all others to pass first.
Acceptance Criteria vs. Definition of Done
| Acceptance Criteria | Definition of Done | |
|---|---|---|
| Scope | A specific user story | The team’s overall quality standard |
| Content | Functional behavior of this feature | All work items (tests, documentation, code review, etc.) |
| Who writes it | Product owner with team input | The entire Scrum team |
| Purpose | Define this feature’s completeness | Define quality across all features |
Both are needed: acceptance criteria define what the feature must do; the Definition of Done defines the process quality standards that apply to all work.
Key Takeaways
Acceptance criteria are one of the most leveraged investments in product quality. Spending an extra 30 minutes writing detailed, testable criteria before development begins prevents hours or days of rework after development ends — because the criteria surface misalignments, edge cases, and unstated requirements while the cost of addressing them is still minimal. Teams that make detailed acceptance criteria a non-negotiable part of their sprint planning consistently deliver fewer defects, more complete features, and fewer post-release surprises.