If there’s a topic that has been discussed in online forums since time immemorial, it has to be Acceptance Criteria.
While there is a lot of buzz around the term, a lot of organizations face trouble when writing the acceptance criteria. This throws the development team off balance.
Shoddy product increments.
If you’re looking to learn about acceptance criteria, its purpose, types, its format, and more, then this blog post will be your guide.
What is Acceptance Criteria?
Acceptance Criteria is the set of predefined conditions that must be fulfilled to ensure that the product fulfill end-users expectations.
Importance of Acceptance Criteria
A well-articulated acceptance criteria removes ambiguity about the functionality to be built. The development team will be clear about the client requirements and what the final deliverable should look like.
Writing acceptance criteria is helpful in the following ways-
- Understand expectations: Acceptance criteria are crystal clear about the task. They are testable with yes or no, pass or fail outcomes providing no scope for confusion and wrong interpretation.
- Develop a shared understanding with the client: It isn’t uncommon to see clients express dissatisfaction over the deliverables. Clients would have expected more from functionalities and clearly defined acceptance criteria will help develop a shared understanding with the client.
- Define the functionality for tests: The specified criteria will help in assessing if the system is performing according to expectations.
- Work on estimates: When the development team is clear about the requirements, the estimates will be accurate.
- Avoid Scope Creep: When an acceptance criteria is clearly articulated at the onset of a project, customers and stakeholders will not be able to change or add requirements midway through the project. Schedules and subjects won’t be subject to overrides when scope creep is taken care of.
Learn how to write good acceptance criteria: Sign Up for the (PSPO) Certification Training
Characteristics of a good acceptance criteria
An Acceptance Criteria is potent if it possesses the following characteristics-
- Easy to test: Since the acceptance criteria help in determining the Definition of Done, the acceptance criteria should be easy to test. The results should not be ambiguous. The test should declare Yes/No or Pass/Fail results.
- Simple and succinct: The acceptance should not be comprehensive. It should be simple and to the point.
- Understandable: Your acceptance criteria serve no value if the developers are not able to understand the same. Discuss with them and modify them until everything is clear.
- Provide user perspective: Acceptance criteria should describe a problem from the perspective of users. It should depict the real-life user experience.
Examples and format of good acceptance criteria
Acceptance Criteria can be written in two formats-
1. Scenario-oriented acceptance criteria (Given/When/Then): Scenario-oriented acceptance criteria is a type that describes the same in the form of a scenario. It follows the Given/When/Then) approach which is as follows-
- Given some precondition
- When I take some action
- Then I anticipate a favorable outcome
This approach is borrowed from Behavior Driven-Development (BDD) where testers are provided with a concrete structure that prescribes when to start and end testing a particular functionality. It also minimizes the time that is spent on writing the test cases.
- Scenario – the name for the behavior that will be detailed
- Given – the start status of the scenario
- When – specific action taken by the user
- Then – the result of the action in “When”
- And – used to continue any of above three statements
“As a website user, I want to be able to search on the webpage So that I can find necessary information.”
Scenario: User searches for an item by its name
Given that I’m in the role of registered or guest user
When I open the “Products” page
Then the system shows me the list of all products
And the system shows the “Search” section in the right top corner of the screen
When I fill in the “Search” field with the name of an existing item in the product list
And I click the “Apply” button OR press the Enter key on the keyboard
Then the system shows products in the Search Results section with product names matching entered product name
And the system shows the number of search results at the top of the Search Results section”
2. Rule oriented Acceptance Criteria: The Rule oriented acceptance criteria contain a set of rules that narrate the behavior of a system.
This type of acceptance criteria is suitable when-
- The developers don’t require a detailed test scenarios
- Software design needs to be elaborated
- The user stories detail a system functionality level requiring a unique QA approach
As a user, I want to use a search field to type a brand, size, or cost, so that I could find results for matching shoes
- The search field is located on the top right bar.
- Search starts when the user clicks “Search.”
- The search field contains a placeholder with grey-colored text, “What are you looking for?”
Who is responsible for writing acceptance criteria?
The Product Owner is responsible for writing the acceptance criteria with the entire cross-functional team chipping with their contributions. The acceptance criteria should be written from the end-users perspective.
The development team should be involved since they will be able to define acceptance criteria addressing the customers’ needs. Involving the development team can help the Product Owner communicate the product vision and roadmap to them.
Second, it helps the developers identify dependencies that might have slipped from the radar.
When should you write acceptance criteria?
While there is no hard and fast rule as to when the acceptance criteria should be written, it is ideal to write it before the development starts.
A common practice used by product owners and product managers is to write the acceptance criteria during backlog refinement events. This is later discussed in the sprint planning meeting with the development team and modified as per their feedback.
One mistake that teams should avoid committing is writing the acceptance criteria way early. Since reprioritizing is an agile practice, you reprioritize user stories from sprint to sprint.
You might be interested in reading: Definition of Done vs Acceptance Criteria
Limitations of writing Acceptance Criteria
While Acceptance Criteria has a fair share of benefits, there are a few limitations that weaken its stance. Here are a few common downsides of acceptance criteria-
- Extremely Narrow: Acceptance criteria is written for a specific use case, scenario, or technical case. Because a solution is already devised when writing acceptance criteria, there’s a high chance of leading the developers in a different direction. A pitfall of being narrow is that the testing might overlook user behaviours not specified in the acceptance criteria. As a result, poor testing equals higher chances of failure.
- Unnecessarily broad: A common criticism of acceptance criteria is that it is unnecessarily broad. When the acceptance criteria is too detailed, the user story may get lost in communication. An effective acceptance criteria should prescribe a limit so that developers can code for what is required and nothing less or more.
- Complicated: Acceptance Criteria becomes complicated when there is too much jargon and technical terms involved. Acceptance criteria should be written in plain and simple language so everyone understands them.
Exceptional Acceptance Criteria aren’t hard to write. Here are seven best practices to help you write an acceptance criteria that is valuable-
1. Document your criteria before development begins: Acceptance criteria serves no purpose if its created after, during, and towards the end of the development process. It must be documented early before the development process starts. This clean practice helps the development team understand the customer requirements so they can later plan the development.
2. Avoid making it narrow: In your attempt to make the acceptance criteria as crystal clear, the outcome is too specific. This leaves the developers confused. The acceptance criteria should convey intent and the ultimate solution.
A narrow criteria increases the chances of leaving out user actions that might be significant.
3. Achievable: Stuffing your acceptance criteria with too many functionalities will leave the developers working on too many tasks at once. Keep it simple, so the development team can work on what’s important.
4. Make it actionable: Being too broad renders the acceptance criteria useless. It should just outline the task for the developers to understand the user requirements and start working on it.
Include just the details needed for the developers to take action.
5. Ditch technical for simplicity: Jargons and technical terms won’t help the development team. The acceptance criteria should be written in plain and simple language so all the non-technical stakeholders can understand them easily.
6. Shared understanding: The acceptance criteria should be able to communicate the user requirements to the stakeholders and the development team. There should be a shared understanding as to what tasks are a priority and what aren’t.
As we conclude the blog post, here are the key takeaways-
- Acceptance Criteria is the set of predefined conditions that must be fulfilled to ensure that the product fulfills end-users expectations.
- Acceptance Criteria should be easy to test, understandable, simple, and convey user perspective.
- The Acceptance Criteria should preferably be written before the beginning of the development session and not after it starts.
So, what were your learnings? If you need help with writing captivating acceptance criteria, then we’re right here to help.
We are a team of Professional Scrum Trainers (PST) and Enterprise Agile coaches actively working as Scrum Trainers, Agile Coaches, Scrum Masters/Product Owners aimed at delivering quality and consistency for our students across the globe.