What are Acceptance Criteria (AC)?
“Acceptance criteria are pre-established standards or requirements a product or project must meet.” -Google
Acceptance Criteria (AC) are unique to each user story and define the feature from the end user's perspective. They form a boundary between what is in scope and what is out of scope.
Best practices for writing ACs
Who, When, How?
AC should always be written from the end user's perspective. It is generally written by the product owner/manager or business analyst before actual development starts. This way, the team will be able to capture all the stakeholder needs in advance.
Shared understanding and consensus
AC synchronise the visions of the client/stakeholder and the product team. They help to ensure a common understanding of the requirements i.e. developers know what behaviour the feature must demonstrate, and the client knows what to expect from the feature. Everyone must review the AC and agree each line.
Clarity, always
AC must be clear, concise and easy to understand for everyone. They should entail all the functional and non-functional aspects of the feature and be written in simple and plain language. Avoid technical details.
AC should convey the intent and not the solution as the same problem can be solved differently by a different team. Avoid implementation details.
Make it testable, measurable and achievable
AC should make it possible to accurately plan and estimate each user story. AC should include clear success and fail scenarios and each criterion should be independently testable so testers can verify that all requirements are met.
The structure
The two most common formats are:
Scenario oriented (Given/When/Then):
Given some pre-condition, when I perform some action, then I expect some result e.g:
User story: As a user, I want to be able to recover the password to my account, so that I am able to access my account again
Scenario: Forgot password
Given the user has navigated to the Log in page,
When the user clicks on the 'Forgot password' button and enters his email address,
Then he should receive an email from the system to the email address he provided
Rule oriented:
In other cases, a feature's requirements may not fit nicely into the Given/When/Then format. The rule-oriented form entails that there is a set of rules that describe the behaviour of the feature e.g:
User story: As a user, I want to use a search field to enter my postal code, so that I can find the nearest community centre
Acceptance Criteria
- The placeholder disappears once the user starts typing
- Search starts when the users hits "Enter/Return" on the keyboard or clicks on the "Search" button
- The search input only accepts numerical digits
- The search input can't take more than 8 digits
- etc.
Most requirements can be captured in the formats above, however, it is always possible to write AC in custom formats.
To recap
Acceptance Criteria (AC) are conditions in which a product must meet in order to be accepted by a user/system. AC define scope, defend against scope creep, clarify requirements and prevents ambiguity. It also helps the QE to verify if development goals were met.
What are some other best practices you/your team follow in writing AC? Curious to hear your thoughts/comments below ⚡
Top comments (1)
Great article on how to write strong acceptance criteria! It's important to clearly define what is acceptance criteria in user story to ensure shared understanding and successful delivery. Your tips for making them specific, measurable, achievable, relevant, and time-bound are spot on. Thanks for sharing this valuable information!