Definition

“Acceptance criteria (AC) are the conditions that a software product must meet to be accepted by a user, a customer, or other systems.” (Altexsoft)

Well-written acceptance criteria will help preventing unexpected results or we call bugs. It must meet user’s expectation, then they will be more satisfied when get result.

Acceptance Criteria aim to user requirement and non-function requirement. So we can consider some kinds of AC :

Functional Criteria: Identify specific user tasks, functions or business processes that must be in place. A functional criterion might be “A user is able to access a list of available reports.” A non-functional criterion might be “Edit buttons and Workflow buttons comply with the Site Button Design.”
Non-functional Criteria: Identify specific non-functional conditions the implementation must meet.
- Performance: If specific performance is critical to the acceptance of a user story, it should be included. This is often measured as a response time, and should be spelled out as a threshold such as “1-2 seconds for a query response.”
- Security How are the system and its data protected against attacks. How we secure data.
- Usability How easy is it for a customer to use the system (UI/UX) and understand user behavior.
- Reliability How often does the system experience critical failures. Data is trustable.
- Maintainability how product is easy to adapt changes and new features. Code is understandable

Purpose

Clear Scope: define boundaries of user story, help team focus in what we need to do.
Define scenarios: include positive and negative scenarios and explain how system react to them. Example in 2 cases of inputting valid and invalid password to system and how system react.
Communication: it sets up and sharing common understanding in requirement. Then team will understand more in why user need this feature and have chance to challenge requirement.
Guide Testing: With engineers, it a guideline how to test function properly. Because it defines all results which users want system performs.
Estimable: when they have clear ACs , team has enough understanding to break into tasks and estimate them.

Format

a.Scenario-oriented (the Given/When/Then template)

This approach is come from behavior driven development (BDD) , provides a structure to describe user scenario in upfront. If have tester/automation tester, it will be test cases and automated test cases.

Template:

Scenario – the name for the behavior that will be described
Given – the beginning state of the scenario
When – specific action that the user makes
Then – the outcome of the action in “When”
And – used to continue any of three previous statements

Example

User story: As a user, I want to be able to recover the password to my account, so that I will be able to access my account in case I forgot the password.

b. Rule-oriented (the checklist template)

In case target stories does not need scenarios, target users don’t need precise details in behavior. So we can use simple bullet list

Example

User story: As a user, I want to use a search field to type a city, name, or street, so that I could find matching hotel options.
Basic search interface acceptance criteria

The search field is placed on the top bar
Search starts once the user clicks “Search”
The field contains a placeholder with a grey-colored text: “Where are you going?”
The placeholder disappears once the user starts typing
Search is performed if a user types in a city, hotel name, street, or all combined
Search is in English, French, German, and Ukrainian
The user can’t type more than 200 symbols
The search doesn’t support special symbols (characters). If the user has typed a special symbol, show the warning message: “Search input cannot contain special symbols.”

c. Custom formats.

There are 2 common formats in BDD and Bullet List. But you can describe AC how to easy understand and clear expectations as below.
Some other :

Input a workflow.
Input a excel file (security Matrix)
Table Matrix (Decision Table)

For instance, your criteria may be specified as an table matrix of system behavior:

Best Practice

Acceptance criteria must be documented before the actual development starts. Each product backlog item or user story should have at least one acceptance criteria
Don’t make AC too narrow and Technical details. Don’t describe AC as a specific solution, it leads to narrow engineer creative in solutions. Narrow AC will lead to missing user behaviors. It focuses on the end result not solution.
Keep your criteria achievable and not too broad : keep AC detail enough for engineers to start working on it. The way we put everything inside AC will lead engineers to a bundle of tasks and risk of missing AC because they wont have read AC carefully
Reach consensus. Make sure ACs are communicated well and everyone understand them.
Write simple/concise and testable : use several simple sentences in stead of complex one. Make AC testable to lead engineer know when they meet AC.
Clear with Pass/fail result

Reference:

https://www.altexsoft.clom/blog/business/acceptance-criteria-purposes-formats-and-best-practices/
https://www.productplan.com/glossary/acceptance-criteria/#:~:text=The standard user story fo
https://www.seguetech.com/what-characteristics-make-good-agile-acceptance-criteria/
https://agileforgrowth.com/blog/acceptance-criteria-checklist/

Acceptance Criteria for User Story