Acceptance Criteria for Agile User Stories

How can we ensure that a user story is completed correctly and meets customer requirements? This is where acceptance criteria come into play. Acceptance criteria are a formal list of requirements that ensure all user stories are completed and all scenarios are considered. In short, acceptance criteria define the conditions under which a user story is considered complete. Clear, written criteria help development teams avoid ambiguity about customer needs and prevent misunderstandings.

Therefore, when writing user stories, acceptance criteria are essential. They help your team understand what is mandatory during feature development and what they should focus on.

Let’s dive into acceptance criteria.

What Are Acceptance Criteria?

Acceptance criteria allow you to define when a user story is complete and when it has all the features needed to satisfy user needs.

They are a set of conditions a user story must meet to be considered complete. They provide detailed scope of the user story and what is required, so your team understands the problem at hand. This way, every time you release a new feature, you can ensure it meets the standard the user deserves.

But before you enthusiastically list a set of functional criteria your user story should meet, consider how other variables may affect your feature’s quality and include them in your acceptance criteria.

Acceptance Criteria Can Include Details Like

  • User experience
  • Impact of the current user story on existing features
  • Key performance such as speed
  • What the user story is intended to do

Thus, depending on the functionality you’re building and its complexity, sit down with your team to determine the minimal subset of functionality it should perform and how it should behave.

If it’s complex or a core feature of your product, you should consider writing as many and detailed acceptance criteria as possible to help your team avoid any confusion.

How to Write Acceptance Criteria for User Stories

1. Acceptance Criteria Should Be Written from a User’s Perspective

Acceptance criteria are a way of viewing the problem from the customer’s point of view. They should be written within the context of a real user experience. After all, you’re building a product for users, aren’t you?

2. Criteria Should Be Clear and Concise

Acceptance criteria should not be confused with test cases or documentation. It’s important to keep your criteria as simple and clear as possible.

3. Everyone Must Understand Your Acceptance Criteria

If your developers can’t understand them, your criteria are useless. If you’re unsure about clarity, take time to ask questions and adjust until everything becomes clear.

4. Acceptance Criteria Is Not About How (How?). It’s About What (Why?)

Like user stories, acceptance criteria are not tasks. They are a way of communicating the user story.

5. Acceptance Criteria Are Specific, But Are Not Another Level of Detail

Consider a tax filing software. The most important requirement is to correctly calculate the tax due based on income and expenses. Clear, right? And you know you can’t test every possible combination—because the possibilities are nearly infinite.

Therefore, your acceptance criteria for the user story will specify specific conditions or requirements that must be met. This means being more specific, not adding another layer of detail. This helps your team understand what’s required and speeds up delivery. Of course, when you compare your current burn-down chart with previous ones, you might see some improvements.

6. Acceptance Criteria Can Be a Restatement of the User Story from a User’s Standpoint

This only applies when the user story is not overly complex. Here’s an example of what I mean.

For a user story like “As a finance officer, I want to accept invoices so I can keep track of all financial reports”

Its acceptance criteria might be “When I perform the accept action, the invoice is accepted (verified by checking the invoice record)”

Given/When/Then Acceptance Criteria Template

To make life easier, here’s a simple template you can use to write acceptance criteria:

Given [context] when [a specific action is performed] then [a set of consequences should occur]

Acceptance Criteria Examples

For the example user story:

“As a writer, I want to receive notifications when others add comments so I can stay up to date.”

Here are three examples of acceptance criteria for the above user story:

  1. Given my phone is locked when the app is not open, then I should receive a banner notification.
  2. Given I am writing a document when the app is open, then the bell icon should update to show unread notifications with a count.

Example – Website Feedback Submission

We specify the user story and acceptance criteria for the blog comment feature. Logged-in users can add comments. The user story for the “Add Comment” feature would be:

As a logged-in user,
I want to be able to leave a comment on a blog post,
so that I can receive feedback on the topic.

The acceptance criteria for this feature are:

Scenario: A logged-in user leaves a comment on a blog post
Given I am a logged-in user,
When I open the page containing a specific blog post,
Then the system displays a “Comments” section below the blog post showing a list of comments added by other users.
The system displays an “Add Comment” field at the top of the “Comments” section.
When I fill in the “Add Comment” field with my comment and click the “Submit” button,
Then the system saves my comment.
The system displays my comment at the top of the “Comments” section.
The system displays my username and avatar to the left of my comment.
The system displays “Delete” and “Edit” icons on the opposite side of my comment.

 

As you can see, writing acceptance criteria is truly a win-win for both customers and development teams: it not only helps the team clearly understand what they must do, but also allows customers to understand the development process and verify that the delivered software meets real business needs.