In this article, we use real-life acceptance criteria examples and good practices to show how to write acceptance criteria, and how they can be used effectively and flexibly to ensure project success.
Have you ever worked on a project only to find out after completion that the result wasn’t quite what the client and stakeholders expected? Maybe the management and the team weren’t on the same page about what the final product should look like. This is where acceptance criteria come in.
While the purpose of user stories is to describe exactly what the users want from the software, and what goals they want to achieve, the purpose of acceptance criteria is to explain in detail, with a high degree of precision, the conditions that a given user story must meet.
Contents
What are the acceptance criteria?
(Yes, it is a plural, greek-origin word, its singular form is criterion.)
Acceptance Criteria (AC) are the lowest-level functional requirements that a software product must meet to be accepted by its users or the customer and be compatible with other systems. They are specific to each user story and describe the functionality from the end-user perspective.
Who writes the acceptance criteria?
Acceptance criteria are high-level goals that should be defined anytime before the sprint and the development work starts. Usually, the development team members write the acceptance criteria during the product backlog refinement meeting, and the Product Owner or Product Manager is responsible to validate them later. Sometimes they write they formulate the acceptance criteria together, or the Business Analyst writes the AC, as a part of the project documentation, there are no strict rules on this.
Whichever you choose, the point is that the PO, PM, or BA and the agile team have a clear, unified vision and a common understanding. The goal is to have a clear and unambiguous user story and your development team knows exactly what they need to develop and understand the scope of the user story or Product Backlog Item (PBI). A well-written feature scope is detailed and ensures that the completed product features fully meet the customer’s needs and expectations.
Acceptance criteria and the definition of done: what is the difference?
Acceptance criteria are also sometimes used as a synonym for “Definition of Done” (DoD). That’s a mistake, the two are not equivalent if you strictly apply the Agile methodology principles. The definition of done only applies to increments and does not impose such conditions on smaller units such as individual backlog items. AC on the other hand are mandatory elements of every user story.
Acceptance criteria and user stories
Acceptance criteria define the boundaries of user stories and help the team understand during the development process and testing whether the user story works as expected. Acceptance criteria can also describe negative scenarios.
Acceptance criteria help to align the client’s and the development team’s ideas. They give a unified vision to ensure that the requirements are understood in the same way by everyone, i.e. that developers understand exactly what user goal the feature will help to fulfill, while stakeholders and the customer effectively communicate what they expect from the feature. Then the team can move forward and split the user stories into that to be estimated.
Acceptance criteria must be independently testable for QA teams: when the Product Owner verifies the acceptance criteria of the user story and the feature created meets them, the development of the user story is considered successful. The Pass/Fail approach allows the acceptance criteria to form the basis for creating automated tests, so ACs must have a clear Pass / Fail result.
Acceptance criteria examples
Let’s see some effective acceptance criteria examples using a hypothetical, simplified story map showing the architecture of software similar to the Substack publishing platform:
User story
“As a blogger, I want to set up paid subscription plans so that my readers can choose how and for how long they commit to exclusive content and other extra services.”
Acceptance criteria:
“I can create new subscription plans. There are three types of subscription plans: monthly, annual, and founding. I can set the plan names, currency, prices, and further detail with lists of features. The users can choose one of the plans to subscribe to my exclusive newsletter list and get access to the paywalled blog content.”
Remember: use simple language and write short sentences, but try to be precise in your wording.
Now let’s see how it all looks on a story card in StoriesOnBoard’s story mapping tool:
Acceptance criteria examples: types and formats
Acceptance criteria can be written in different formats, such as the most popular scenario-oriented and rule-oriented formats.
Scenario-oriented acceptance criteria format
This type of structure is commonly used to write acceptance criteria in agile environments. The most common template for using a scenario-oriented approach is given in the following form:
“Given (precondition)/When (action)/Then (result).”
Let’s see how this works with the user story example above about creating subscription plans:
Scenario: The creation of subscription plans
Given: The user navigates to the Setting page.
When: The user selects the Payments option.
And: Choose a currency from a list.
And: Set the amount of money for each subscription plan.
Then: The system allows readers to pledge subscriptions.
Other natural acceptance criteria formats may also be appropriate, and you can create the acceptance criteria that best fit the solution.
Rule-oriented acceptance criteria format
A rule-oriented approach is relevant when the previous format is too difficult to apply.
Also using the acceptance criteria examples above, it looks like an acceptance criteria checklist:
Scenario: On the Setting page, you can select the Payments function from the list on the left. To set up payments there is a block with a toggle to activate the paid subscription feature. Underneath the box, I can set up three different packages: monthly, annual, and founding sponsorship. For each of these, I can select the currency from a drop-down list and enter the prices in this format: 1.00.
Expand your knowledge, follow us for more!
Acceptance criteria for user stories
One of the most crucial steps in the software development process is to clearly define the purpose of the product or service, both from the perspective of the prospective end users and the customer. It is the responsibility of the development team to fully understand these needs and to meet the requirements of each sub-solution during its development.
By writing clear acceptance criteria, we understand what content and functional elements a given user story should have. As a result, the new software will meet the business objectives and user needs.
Writing user stories and acceptance criteria may seem difficult if you are inexperienced or new to the process. Fortunately, there are examples and templates available, or if you want an even better solution, you can choose a user-friendly story mapping and product management tool like the one that StoriesOnBoard is based on.
Our tool has a built-in tutorial to help novice users learn how to write user stories and acceptance criteria, how to create good user story cards, and a complete backlog of them, called a user story map.
You get in-app help to
- Create user personas
- Split user stories into tasks
- Sync them with your issue tracker
- Prioritization
- Create the MVP and the further releases
- Create a visual product roadmap
- Collaborate with your team and stakeholders inside and outside of your organization… and more.
Build better products faster.
Get started with StoriesOnBoard today!
14-day Free Trial. No Credit Card is Required.
Summary
To ensure project success, it’s important to understand acceptance criteria, and how to use them effectively and flexibly adapted to the specific project. In this article, we have explored what the acceptance criteria are, why they are important, and provided acceptance criteria examples and best practices for their application in software development projects. Whether you’re a Product Owner, a Product Manager, a Business Analyst, a developer, a tester, or a stakeholder, understanding acceptance criteria can help improve your project outcomes.