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.
The result? Shoddy product increments. If you’re looking to learn about acceptance criteria, their purpose, types, format, and more — then this blog post with real-life acceptance criteria examples and user story templates will be your guide.
What are Acceptance Criteria?Acceptance Criteria is the set of predefined conditions that must be fulfilled to ensure that the user story is complete. So, what is the user story? In the simplest terms, a User Story is a way of expressing requirements from the perspective of the user of the product or system, or software.
A User Story follows 3C’s – Card, Conversation, and Confirmation. In addition, it is often helpful to have six attributes defined by the acronym INVEST – Independent, Negotiable, Valuable, Estimable, Small, and Testable, to be part of a user story.
If you want to learn how to write good user stories, then you must read our guide to 10 tips to write great user stories – from the elements of a user story to its types and characteristics, it has it all.
We know that by just learning what the acceptance criteria and user story is, it won’t be enough until you learn the importance of writing it and how to write one. Let’s learn with good acceptance criteria examples to have better clarity.
Before you proceed further, we recommend you read the definition of done vs acceptance criteria.
User Story TemplateAs A “Registered User”
Please note that there are no fixed acceptance criteria templates like user story since but you will have a better understanding when you read acceptance criteria examples which we have discussed below.
Importance of Acceptance CriteriaA well-articulated acceptance criterion 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 helps us to: -
- 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 criterion 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.
We won’t let you wonder if you have written the acceptance criteria correctly or not, therefore, we will show you what a good acceptance criteria looks like.
Learn how to write good acceptance criteria: Sign Up for the PSPO Certification Training.
Characteristics of a Good Acceptance CriteriaAn Acceptance Criterion 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.
Acceptance Criteria ExamplesAcceptance 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
- Scenario – the name for the behavior that will be detailed
- Given – the start status of the scenario
- When – specific action was taken by the user
- Then – the result of the action in “When”
- And – used to continue any of the 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 a 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 detailed test scenarios
- Software design needs to be elaborated
- The user stories detail a system functionality level requiring a unique QA approach
- The search field is located on the top right bar.
- Search starts when the user clicks “Search.”
- The search field contains a placeholder with gray-colored text, “What are you looking for?”
We are quite sure that now you are at a better place than before with our acceptance criteria examples. If you want to learn the best practices of writing acceptance criteria, make sure you stick with us until the end.
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-user's 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. Now that you know that the product owner is responsible for writing acceptance criteria, it is also important when they should write one.
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 CriteriaWhile 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 are 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 behaviors 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. Effective acceptance criteria should prescribe a limit so that developers can code for what is required and nothing less or more.
- Complicated: Acceptance Criteria become 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.
Best PracticesExceptional 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 serve no purpose if it's 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 criterion 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: Jargon 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 isn’t. With that, we have reached the end of this blog. But surely, we won’t end it without having a quick overview of what we have learned so far.
Key TakeawaysAs 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.