Acceptance Criteria for User Stories in Agile: Purposes, Formats, Examples, and Best Practices

Suppose you tell your development team to create a feature that enables users to search for books by category for an online bookstore. You can see an interface with users having the option to click on pre-defined categories like fantasy, nonfiction, or history. But two weeks later, the team has produced a search bar where users have to manually input the category. Although workable, this did not meet your initial goal of having all categories prominently displayed for discovery. To avoid such misalignments and ensure that the software is user need-oriented and product-market fit, proper documentation is a must. User stories and acceptance criteria (AC) play their part here. While user stories tell us what the user wants from the system, acceptance criteria specify the conditions under which the story will be deemed complete.

This article will concentrate on acceptance criteria, discussing their purpose, types, best practices, and examples to assist teams in applying them properly.

What are Acceptance Criteria and Their Function in Projects?

Acceptance criteria (AC) describe the requirements a piece of software must satisfy to be accepted by a user, customer, or other system. Every user story has its own AC, specifying the way the feature should act from the end-user’s standpoint.

Clearly defined acceptance criteria avoid misinterpretations and ensure all the stakeholders are on the same page with regard to expectations. The efficient AC must possess the following characteristics:

• Clarity – They should be simple and easy to understand by all team members.
• Conciseness – They should convey critical information without excessive complexity.
• Testability – Every criterion must be testable to check if it has been fulfilled.
• Result-oriented – They need to be concerned with creating value for the customer.

It is worth noting here that acceptance criteria address the desired outcome and not the nitty-gritty of implementation. For instance, rather than saying, “Implement a filtering facility through dropdowns,” a nicely crafted AC would say, “Search results need to be filterable by date, price, and location for users.”

In addition, acceptance criteria should be established prior to development so that deliverables match user expectations.

User Stories vs. Acceptance Criteria

Agile development employs a systematic method in which overall requirements (epics) are divided into detailed user stories and acceptance criteria. Though closely intertwined, these two items play different roles.

User Stories: Give a top-level overview of a feature from the user’s point of view. They emphasize what the user is looking for and why. A standard user story looks like this:

As a [user role], I want to [perform an action] so that [I achieve a benefit].

Example: As a traveler, I would like to select airplane seats online so that I can reserve a window seat.

Acceptance Criteria: Specify the exact conditions that need to be fulfilled for the user story to be complete. They offer a checklist that guarantees the feature performs as anticipated from the end-user.

Whereas user stories define the end result, acceptance criteria detail the quantifiable conditions that confirm the implementation.

Definition of Done vs. Acceptance Criteria

Though often conflated, definition of done (DoD) and acceptance criteria are used for different purposes.

Definition of Done (DoD): A formal checklist that is relevant to all user stories across a project. It usually contains:

• Code integration and completion of peer review
• All unit tests passed
• No open bugs
• Full documentation
• Approval of product owner

Acceptance Criteria: Tailored to every user story, with descriptions of the test scenarios needed to assure the software behaves as intended.

The major difference is that DoD applies for all user stories, while acceptance criteria are specific to each individual one. The former assures quality consistency, while the latter outlines particular functionality requirements.

Main Purposes of Acceptance Criteria

To clarify the function of AC, let’s analyze their main responsibilities:

Defining the Feature Scope

The acceptance criteria set definite boundaries for user stories, specifying what is to be implemented and checking whether the functionality lives up to expectations.

Handling Negative Scenarios

AC ought to consider probable edge cases as well as undesirable scenarios. Suppose a user gives an invalid format password. Then, the system ought to withhold further progress for such a user. Defining behaviors like that precludes occurrence of unexpected things.

Aligning Stakeholder Expectations

Acceptance criteria ensure that developers, stakeholders, and clients share the same vision. Developers know exactly how the feature should behave, and stakeholders understand what to expect from the final product.

Facilitating Acceptance Testing

Because acceptance criteria identify desired outcomes, they form the basis for user story acceptance testing. Every AC must be testable in isolation with well-defined pass/fail criteria so that features are more easily verified through automated or manual tests.

Facilitating Feature Evaluation

AC give a clear development path to development teams, enabling them to decompose user stories into smaller tasks. This makes it possible to estimate efforts accurately and plan development in a structured manner.

Various people might have different views on how a feature should be implemented. Good acceptance criteria help align these views and create a common understanding within the team.

Acceptance Criteria Formats and Examples for User Stories

The acceptance criteria format may differ based on the requirement complexity and nature of the user story. The frequently used formats are:

• Scenario-oriented (Given/When/Then format)
• Rule-oriented (Checklist format)
• Custom formats

Although the first two formats are commonly applied because of their structured nature, teams can adopt customized formats according to their requirements. Let’s discuss these formats in detail.

Scenario-Oriented Acceptance Criteria Format (Gherkin)

The scenario-oriented format organizes acceptance criteria in the style of user scenarios. It adopts the Given/When/Then (GWT) style, which is popularly utilized in Behavior-Driven Development (BDD).

The format consists of:

• Given – The initial state or precondition
• When – The action performed by the user
• Then – The expected outcome
• And – An additional condition or step

This format, written in Gherkin language, provides clear guidelines for testers by defining when testing should begin and end while reducing time spent writing test cases.

Example 1: Password Recovery Feature

User Story: I want to be able to recover my password as a website user so that I can access my account again if I forget it.

Scenario: Forgot Password

• Given: The user is on the login page
• When: The user chooses the “Forgot Password” option
• And: Enters a valid email to get a password recovery link
• Then: The system sends the link to the entered email
• Given: The user receives the link via email
• When: The user clicks on the link
• Then: The system allows the user to set a new password

Example 2: ATM Cash Withdrawal

User Story: I am a bank card holder, and I would like to withdraw money from an ATM so that I can spend my money anytime, anywhere.

Scenario 1: Successful Withdrawal

• Given: The account is in good balance
• And: The card is valid
• And: The ATM contains enough cash
• When: The customer makes a cash withdrawal request
• Then: The account is debited
• And: The ATM dispenses the amount requested
• And: The card is returned

Scenario 2: Insufficient Funds

• Given: The account has not enough balance
• And: The card is valid
• When: The customer asks for a cash withdrawal
• Then: A rejection message is shown
• And: No money is given out

Although the scenario-based format is convenient for feature testing, it might not be appropriate for system-level features or design restrictions. In these instances, a rule-based format would be more suitable.

Rule-Oriented Acceptance Criteria Format (Checklist)

When the Given/When/Then form is not being used, there is a rule-based form. This form has a bullet list that prescribes the actions of a system.

Example: Hotel Search Functionality

User Story: As a traveler, I want to be able to search by city, name, or street so that I can identify suitable hotel possibilities.

Basic Search Interface Acceptance Criteria:

• The search box is positioned on the top navigation bar
• The search is triggered when the user presses the “Search” button
• The search input has a placeholder text: “Where are you going?”
• The placeholder is removed once the user begins to type
• The search should be able to handle queries by city, hotel name, and street (or a combination of the three)
• The search must be accessible in English, French, German, and Ukrainian
• Input field must not be more than 200 characters
• Special characters must not be enabled, and an error message should be displayed: “Search input cannot contain special symbols.”

This format is simple and easy to read, making sure that important system features are properly documented.

Other Formats for Acceptance Criteria

While scenario-based and rule-based formats are the most popular ones, teams can create their own project-specific custom formats for acceptance criteria. A few teams even use plain text to write acceptance criteria in an informal yet structured format.

Whichever format is used, acceptance criteria should be unambiguous, testable, and comply with user expectations.

Ready-to-Use Acceptance Criteria Templates

If you are searching for ready-to-use templates, the following resources are useful tools:

• Klariti – Provides an MS Excel Acceptance Criteria Log template as a part of their Software Testing Template pack.
• Aha! – Offers templates documenting different user stories and acceptance criteria.
• PowerSlides – Contains a PPT template with six dynamic designs for recording user stories and acceptance criteria.
• Stakeholder Map – Provides a completely editable Excel product requirements template containing acceptance criteria.

Having looked at acceptance criteria structures and examples, let’s speak about who authorizes them to be written.

Who Authors Acceptance Criteria?

Within Agile teams, several individuals work together in order to author acceptance criteria:

• Product Owner – Chiefly in charge of establishing acceptance criteria when they develop product requirements.
• Business Analyst/Requirements Analyst – Can help document AC, especially in sophisticated projects.
• Project Manager – PMs sometimes help with AC to provide clarity on deliverables.
• Developers and Testers – Give feedback to improve AC based on technical feasibility.
• Clients and Stakeholders – Where technically savvy, clients can author AC but must be checked against the development team to prevent miscommunication.

Acceptance criteria are to be inspected and honed together to verify team alignment.

When to Write Acceptance Criteria?

Timing for writing acceptance criteria is essential to ensure project success. It often happens at three stages:

Initial Stage:

• Acceptance criteria for the initial sprints are established during project planning.
• Assists in bringing clarity prior to development.

Prior to Each Sprint:

• Acceptance criteria are discussed and improved during backlog grooming sessions.
• Ensures that user stories scheduled for the sprint are clearly defined.

Sprint Planning and Adjustments:

• AC is completed prior to the start of the sprint.
• Changes in the middle of the sprint should be avoided unless absolutely necessary to avoid rework.

After these steps, there is certainty that acceptance criteria are properly developed and agreed upon prior to development.

Best Practices for Writing Acceptance Criteria

It is not easy to write effective acceptance criteria. The following best practices should be adhered to:

• Don’t make the criteria too specific. Leave enough room for developers to come up with solutions.
• Make AC attainable. Set a reasonable minimum scope that can be implemented.
• Make AC measurable. Clearly define conditions that mark completion.
• Steer clear of technicalities. Use simple language to make AC understandable to everyone in the team.
• Come to a consensus. Make sure both stakeholders and developers are in agreement on the criteria.
• Make testable AC. Allow QA teams to test requirements.

General Writing Tips:

Use active voice: Replace “Filters should be applied in search” with “The user should be able to apply filters to search results.”

Avoid negative statements: Replace “The system should not allow invalid email formats” with “The system should validate email format before submission.”

Use concise statements: Use short, simple sentences for improved clarity.

Writing Acceptance Criteria in Jira

There is no native feature for acceptance criteria in Jira, but teams can record AC by:

• Description Field: Include acceptance criteria in the issue description.
• Custom Fields: Define a specific acceptance criteria field.
• Checklist Apps: Employ third-party Jira apps such as Issue Checklist Pro for the tracking of acceptance criteria.

Applying these strategies, teams are able to track and manage acceptance criteria effectively in Jira.

Final Thoughts

Acceptance criteria are vital in software development as they capture user expectations, establish scope, make things clear, and enhance quality assurance. Regardless of whether Agile methodologies are being followed or not, choosing the correct format and modifying it according to project requirements is imperative.

By using well-defined, well-organized acceptance criteria, teams can make development more efficient, eliminate confusion, and provide software that meets user expectations efficiently.