In a faraway world of perfection, we would truly understand each other without any confusion whether it was 'this' or 'that'. In our world, we need to come up with ways to convey our intentions and ideas clearly so we are not misunderstood by our colleagues.
In software development, acceptance criteria aid the development team in knowing the expectations for a certain feature. As development teams, we strive to build the best system of our specific industry, however this does not convey much, we need to come up with objectives to achieve our goals.
This post will discuss the following on acceptance criteria:
- What is the definition?
- Why are they used?
- Who writes them?
- How to write acceptance criteria?
Defining Acceptance Criteria
The criteria that a component or system must satisfy in order to be accepted by a user, customer, or other authorised entity - ISQTB
Acceptance criteria are the “conditions that a software product must satisfy to be accepted by a user, customer or other stakeholders.” - FreeCodeCamp
Why are they used?
- Understanding the value and vision - assist the development team on what the feature is, how it adds value to the business, and how it contributes to the vision of the company
- Define Behaviour -This aids the team in getting a list of items on what the feature should do
- Reach Harmony - The development team knows exactly what conditions need to be met, just as the clients know what to expect from the feature
- Support testing - On top of the ticket description, talking to the product, and talking to the development team for test cases, this provides another point of view for testers
Who writes Acceptance Criteria?
These are normally written by the product owner and reviewed by a member of the development team to ensure that there are no technical constraints and/or inconsistencies from a development perspective. In my team, it is first written by the product owner, then reviewed by a developer for the technical constraints, and finally a QA specialist for their knowledge of how the new feature should interact with the current system.
The Acceptance Criteria should be specified before it gets added to the sprint for the team to work on
How to write Acceptance Criteria
There are multiple ways to write acceptance criteria. Our team prefers the scenario-oriented format as the team gets a better understanding of the requirements compared to one sentence scenarios.
A common template used from my conversations with teams in other companies is the Given/When/Then format.
Here are a couple of examples:
User Story 1
User Story 2
Sample Acceptance Criteria