How to write great acceptance criteria

Customers want great software products, businesses want to provide them, and development teams want to create them. But creating an end product that satisfies the user and client requires clear communication at every phase of a product's development to ensure that everyone agrees on the project's goals, process, and outcome. 

Whether you're a food vertical that wants users to search your site by ingredient type or a dating app that wants to display different genders or sexualities for users to select from in their profile, clearly identifying the needs you want your products to meet—and the conditions that the product must satisfy to fulfill them—is essential to making the best product possible with the least amount of confusion and delay.

This is where user stories and acceptance criteria come in. User stories help you and your client come together and develop a shared vision for a product before you begin development, articulating what needs you're meeting and for whom—and when you'll know you've reached your goal.

What are acceptance criteria, and what is their role in user stories?

In development circles—particularly when using Agile—teams want to define the features of the products they're developing to meet the end-user's needs. But everyone on a team has a different idea of what the end-user might want—or a different skillset or perspective they bring to the table—and even the most united teams can have trouble defining their project and determining when they've achieved their goal. 

User stories and acceptance criteria were designed to address these problems and make development work as effective and efficient as possible.

When development teams create their backlog, they begin by creating user stories. A user story is a simple description of a feature that a product user desires, as well as a description of how they will use that feature. It often takes the following form: As a [type of user], I want a [specific feature] so I can [meet a specific need]. For example, a library user might want a searchable online catalog so that she can discover whether a book is available without leaving her home.

User stories can be worked out between the client, the product owner, and the development teams to ensure everyone is on the same page. After that, though, it's up to the development team to deliver the feature. And that's where acceptance criteria enter the picture. Acceptance criteria are the conditions a development team must meet to complete a user story. In other words, acceptance criteria let teams know when they've created a feature that satisfies a user's needs. Acceptance criteria provide clear, achievable, testable standards that let a team know exactly when they've completed a piece of the product development puzzle—and when they can move on to the next task. They function as realistic timetables, allowing a team to map out how long a project will take and schedule themselves for success. And since formulating acceptance criteria requires buy-in from all stakeholders on the development team, it also ensures that clients and developers work toward a clear and common goal from the beginning, reducing miscommunication and maximizing efficiency.  

Tips for writing great acceptance criteria 

Acceptance criteria is a vital tool for creating a product that meets a user's needs. It's a common language that helps your team work toward a common goal, a checklist that keeps everyone on track, and a testable system that lets you know when you're finished with a task—all wrapped into one. 

Every product backlog item or user story should have at least one acceptance criteria written before implementation. But who should write them? Each company approaches the writing process differently. Some choose to have the clients spearhead the writing since they have a clear vision of the feature they want and a relationship with the product's users. Other teams assign the task to a business analyst, who uses her knowledge of the client's needs and the developer's skills to develop story standards. Choose the person who makes the most sense for your team. The critical thing to remember is that the writing should be done before the project begins—and everyone involved should understand and agree with the criteria before starting.

Concise, effective acceptance criteria should:

Be specific but not narrow

Acceptance criteria should clearly articulate a goal, but they shouldn't dictate exactly how to achieve it. Acceptance criteria that does this is too narrow and doesn't allow developers the flexibility to problem-solve effectively. Similarly, narrow acceptance criteria might inadvertently exclude certain user behaviors. Aim for criteria specific enough to provide direction but broad enough to include different potential approaches and user actions.  

Be achievable and independently testable

When making personal goals, it's important to ensure they're obtainable and measurable. The same goes for acceptance criteria. Write criteria that can be independently tested objectively—allowing developers to know when they've hit the mark. That way, you will not only create user stories that are achievable. You'll also know when you've achieved them.

Be simple and straightforward

Acceptance criteria shouldn't read like a manual. They should read like a directive: clear, concise, and to the point. Acceptance criteria should always clarify a user story—not confuse it—so avoid complex ideas, technical details, or jargon. State clearly the end result you want to achieve. Focus on what you want to achieve, not how. This will create clear communication while allowing developers the flexibility to problem-solve. And remember, use language that all your stakeholders can agree upon and understand.

Supported by all stakeholders

A user story is only as good as its acceptance criteria—but everyone needs to accept the acceptance criteria for it to be effective. The whole purpose of acceptance criteria is to ensure that everyone is working toward the same goal. So everyone must have a shared understanding of the criteria themselves. Regardless of who initially writes your criteria, ensure agreement from all stakeholders—from the client to the product and development team. This will confirm that everyone agrees on the task at hand—and how to measure it—and will pave the way for a smooth user story process before you even begin.

Acceptance criteria examples

It's one thing to talk about writing acceptance criteria—but it might be hard to get the hang of it. Just as user stories follow a rough formula—a [type of user] wanting a [specific feature] to meet a [specific need]—acceptance criteria follows what's known as the Given/When/Then format. More simply, it can take the form of a list of conditions the user story must meet. When writing acceptance criteria, you should explain the scenario, then follow the following template: Given [how things start], when [specific action happens], then [outcome of taking action].  

To make this easier to understand, we've provided two scenarios that offer examples of effective list-based acceptance criteria below.

Scenario one

In this example, the user—a visitor to a travel website—wants to type an address into a search bar and get a list of nearby hotels.

Acceptance criteria for this scenario might look like this.

• Scenario: A user types her address into the website to find nearby hotels
• Given: Given that I typed in my address to find nearby hotels
• When: When I used the search bar 
• Then: Then I will find a list of nearby hotels

Scenario two

In this example, a user wants to recover the password on an account so they can access the account in case they forget the password.

Acceptance criteria for this scenario might look like this.

• Scenario: A user forgets their password and clicks on a "Forgot password" link to recover it.
• Given: Given that I've requested to recover my password
• When: When I reached the login page 
• Then: Then the system will send me a recovery link to my email
• Given: Given that I received the email 
• Then: Then I can open the link, verify my identity, and get a prompt to reset my password
• When: Then I can securely reset my password.