The work of modern Agile teams involves the use of certain artifacts, among which are user requirements and acceptance criteria. The latter allows us to clearly formulate expectations from the final product and avoid misunderstandings between the customer and developers of this digital solution. Even though the importance of writing acceptance criteria is obvious, many teams either forget about it when creating a product backlog or do not determine acceptance criteria qualitatively.
When defining acceptance criteria, first of all, it should be mentioned that, together with the user story, they are the main ways of documenting the requirements for the developed product. The relationship between the user story and acceptance criteria is fundamental to Agile planning, ensuring that all team members understand what needs to be delivered.
In this article, we decided to figure out how to write good acceptance criteria for user stories. Let’s brief guide to acceptance criteria terminology (AC, using abbreviation to terminology)
What are the acceptance criteria in testing?
User story acceptance criteria are a list of conditions that an app must meet in order to fully fulfill the tasks assigned to it, highlighting the necessity of writing acceptance criteria that align with the end user’s needs. The software product must meet the target audience’s expectations and not contradict the main market application trends; in a word, it must be accepted by the general public and the direct customer.
It is worth noting that ACs are not repeated from one user story to another, and their task is to determine the options for feature usage by the end user.
AC are important for the development team to accurately understand the customer’s vision because each person may have a different perception of the same goal in software development (SDLC). And, accordingly, a different approach to its solution.
User story VS acceptance criteria
In contrast to the acceptance criterion, the user story describes a specific software function from the user’s point of view. The acceptance criteria’ purpose is to clearly articulate the task that the software product must perform in order to fulfil the client’s needs.
Here’s some background. In 2001, Ron Jeffries wrote about the Three C’s of the user story:
- Card – stories are traditionally written on notecards, and these cards can be annotated with extra details
- Conversation – details behind the story come out through conversations with the Product Owner
- Confirmation – acceptance tests confirm the story is finished and working as intended.
In a workflow based on the Agile methodology, user stories depict the project work yet to be performed by the team. Let’s look at the examples below đź‘€
Typically, user stories are written in the following format:
“As (the type of user) – I want (to do something) – so that I (can achieve a certain result, goal, or benefit).”
Although some teams in the same situation use abbreviated syntax, which speeds up the process of writing a user story.
In abbreviated format, the user story will look like this:
“User type – feature – result.” Logically, this result is our acceptance criteria âś…
All features that should be present in the program make up the product backlog. It is developed by the Project Manager(PM) or Product Owner(PO is the person who represents the customer for the thing you’re developing), taking into account the priority of implementing one or another functionality.
Acceptance criteria VS the definition of done
People are sometimes unsure of the difference between acceptance criteria and the definition of done. The key difference is that the definition of done applies to all your work, whereas acceptance criteria are specific to individual stories.
Example acceptance criteria
To illustrate the importance of well-written acceptance criteria, consider the next comparison of product filter categories on the e-shop site:
A client approached you to develop an e-commerce platform specializing in selling devices. They want users to be able to search for the products they want in certain categories (smartphones, tablets, laptops, etc.). The task can be understood ambiguously if you don’t write the acceptance criteria.
The first user story acceptance criteria example is to implement the search function in such a way that customers would have to specify the category of interest manually.
The second example is that the customer could imply selecting the desired product category from a ready-made catalog.
The result: due to the lack of clearly formulated AC, the ready-made software does not meet the client’s expectations.
Why do teams need clearly written acceptance criteria?
The fact that all team members need effective acceptance criteria is an undeniable fact, and we have already made sure of that. Let’s talk more about the benefits you can get from well-written acceptance criteria:
- Confirmation of user story completion. How does a developer know that a digital solution is working properly, that is, the user story is complete? Without clear criteria, it would be very difficult to do so.
- Reaching an understanding between a customer and a developer. Documented acceptance criteria will allow for meeting the expectations of both parties. The team of specialists working on the project clearly understands the client’s vision, and they, for their part, know in advance what they will get from the software solution.
- Optimal workflow planning. Given the fact that each user story is an unfinished task facing the team of developers, its exact description by creating acceptance criteria allows you to understand how important each such task is and to properly prioritize the work.
- Reliable basis for the acceptance tests. Clearly written acceptance criteria can be used as the basis for subsequent product testing. For this purpose, the result of checking AC and compliance of a particular function with it is used. There can be two options for this result: Pass or Fail.
Properly written user stories and acceptance criteria greatly simplify the testing and development process, so do not disregard this format for documenting the requirements for a future app.
Who is responsible for acceptance criteria?
It is a mistake to think that only business analysts can create acceptance criteria. The necessary knowledge and skills should guide all Agile team members and even the customer in this matter. Let’s look at a few options for who writes acceptance criteria:
Client-side presents competent personnel in the writing project documentation
This is a great way to build close cooperation between the client and the technical team. However, you should consider that even if the client has some experience in development and testing, it is still better to check the AC written by them before starting to work on the project. They should be clearly formulated and strictly correspond to the development process.
The responsibility for writing the AC is on the development team
If the customer decided to entrust the creation of the criteria to specialists, this task can be undertaken by any team member who knows the intricacies of implementing the app functionality and is aware of the technology stack used:
- QA Analyst
- Project Manager (PM)
- Tester (QA engineer or QA cordinstor)
- Business Analyst (BA).
Whoever is writing the acceptance criteria should do it in time, not before the start of development. This will help you better understand what you should work on first and what tools to choose to implement the necessary functions. Additionally, these criteria should be aligned with the relevant user stories to ensure that they meet the end-users’ expectations and requirements effectively.
BDD way: Agile acceptance criteria Given/When/Then
Based on the tasks set before the developers and the existing goals of the project, you can choose one of three varieties of AC:
- scenario-oriented acceptance criteria
- rule-oriented criteria
- custom acceptance criteria formats
The first two formats are the most common, so let’s talk about them in more detail. The scenario-oriented format aligns closely with user stories, helping to ensure that development matches end-user needs. The rule-oriented acceptance criteria format focuses more on technical specifications and rules. Both methods aid in creating clear, testable acceptance criteria to guide the development process.
Scenario-oriented approach
This approach is popular because it can significantly reduce the time required to create test cases. After all, the app’s behavior will be described in advance. It is based on the principles of Behavior Driven Development, and the main distinguishing features are a clear structure and consistency.
Scenario-oriented AC involves writing using the Given/When/Then sequence, and it looks like this:
User Story:
As a user, I want to be able to log in through my Google account to get quick access to my account in the app
Scenario: Quick access to the system.
Given: a user enters the login page.
When: a user presses the Google button.
Then: a system offers to select the needed account.
And: a user enters their account information.
Rule-oriented AC
If you describe functions in your user stories that are difficult to fit into the GWT framework, or the end user doesn’t need such detailed test cases, you can choose another approach to writing acceptance criteria, which is called Rule-oriented. As the name implies, this acceptance criteria format is a list of rules arranged as a bulleted list. In practice, it looks like this:
User Story:
As a user, I want to be able to enter the name of the city and the area in the search field so that I can find a suitable rented apartment.
Acceptance criteria of search interface:
1. | The search field is on the left side of the top bar. |
2. | The search begins when the user clicks the “Search” button. |
3. | The field contains a gray “City, District” placeholder. |
4. | The placeholder disappears when the user starts entering text. |
5. | The search will be performed if the user enters the name of a city, a district, or all together. |
6. | Allowed search languages are English, French, and Italian. |
7. | The maximum text length is 300 characters. |
8. | The search cannot contain special characters. If the user uses a special character, a warning appears: “Invalid character.” |
How to write acceptance criteria?
Some recommendations from the professionals. Regardless of what agile development methodology you practice and what project management system you work with, there are general guidelines for writing AC that will help optimize the development process.
- Be sure to add acceptance criteria for all user stories. Remember that each user story is an unfulfilled task of the Agile team. And acceptance criteria clarify exactly how this task should be implemented. So you need to write at least one criterion.
- Create AC before you start software development. We want to draw your attention once again: writing AC after the start of the project will not allow you to understand customer expectations at the very beginning of cooperation. It can lead to problems in the implementation of the customer’s vision. Therefore, define acceptance criteria first and start development based on them.
- Avoid overly specific criteria. If you imply a specific solution for each AC, this leaves no room for developers to maneuver. In addition, other user behavior options may be missed in the testing process, greatly increasing the likelihood of failure.
- Too broad acceptance criteria are also bad. Effective acceptance criteria define for developers how much code to write and when it’s time to stop. If you make them too extensive, the user story will become incomprehensible and will be of no value to the team.
- Write independently testable AC. When writing the criteria, leave the option to test each of them independently from the others. Once you get a result (Pass or Fail), you can use them as the basis for acceptance testing.
- Avoid technical details. One of the benefits of the BDD methodology is the ability for non-technical experts to participate in the process of creating and testing software. This is achieved because all project documentation is written in an understandable language that is available to business analysts, product owners, and even customers. Adhere to this principle, including when writing AC.
- Consult with the client. Take into account that the options for using a particular feature may be formulated differently by the customer and developers. Therefore, when compiling the acceptance criteria, be sure to clarify the opinion of all other stakeholders and reach consensus on the vision of the implementation of the software functionality.
- Don’t write too much AC for one user story. The optimal number of criteria for one uncompleted task is no more than three. If there are significantly more (from six), it makes sense to divide the user story into several. This practice allows for faster delivery, and faster feedback and minimizes the risk of failure.
Despite the fact that when writing test cases in BDD format, you use clear, human-readable language, creating AC can be difficult. The above recommendations will help you avoid documentation errors and simplify the development process.
As you noticed, we a little bit expanded the well-known INVEST model criteria of Agile user stories:
- Independent
- Negotiable
- Valuable
- Estimable
- Small
- Testable
What should be in acceptance criteria, and what’s best to avoid?
In addition to the above recommendations, there are rules for formulating good acceptance criteria that will help make them clear and thus improve cooperation both within the Agile team and between developers and customers.
#1: Avoid negative sentences
Conditions that contain the particle “not” imply that the action must not happen under any circumstances. It takes too much time to check this condition, which makes it almost impossible. The best way out is to rewrite the user story or AC without the negation.
For example, acceptance criteria:
❌ “The system must not fail”
âś… Is better rewritten as: “The system must be available 85% of the time.”
#2: Refuse to use the passive voice
If the condition is written in the passive voice, it may not be clear who should perform a particular action. This will lead to AC ambiguity. Therefore, it is better to use the active voice when the subject performs an action (the predicate).
For example, acceptance criteria:
❌ “A link to the entered email address must be sent” does not have the clarity you want.
âś… It would be better changed to “The system sends a link to the entered email address.”
#3: Use nouns instead of pronouns
The use of pronouns is another reason why the acceptance criteria can become ambiguous. This is especially true when pronouns replace elements that appear in other requirements.
For example:
Scenario: User forgot password.
Given: The user goes to the login page.
When: The user clicks the Forgot Password button.
And: The user enters an email address to get a link to recover it.
In this example it is better to write the last sentence without using a pronoun:
And: enters an email address to get a link to recover the password.
#3: Try to use fewer conjunctions
If you use in acceptance criterion “and,” “or,” “as well as” “but” in most cases, it means that such AC can be divided into several. That is, to make it clearer.
For example:
Given: I am a user who has logged out, and I am on the login page
In this AC, the use of the conjunction “and” is inappropriate. It is more appropriate to split it into two criteria:
Given: I am a user who is logged out
And: I am on the login page
#4: Set achievable requirements
Using the words “always”, “never”, “all”, “100%” when formulating the criteria will not allow you to check such a condition, because it is almost impossible to achieve absolute values.
Let’s return to the example of a system that must not fail.
❌ The requirement “The system must always be available” is unattainable.
âś… It is better to formulate this condition more objectively: “The system must be 90% available.”
Wrap-up: Make acceptance criteria part of your user stories
We hope that the acceptance criteria examples and recommendations in this material will help you in writing good acceptance criteria and conducting effective acceptance tests.
Also, allow development teams to reach consensus with customers and develop software that fully meets the needs of end users.
Frequently asked questions
What are the acceptance criteria and their roles in projects?
In Agile, acceptance criteria are a set of predefined conditions or requirements that must be met to mark a user story complete. Acceptance criteria are also sometimes called the definition of done because they define clear, measurable, and testable standards and requirements that must be executed by the team to consider the user story finished. It allows us to evaluate whether the app is deliverable for the market or no.
Roles of acceptance criteria in web projects:
- Clear expectations: acceptance criteria help to clearly define what is expected from a project or a specific feature, reducing ambiguity and misunderstandings.
- Define the Scope: acceptance criteria frame the boundaries of what needs to be done.
- Focus on Objectives: acceptance criteria point to clear goals on what should be done for delivering, by the development team.
- Prioritization: they help prioritize tasks by outlining which features or functions are necessary for the project to be accepted.
- Test Design: acceptance criteria might be used to develop test cases allowing QA to verify the functionality and correctness of the product.
- Feedback loop: Acceptance criteria facilitate feedback from stakeholders, ensuring that the product aligns with business goals throughout the development process.
- Scope Control: acceptance criteria help manage scope by clearly describing what is included in the release. This ensures the project stays on track.
Who writes acceptance criteria?
Acceptance criteria are typically written collaboratively by:
- Product Owner: defines and prioritizes requirements based on business goals.
- Business Analysts: clarify and document requirements.
- QAs: they ensure the testability of acceptance criteria, and identify verification conditions. Sometimes they perform the functional responsibilities of BA, a role named QA Analysts.
- Stakeholders: Provide insights and feedback, QAs and BA ensure that criteria meet business needs and expectations.
- Development Team: also provide feedback that criteria are technically realistic.
This collaborative approach guarantees that acceptance criteria are clear, comprehensive, and aligned with technical and business goals.
When to Write Acceptance Criteria?
Acceptance criteria might be written early in the different stages development process to ensure clarity and alignment. Here are key times to write acceptance criteria are:
- During Requirement Gathering
- Before Development Starts
- During Backlog Refinement
- When Requirements Change
- In the Review Process.
How to Define Acceptance Criteria?
Defining acceptance criteria involves creating clear, specific, and testable conditions that a product or feature must meet to be considered complete. Here’s how to effectively define acceptance criteria:
- Gather Requirements
- Clarify Objectives
- Use Clear and Simple Language
- Make Criteria Testable, don’t forget to include conditions
- Align with the user stories or requirements they are associated with
- Make sure that reqs. reflect Business Value
What is the right amount of Acceptance Criteria?
The are no right amount of acceptance criteria, the right amount is up to you, your scope should provide clear, testable, and comprehensive requirements without being overly complex.