How to Write Acceptance Criteria: Examples and Best Practices
How can you avoid misunderstandings in the software development process and properly set your expectations for a product? In this article, we dig into a very important but often overlooked element of the product backlog — acceptance criteria.
Here at Mobindustry, we operate with an Agile approach. That means we use Agile components like user stories and acceptance criteria. High-performing teams and organizations have these components in their product backlogs, and they know how to create them and use them effectively.
If your product backlog lacks user stories and acceptance criteria — or if they’re not clearly defined — you risk your expectations not converging with reality. User stories and acceptance criteria are responsible for representing how the end user will use your app and how your development team should execute each development task. When we start working on a new product, our team collaborates with the client to define user stories.
A user story is a short, simple description of a product feature from the perspective of a person who wants to use that feature. User stories are used to define the product backlog in an Agile development workflow.
The product backlog is essentially a collection of user stories that informs the functional specification and the development of features for a particular product or service. User stories consist of three parts: a persona of the user the story is being written for, a description of the feature the user requires, and an explanation of the need the feature satisfies.
Here’s how to write a user story:
As a (user) I want a (feature) so that I can (satisfy a need).
Let’s take a look at how a user story might look. We’ll take Airbnb as an example. Let’s imagine how a typical user story might look for a product like Airbnb.
“As a user, I want to search for a destination so I can book accommodation in a foreign city.”
Definition of acceptance criteria
Now, we need to make sure that user stories are completed correctly and accommodate the client’s demands.
Acceptance criteria are the conditions that a software product must satisfy to be accepted by a user, customer, or, in the case of system-level functionality, the consuming system.
Acceptance criteria are a set of statements, each with a clear pass/fail result, that can be measured and specify both functional and non-functional requirements.
Writing acceptance criteria is important not only for establishing what the client expects of the product but for the development process. Naturally, different people see the same problem from different angles. Well-defined acceptance criteria provide a uniform view of the functionality you plan to implement.
Anyone should be able to walk up to a Scrum board, grab a product backlog item, read the acceptance criteria, and clearly see everything that needs to be completed for that particular item to be moved to the done column. Acceptance criteria tell you what needs to be done for a particular part of a product to be finished.
Why do we need acceptance criteria?
- Defining boundaries. Acceptance criteria help the development team define the boundaries of a user story. They serve as a form of confirmation that the app is working as expected, which means the user story is complete.
- Reaching consensus. Acceptance criteria allow the development team to be on the same page as the client. They inform the development team about exactly what conditions must be met and ensure the client knows what to expect from the application.
- Streamlining acceptance testing. Acceptance criteria are the foundation of user story acceptance testing. Every acceptance criterion should be tested independently and have clear scenarios for success or failure.
- Planning and estimating. Acceptance criteria allow you to distribute user stories across tasks so they’re properly assessed and scheduled.
- Describing negative scenarios. Acceptance criteria may require the system to identify a weak password and prevent a user from continuing, for instance. Entering an incorrect password format is an example of a negative scenario in which a user enters incorrect data or behaves unexpectedly. Acceptance criteria identify these scenarios and explain how the system should respond to them.
Who writes acceptance criteria?
Writing acceptance criteria helps to establish a common understanding between the product owner and the development team with regard to solving a customer’s problem or creating product capabilities. Since acceptance criteria relate to the client and the team, they should be written either by the client or a team member.
At Mobindustry, our business analysts write all the acceptance criteria for user stories. Business analysts understand the client’s needs and what developers need to know to meet the project requirements.
Acceptance criteria are documented and confirmed before the start of the project, as the team and the client need to agree on what outcomes will meet the client’s requirements.
Examples of user stories with acceptance criteria
Now that you have a clear understanding of what user stories and acceptance criteria are, let’s take a look at some examples.
User story: As a user, I want to be able to register in the service so that I can start shopping online.
- Users can only submit a form by filling in all the required fields.
- The email the user provides must not be provided by a free email service.
- Submissions from the same IP can only be made three times within 30 minutes.
- Users receive notification emails after successfully registering.
User story: As a user, I am able to access a notification on my device immediately after receiving it.
- Swiping/tapping a notification takes the user directly to the message.
- View shows conversation — if the new message was a reply, then it’s displayed above the original.
- Message count is updated.
- A message is marked read after it’s displayed.
7 tips on writing good acceptance criteria
Acceptance criteria aren’t easy to write. Despite the simple format, writing the text is a challenge. Here are seven tips to help you avoid common mistakes while writing acceptance criteria or to review criteria written by a member of your team.
- Document criteria before the development process starts. In this way, the team is more likely to catch all of the client’s needs in advance. Initially, it’s enough to set criteria for a small number of user stories to complete backlogs for two sprints. The documented acceptance criteria are then used by developers to plan the technical process.
- Don’t make acceptance criteria too narrow. Acceptance criteria that’s too specific leaves developers little room to maneuver. To avoid this, remember that acceptance criteria should be an expression of intent, not a final decision. Moreover, narrow acceptance criteria may not take into account all user actions.
- Keep your criteria achievable. Effective acceptance criteria define a reasonable minimum amount of functionality that you can provide. But if you keep describing all the little details, there’s a risk that your team will get stuck on hundreds of small tasks.
- Avoid too broad of acceptance criteria. Broad acceptance criteria makes a user story vague. Effective acceptance criteria must outline the scope of work so that developers can properly plan and estimate their efforts.
- Avoid technical details. Acceptance criteria should be written in plain language. Your stakeholders and managers may not have technical backgrounds, so using plain language will make the criteria understandable for everyone.
- Reach consensus. The same problem can be solved in different ways by team members and stakeholders depending on their points of view. Make sure you communicate your acceptance criteria to stakeholders and team members and reach a mutual agreement.
- Write testable acceptance criteria. This will give testers the opportunity to ensure that all requirements are met and will allow developers to know if the user story is complete.
How to write acceptance criteria
Here are five general rules that will help you solve problems with the wording of acceptance criteria. These rules will let you save valuable time and establish an understanding between the product owner and the development team.
Rule #1: Avoid “not”
“Not” means “in no case,” and therefore no amount of time will be enough to verify compliance with such a condition. If you rewrite the requirement without using “not,” it will be clearer and, most importantly, verifiable.
Don’t: As a user, I do not want to have to enter my password every time I access my account.
Do: As a user, I want my password to be remembered and automatically filled in so that I can access my account without re-entering my password.
Don’t: The system must not fail.
Do: The system should have an availability of no less than 90%.
You can use “not” in acceptance criteria to introduce a logical objection, such as “the login form should not be red.” In most cases, this will apply to non-functional requirements. In this example, we formulate a constraint that can be easily verified if the range of shades of red is clearly defined (for example, specified in RGB format).
Rule #2: Use active voice
Active voice is when the subject in a sentence is the performer of the action. If the entity responsible for executing the action is not clearly indicated, it will be unclear who or what should perform the action, and it will be more difficult for you to verify whether a requirement is fulfilled.
Don’t: As an online shopper, I want filters to be applied so that I can find what I want.
Do: As a user, I want to apply search filters so that I can find items.
Don’t: The identity of the customer should be confirmed. (It is unclear who or what is responsible for confirming the identity of the customer.)
Do: The Accounting_System should confirm the Customer_Indentity. (Note that the definitions of the terms “Accounting_System” and “Customer_Indentity” should be added to the glossary.)
Rule #3: Avoid using pronouns (especially undefined ones)
Use nouns instead of pronouns when referring to items referenced in other requirements. Pronouns should be avoided because they may introduce ambiguity.
This is especially important when acceptance criteria are stored in requirement management tools (such as Jira) as separate statements that are not necessarily organized. Always use nouns instead of pronouns and you’ll avoid this problem.
Don’t: As a site member, I want to share information about myself so that others can see it.
Do: As a site member, I want to add a profile description so that others can learn about me.
Don’t: The controller should send the driver the itinerary for the day. It should be delivered at least 8 hours prior to the shift.
Do: The Controller should send the Driver_Itinerary for the day to the Driver at least 8 hours prior to the Driver_Shift.
Rule #4: Avoid conjunctions
Conjunctions are words and phrases such as “and,” “or,” “but,” and “as well as” that combine simple sentences into complex ones. Their use in requirements is usually a sign that a requirement can be broken down into several separate requirements.
Don’t: As a UI designer, I want to create and view an issue so that I know what to test.
Do: As a UI designer, I want to create an issue so that I know what to test. / As a UI designer, I want to view an issue so that I know what to test.
Don’t: The user should either be trusted or not trusted.
Do: The Security_System should categorize each User as either Trusted or Not_Trusted.
“And,” “or,” and “not” can be used to describe logical conditions and add qualifiers.
Rule #5: Avoid unattainable absolutes
An absolute (such as 100% availability) is unattainable. Think about how to check the indicator: will it be possible to prove that the level of system availability is exactly 100%? And even if such a system could be created, can you afford it?
Avoid the words “all,” “always,” and “never,” as checking such absolute requirements will require an infinite number of tests.
Don’t: As a traveler, I want to know my precise location updated in real time so that I don’t get lost. (“Real time” can be interpreted in different ways. For example, it can be seen as an absolute (the absence of any delay), which cannot be achieved and which is not verifiable.)
Do: As a traveler, I want to know my precise location, updated every second, so that I don’t get lost.
Don’t: The system should have 100% availability. (100% is an absolute that cannot be reached and cannot be verified.)
Do: The system should have an availability of at least 98%.
Quick summary of acceptance criteria
We hope this article has shed light on the world of acceptance criteria and user stories. Here are the key takeaways:
- Acceptance criteria are the conditions a software product must satisfy to be accepted by a user, customer, or in the case of system-level functionality, the consuming system.
- Acceptance criteria should be documented and completed before the start of a project, as the team and the customer must agree on what results will meet the client’s requirements.
- Remember that acceptance criteria should be an expression of intent, not a final decision.
- Effective acceptance criteria define a reasonable minimum amount of functionality.
- Good acceptance criteria must outline the scope of work so developers can properly plan and estimate their efforts.
- Acceptance criteria should be written in plain language.
- Make sure you communicate your acceptance criteria to stakeholders and team members and reach a mutual agreement.
- While writing acceptance criteria, avoid using “not,” conjunctions, and unattainable absolutes. Formulate sentences using active voice.
If you want to create acceptance criteria and user stories for your mobile app or if you have any questions regarding this topic, contact Mobindustry for a free consultation.