Acceptance Criteria for User Stories: Purposes, Formats, Examples, and Best Practices
altexsoft | May 18, 2021
What are the acceptance criteria and their role in projects?
Acceptance criteria (AC) are the conditions that a software product must meet to be accepted by a user, a customer, or other systems. They are unique for each user story and define the feature behavior from the end-user’s perspective.
Acceptance criteria are the lowest-level functional requirements
Well-written acceptance criteria help avoid unexpected results in the end of a development stage and ensure that all stakeholders and users are satisfied with what they get.
An important aspect in regard to acceptance criteria is that they have to be defined before the development team starts working on a particular user story. Otherwise, there’s a decent chance the deliverables won’t meet the needs and expectations of a client.
Acceptance criteria main purposes
Making the feature scope more detailed
Describing negative scenarios
Streamlining acceptance testing
Conducting feature evaluations
Acceptance criteria types and structures:
(A) Scenario-oriented acceptance criteria (GWT)
As the name suggests, the scenario-oriented format is the acceptance criteria type that comes in the scenario form and illustrates each criterion. It is approached through the Given/When/Then (GWT) sequence that looks like this:
Given some precondition
When I do some action
Then I expect some result
The acceptance criteria template in this format includes the following statements:
Scenario – the name for the behavior that will be described
Given (a precondition) – the beginning state of the scenario
When (something happens) – the specific action that the user makes
Then (this the result) – the outcome of the action in “When”
And – used to continue any of three previous statements
When combined, these statements cover all actions that a user takes to complete a task and experience the outcome.
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.
Scenario: Forgot password
Given: The user navigates to the login page
When: The user selects option
And: Enters a valid email to receive a link for password recovery
Then: The system sends the link to the entered email
Given: The user receives the link via the email
When: The user navigates through the link received in the email
Then: The system enables the user to set a new password
(B) Rule-oriented acceptance criteria format
The rule-oriented form entails that there is a set of rules that describe the behavior of a system. Based on these rules, you can draw specific scenarios.
Usually, criteria composed using this form look like a 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.”
Ready-to-use acceptance criteria templates
Roles responsible and how acceptance criteria are created
Some of the criteria are defined and written by the product owner when he or she creates the product backlog. And the others can be further specified by the team during user stories discussions after sprint planning.
There are no strict recommendations to choosing the person responsible for writing the criteria. The client can document them if he or she has ample technical and product documentation knowledge. In this case, the client negotiates the criteria with the team to avoid mutual misunderstandings. Otherwise, the criteria are created by a product owner, business analyst, requirements analyst, or a project manager.
Main challenges and best practices of writing acceptance criteria
Document criteria before development.
Don’t make AC too narrow.
Keep your criteria achievable.
Keep AC measurable and not too broad.
Avoid technical details.
Write testable AC.
Follow these tips for guidance on how to phrase your AC.
Write in active voice, first-person.
Avoid negative sentences.
Write simple, concise sentences.
Don’t neglect the acceptance criteria as they – being simple and approachable – solve multiple problems at once. They document customer expectations, provide an end-user perspective, clarify requirements, prevent ambiguity, and eventually help quality assurance verify if the development goals were met. Regardless of whether you use Agile methods or not, make sure to choose the best format or experiment with your own ones. Different types of user stories and eventually features may require different formats and testing the new ones that work for you is a good practice.
Author = altexsoft