_edited_edited.png)
While user stories aim at describing what exactly the user wants the system do, the goal of the acceptance criteria is to explain the conditions that a specific user story must satisfy. So let’s understand what are the acceptance criteria and their role in the project.
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.
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.
The main purpose of Acceptance criteria is to:
To scope of the feature is detailed.
Describing the negative scenario
Setting communication for common understanding of the requirement
Streamlining the acceptance testing
Conducting feature evaluations.
Acceptance criteria types and structures namely:
scenario-oriented (the Given/When/Then template)
rule-oriented (the checklist template)
custom formats.
1. Scenario-oriented acceptance criteria:
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
This approach was inherited from behavior driven development (BDD) and provides a consistent structure that helps testers define when to begin and end testing a particular feature. It also reduces the time spent on writing test cases as the behavior of the system is described upfront.
EX: 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.
2. Rule-oriented Acceptance Criteria format:
In some cases, it’s difficult to fit acceptance criteria into the Given/When/Then structure. 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.
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.
3. Custom formats: Most user stories can be covered with two formats mentioned above. However, you can invent your own acceptance criteria given they serve their purposes, are written clearly in plain English, and can’t be misinterpreted. Some teams even use plain text.
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. The criteria are created by a product owner, business analyst , requirements analyst, or a project manager.
Best Practices:
> Document criteria before development
> Don’t make AC too narrow
> Keep your criteria achievable.
> Keep AC measurable and not too broad
> Avoid technical details
> Reach consensus
> Write testable AC
> Write simple, concise sentences.
Conclusion: AC document serves 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 good practice.