How to write acceptance criteria: Purposes, Types, Examples and Best Prac

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.

User Story Template

As A “Registered User”

I WANT TO “Search for books by author’s name”

SO THAT “I can find and buy books by my favorite author”

Importance of Acceptance Criteria

A 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.

Characteristics of a Good Acceptance Criteria

An 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.

As promised, we will provide you with acceptance criteria templates to help you write the best one.

Tips for Writing Acceptance Criteria with Examples

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 was taken by the user
• Then – the result of the action in “When”
• And – used to continue any of the above three statements

Acceptance Criteria example (scenario-oriented):

“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

Acceptance Criteria example (rule-oriented): 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 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.

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 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.

Now that we are well aware of what acceptance criteria are, what their importance is, their types, and so much more — it’s time to learn the best practices for writing acceptance criteria.

Best Practices for the writing of the Acceptance Criteria

• 1Document 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.
• 2Avoid 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.
• 3Achievable: 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.
• 4Make 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.
• 5Ditch 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.
• 6Shared 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 Takeaways

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.