In Agile, acceptance criteria refer to a set of predefined requirements that must be met to mark a user story complete. Acceptance criteria are also sometimes called the “definition of done” because they determine the scope and requirements that must be executed by developers to consider the user story finished.
As a product manager or product owner, you may be responsible for writing acceptance criteria for the stories in your product backlog.
Why Do You Need User Story Acceptance Criteria?
Acceptance criteria serves several purposes for cross-functional teams.
A user story on its own leaves a lot of room for interpretation. Acceptance criteria clarifies the expected outcome(s) of a user story in a concrete manner. It also gives developers and QA a clear-cut way to determine whether a story is “done.”
You want to incorporate these requirements into your process for many reasons. First of all, when you define your desired outcome before development begins, you help promote alignment and shared understanding. This understanding helps reduce the likelihood of surprises down the line.
In addition to helping product people set and manage expectations, acceptance criteria is also helpful for developers. Not only does the added context reduce ambiguity, but also creates a great defense against scope creep. If a requirement isn’t defined and set at the beginning of a sprint, it’s more difficult to sneak it in midway through. Finally, acceptance criteria often defines the fail/pass testing that will be done to determine whether a user story is complete.
What are the acceptance criteria and their role in projects?
Acceptance criteria (AC) are the conditions that a software product must meet to be accepted by a user, a customer, or other systems. They are unique for each user story and define the feature behavior from the end-user’s perspective.
Acceptance criteria main purposes
Clarifying the stakeholder’s requirements is a high-level goal. To make the purposes of AC clearer, let’s break them down.
Making the feature scope more detailed. AC define the boundaries of user stories. They provide precise details on functionality that help the team understand whether the story is completed and works as expected.
Describing negative scenarios. Your AC may require the system to recognize unsafe password inputs and prevent a user from proceeding further. Invalid password format is an example of a so-called negative scenario when a user does invalid inputs or behaves unexpectedly. AC define these scenarios and explain how the system must react to them.
Setting communication. Acceptance criteria synchronize the visions of the client and the development team. They ensure that everyone has a common understanding of the requirements: Developers know exactly what kind of behavior the feature must demonstrate, while stakeholders and the client understand what’s expected from the feature.
Streamlining acceptance testing. AC are the basis of the user story acceptance testing. Each acceptance criterion must be independently testable and thus have clear pass or fail scenarios. They can also be used to verify the story via automated tests.
Conducting feature evaluations. Acceptance criteria specify what exactly must be developed by the team. Once the team has precise requirements, they can split user stories into tasks that can be correctly estimated.
Since different people can have different points of view and solution ideas regarding one problem, creating a unified vision of how the functionality should be implemented is necessary. That’s exactly what clearly written acceptance criteria do.
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.
Example:
User Story
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.
Acceptance criteria
Don’t: The system must not fail.
Do: The system should have availability of no less than 90%.
Exception
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.
Example:
User story
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.
Acceptance criteria
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.
Example:
User story
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.
Acceptance criteria
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.
Example:
User story
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.
Acceptance criteria
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.
Exception
“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.
Example:
User story
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.
Acceptance criteria
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%.
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.
Example 1
User story: As a user, I want to be able to register for the service so that I can start shopping online.
Acceptance criteria:
- Users can only submit a form by filling in all the required fields.
- The email the user provides must not be provided by free email service.
- Submissions from the same IP can only be made three times within 30 minutes.
- Users receive notification emails after successfully registering.
Example 2
User story: As a user, I am able to access notification on my device immediately after receiving it.
Acceptance criteria:
- 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.
- The message count is updated.
- A message is marked read after it’s displayed.
7 Tips for Writing Acceptance Criteria:
- Each product backlog item or user story should have at least one acceptance criteria. Hey, don’t take writing acceptance criteria lightly or think of skipping it.
- Acceptance Criteria is written before implementation – this is obvious yet frequently missed by teams. Write acceptance criteria after the implementation and miss the benefits.
- Each acceptance criterion is independently testable. Why shouldn’t it be?
- Acceptance criteria must have a clear Pass / Fail result. Write complex and long sentences at your own risk.
- It focuses on the end result – What. Not the solution approach – How.
- Include functional as well as non-functional criteria – when relevant.
- Team members write acceptance criteria and the Product Owner verifies it. It confirms the PO and the team have shared understanding of the user story.
A Checklist for Writing Acceptance Criteria
- Clear to everyone involved
- Can be tested or verified
- Either passes or fails (cannot be 50% completed, for example)
- Focus on the outcome, not how the outcome is achieved
- As specific as possible (fast page load speed vs. 3-second page load speed)
- NEVER USER ‘HOW’ eg – acceptance criteria – “The online shopping cart uses checkboxes to select which items you want to delete” is WRONG
7 Tips for Writing Acceptance Criteria:
- Each product backlog item or user story should have at least one acceptance criteria. Hey, don’t take writing acceptance criteria lightly or think of skipping it.
- Acceptance Criteria is written before implementation – this is obvious yet frequently missed by teams. Write acceptance criteria after the implementation and miss the benefits.
- Each acceptance criterion is independently testable. Why shouldn’t it be?
- Acceptance criteria must have a clear Pass / Fail result. Write complex and long sentences at your own risk.
- It focuses on the end result – What. Not the solution approach – How.
- Include functional as well as non-functional criteria – when relevant.
- Team members write acceptance criteria and the Product Owner verifies it. It confirms the PO and the team have shared understanding of the user story.
Who writes Acceptance Criteria?
Let me first burst a common myth that the Product Owner should write the acceptance criteria.
In fact, I recommend, you try ‘avoiding’ the Product Owner writes all the acceptance criteria. Why so?
Who writes the acceptance criteria, or who defines the acceptance criteria is not a matter of rules, availability or convenience.
What matters is – writing acceptance criteria (AC) should help establish and communicate shared understanding between the product owner and the development team about solving a customer’s challenge or building the product capability.
When you encourage the team members to write the AC, they must first understand the intended purpose of the feature and the outcome it must generate for the users.
Writing the acceptance criteria clarifies the scope for the team and also allows for the Product Owner to verify if the team and the PO have a shared understanding of the feature.
Alternately, Acceptance criteria may also be developed jointly by the development team and the product owner.
Acceptance criteria structures
- Scenario oriented acceptance criteria
- Given some precondition
- When I do some action
- Then I expect some result
This approach was inherited from behavior-driven development (BDD) and provides a consistent structure that helps testers define when to begin and end testing a particular feature. It also reduces the time spent on writing test cases as the behavior of the system is described upfront.
The acceptance criteria template in this format includes the following statements:
- Scenario – the name for the behavior that will be described
- Given – the beginning state of the scenario
- When – specific action that the user makes
- Then – the outcome of the action in “When”
- And – used to continue any of three previous statements
2. Rule oriented acceptance criteria
In some cases, it’s difficult to fit acceptance criteria into the Given/When/Then structure.
The rule-oriented form entails that there is a set of rules that describe the behavior of a system. Based on these rules, you can draw specific scenarios.
Usually, criteria composed using this form look like a simple bullet list. Let’s have a look at an example.
Example
User story: As a user, I want to use a search field to type a city, name, or street, so that I could find matching hotel options.
Basic search interface acceptance criteria
- The search field is placed on the top bar
- Search starts once the user clicks “Search”
- The field contains a placeholder with a grey-colored text: “Where are you going?”
- The placeholder disappears once the user starts typing
- Search is performed if a user types in a city, hotel name, street, or all combined
- Search is in English, French, German, and Ukrainian
- The user can’t type more than 200 symbols
- The search doesn’t support special symbols (characters). If the user has typed a special symbol, show the warning message: “Search input cannot contain special symbols.”
Other formats
Most user stories can be covered with two formats mentioned above. However, you can invent your own acceptance criteria given they serve their purposes, are written clearly in plain English, and can’t be misinterpreted. Some teams even use plain text.
For instance, your criteria may be specified as an example of system behavior:
What to include in acceptance criteria
When writing acceptance criteria, it’s important that all the statements are succinct and to the point, describing exactly what a specific application function does and what users expect from it. However, it should also account for the unique needs of both developers and testers.
For instance, development teams need the acceptance criteria to clearly state when certain dependencies or integration points come into play, such as any API-enabled database updates. This helps communicate the intended scope of application features and guides the process of updating functionality down the line.
For QA professionals and UATs, meanwhile, acceptance criteria need to provide clearly-defined and readily testable workflow expectations. For example, if information saved by the user gets passed to the database using an API, testers need to know when and how that transaction occurs. This way, they can know exactly what to look for when things go wrong.
References/Some good articles –
https://www.altexsoft.com/blog/business/acceptance-criteria-purposes-formats-and-best-practices/
The-Product-Space 
Leave a comment