What is Acceptance Criteria?
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. This article will define acceptance criteria, look at a few examples, and explore some best practices for writing it.
In agile methodologies, acceptance criteria refer to a set of predefined requirements that must be met to mark a user story complete. They are a form of agile requirements documentation. As with most things agile, there are varying definitions of acceptance criteria.
- Acceptance Criteria Definition 1: “Conditions that a software product must satisfy to be accepted by a user, customer or other stakeholder.” (via Microsoft Press)
- Acceptance Criteria Definition 2: “Pre-established standards or requirements a product or project must meet.” (via Google)
Acceptance criteria are also sometimes called the “definition of done” because they define the scope and requirements of user stories. They give developers the context needed to execute on a user story. Watch our short explainer video, below.
What are a few traits of effective acceptance criteria?
- Acceptance criteria should be testable. Since these requirements help formulate the definition of done for your engineers, they need to be easy to test. And the results of these tests must leave no room for interpretation. Tests should reveal straightforward yes/no or pass/fail results.
- Criteria should be clear and concise. You aren’t writing comprehensive documentation here. Keep your criteria as simple and straightforward as possible.
- Everyone must understand your acceptance criteria. Your criteria is useless if your developers can’t understand it. If you’re unsure about whether something is clear, take the time to ask and make adjustments until things are clear.
- Acceptance criteria should provide user perspective. Acceptance criteria is a means of looking at the problem at hand from a customer’s standpoint. It should be written in the context of a real user’s experience.
Why Do You Need User Story Acceptance Criteria?
Acceptance criteria serves several purposes for cross-functional teams.
Let’s dive in a little more into the benefits of acceptance criteria.
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.
Who is Responsible for Writing Acceptance Criteria?
Virtually anyone on the cross-functional team could write acceptance criteria for user stories. Usually, the product owner or manager is responsible for writing acceptance criteria or at least facilitating the discussion about it. The idea behind that is to ensure that the requirements are written with customer needs in mind, and who better to understand customer needs than a product person? That said, it is widely recommended to make writing acceptance criteria a group activity that includes both dev and QA representatives.
Involving developers and QA as you define acceptance criteria has several benefits. For one, it gives you another opportunity to communicate with developers about product strategy and vision. Secondly, developers and QA staff can help point out any missing pieces or identify dependencies that may not have been clear before. Finally, these discussions can help you as the product owner better understand what your user stories look like through the eyes of developers. So whenever possible, define done together.
When Should User Story Acceptance Criteria Be Written?
Many product managers and product owners choose to write acceptance criteria during backlog grooming sessions. They then bring this criteria to sprint planning meetings to discuss with developers and refine based on their feedback. But there is no rule for specifically when to write these requirements out.
At the very latest, acceptance criteria should be defined before development begins. Otherwise, you’ll miss many of the benefits of having it in the first place. It’s also worth noting that writing acceptance criteria too early can backfire as well. Remember, the agile methodology encourages frequent reprioritization based on new findings. And that means you can reprioritize user stories from sprint to sprint.
One way to balance this uncertainty is to only write acceptance requirements when you decide to move something into the sprint backlog. This way you aren’t spending time writing out specs for user stories that ultimately get deprioritized. Once you’ve moved user stories into the sprint backlog, it’s fairly certain that they are up next. So you can go ahead and loosely define acceptance requirements and later discuss and finalize them during sprint planning meetings.
How Should You Format User Story Acceptance Criteria?
There’s no single right or wrong way to write acceptance criteria for a user story. Ultimately, you need to establish a format and procedure for creating acceptance criteria that consistently works for your team. Expect a little bit of trial and error if you’re new to this. Most agile organizations use one of two formats for their acceptance criteria:
1. Given/When/Then Acceptance Criteria
The Given/When/Then style of user story requirements is similar to the traditional formatting for user stories themselves. The standard user story follows the template: “As a (intended user), I want to (intended action), so that (goal/outcome of action).” User acceptance criteria in given/when/then format follows the template: “Scenario: (explain scenario). Given (how things begin), when (action taken), then (outcome of taking action).”
It looks a little confusing until you see a realistic example of a user story paired with given/when/then acceptance criteria. So here’s an example.
Example Acceptance Criteria – Given/When/Then
User story:
As a product manager.
I want to score potential ideas.
So that I can decide what to include on my product roadmap.
Acceptance criteria for that user story could be:
Scenario: The product manager adds potential ideas and ranks the best ideas based on benefit versus cost.
Given that I have added two or more ideas and scored them using the Benefit vs Cost scoring model
When I click the Rank button
Then ideas are sorted with the top-scoring ideas at the top.
2. Verification List Acceptance Criteria
Formatting your user story requirements as a checklist is another viable option. It’s also extremely straightforward. You simply work as a team to define a list of pass/fail statements that the functionality must meet in order to be marked complete.
At the end of the day, the format of your acceptance criteria doesn’t matter as much as its practicality. If your team understands it and is able to work off of it, you’ve managed to create effective acceptance criteria. No matter what the format looks like.
The Bottom Line:
Acceptance criteria is an important component of every user story that an agile team works on. It clearly defines the scope, desired outcomes of, and testing criteria for pieces of functionality that the delivery team is working on. The process of creating and agreeing on acceptance criteria itself is also an invaluable communication opportunity between developers and product.
Watch the webinar on managing complex requirements in an agile world to keep learning more.
See also: Acceptance Test, Definition of Done, Backlog Grooming, User Story