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

If you are working in agile software development, or other industry for that matter where users are part of change, you are probably familiar with user stories and acceptance criteria. These are two essential tools for defining and delivering valuable features or functionality to your customers or stakeholders. But what exactly are user stories and acceptance criteria, and how do you write them effectively?

In this article, we will explain the concepts and purposes of user stories and acceptance criteria, provide some examples and best practices for writing them, and show you how to test them using different methods and tools.
By the end of this article, you will have a better understanding of how to use user stories and acceptance criteria to communicate, collaborate and ensure quality in your agile projects.

What are User Stories and Acceptance Criteria?

A user story is a short and simple description of a feature or functionality from the perspective of a user or stakeholder. It captures the essence of what the user wants to achieve or the problem they want to solve with the system. A user story is not a detailed specification or a technical requirement, but rather a high-level goal or a value proposition.

The standard format for writing user stories is: As a , I want to so that . For example:

• As a customer, I want to filter products by category so that I can find what I am looking for more easily.
• As an admin, I want to create and edit user accounts so that I can manage access to the system.
• As a student, I want to enrol in courses online so that I can save time and money.

The user or stakeholder defines how to complete a user story with a set of statements or requirements known as acceptance criteria. These criteria detail necessary conditions and functionality that fulfill the user’s needs and expectations. Furthermore, they pave a clear path for verifying that the user story operates as intended.

The Standard Format for Writing Acceptance Criteria 

Given some precondition when I do some action then I expect the result. For example:

• Given that I am on the product page when I click on the category filter then I see a list of products in that category.
• Given that I am logged in as an admin when I go to the user management page then I see options to create and edit user accounts.
• Given that I have selected a course when I click on the enrol button then I see a confirmation message and receive an email with further instructions.

Why are User Stories and Acceptance Criteria Important?

User stories and acceptance criteria are indispensable elements throughout the project life cycle, with their significance becoming particularly evident during the requirements definition phase. This phase serves as the cornerstone for the project’s success, and user stories and acceptance criteria contribute significantly to this success by:

1. Clarifying Objectives and Scope: During the requirements definition phase, user stories provide a narrative that encapsulates user needs and their goals. Acceptance criteria break down these narratives into specific conditions and functionality, essentially serving as a blueprint for the project. This clarity prevents ambiguity and aligns all stakeholders on the project’s objectives and scope from the very beginning.
2. Mitigating Ambiguity: The precision offered by acceptance criteria leaves no room for misunderstanding. By specifying the exact conditions that must be met for a feature or functionality to be considered complete, they eliminate ambiguity and ensure that the project’s direction remains crystal clear.
3. Preventing Miscommunication: Effective communication is the linchpin of successful project execution. User stories and acceptance criteria create a common language for product owners, developers, and testers. This shared vocabulary minimizes the risk of miscommunication and fosters a deeper understanding of not just what needs to be done but also why it needs to be done in a certain way.
4. Safeguarding Against Scope Creep: Accurate and well-defined acceptance criteria serve as a safeguard against scope creep. They delineate the boundaries of the project, making it easier to identify and resist the inclusion of unnecessary features or changes that deviate from the project’s original goals.
5. Enhancing Collaboration: In the requirements definition phase, user stories and acceptance criteria encourage collaboration among team members. They serve as a focal point for discussions, enabling teams to explore different perspectives, clarify doubts, and work together to refine the project’s requirements. This collaboration not only leads to a better understanding of the tasks at hand but also fosters a sense of ownership and commitment among team members.

As such, during the requirements definition phase which is a integral part of systems engineering, user stories and acceptance criteria act as the lighthouse that guides the project, ensuring that it remains on course by defining objectives, preventing misunderstandings, and promoting effective collaboration. Their influence extends throughout the project, providing a strong and reliable framework for decision-making, development, testing, and successful project delivery.

How to Write User Stories and Acceptance Criteria?

Writing user stories and acceptance criteria is not an exact science, but rather an art that requires practice and refinement. However, there are some best practices and tips that can help you write them more effectively. Here are some of them:

• Use clear and concise language that is easy to understand by anyone involved in the project. Avoid jargon, acronyms or technical terms that might confuse or alienate your audience.
• Focus on the value and outcome for the user, rather than the technical details or implementation. Explain what the user wants to achieve or the problem they want to solve with the system, not how they want it done.
• Involve the users and stakeholders in writing user stories and acceptance criteria. Seek their input, feedback and validation throughout the process. This will help you to capture their needs and expectations more accurately and to build trust and collaboration.
• Use the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable) to evaluate and refine your user stories and acceptance criteria. Make sure that each user story is independent from other user stories, negotiable with the users and stakeholders, valuable to the users and the business, estimable in terms of time and effort, small enough to fit in one iteration or sprint, and testable with clear pass or fail scenarios.
• Use story points or other estimation techniques to assign a relative value to each user story based on its complexity, uncertainty and risk. This will help you to prioritise and plan your user stories more effectively and to track your progress and performance.

The Good and the Bad

Here are some examples of good and bad user stories and acceptance criteria, highlighting the differences and explaining why they are good or bad:

Bad User Story	Good User Story
As a user, I want a login page.	As a user, I want to securely log in to the system so that I can access my personal data and settings.
Why it’s bad: It doesn’t explain the value or the reason for the user story. It doesn’t specify the functionality or the security requirements.	Why it’s good: It explains the value and the reason for the user story. It specifies the functionality and the security requirements.
Bad Acceptance Criteria	Good Acceptance Criteria
The login page should have a username field, a password field and a submit button.	Given that I am on the login page when I enter a valid username and password and click on the submit button then I see a welcome message and my personal data and settings.
Why it’s bad: It describes the design or the implementation of the feature, not the expected behaviour or outcome. It doesn’t account for negative scenarios or error handling.	Why it’s good: It describes the expected behaviour or outcome of the feature, not the design or the implementation. It accounts for negative scenarios or error handling.

How to Test User Stories and Acceptance Criteria?

Testing user stories and acceptance criteria is an essential part of ensuring that the feature is complete and working as intended. Testing can be done manually or automatically, depending on the type and complexity of the feature, the availability of resources and tools, and the preferences of the team.

Some of the methods and tools that can be used to test user stories and acceptance criteria are:

• Unit testing: Testing individual units or components of code to verify that they perform as expected. This can be done using tools such as JUnit, NUnit, TestNG, etc.
• Integration testing: Testing how different units or components of code work together to verify that they function as expected. This can be done using tools such as Selenium, Cypress, Postman, etc.
• Functional testing: Testing how the feature works from the user’s perspective to verify that it meets the acceptance criteria. This can be done using tools such as Cucumber, SpecFlow, Behat, etc.

Test Cases Based on Acceptance Criteria

Here are some examples of test cases or scenarios based on acceptance criteria, showing how to write them using a given-when-then format or other notation:

• User Story: As a customer, I want to filter products by category so that I can find what I am looking for more easily.
• Acceptance Criteria: Given that I am on the product page when I click on the category filter then I see a list of products in that category.
• Test Case: Verify that clicking on the category filter shows a list of products in that category.
• Test Steps:
  1. Navigate to the product page
  2. Select a category from the filter dropdown
  3. Verify that only products in that category are displayed

How to write acceptance criteria effectively

Writing acceptance criteria may seem easy, but it can be tricky for many teams. Here are some best practices to avoid common pitfalls.

Write criteria before development:

To effectively capture all customer needs in advance, it’s essential to draft the acceptance criteria before kick-starting the development process. Initially, concentrate on crafting criteria for several user stories sufficient to occupy the backlogs for two consecutive sprints, especially if you employ Scrum or a comparable method. It’s crucial that both parties reach a consensus on the criteria. Following that, developers can utilize the written acceptance criteria to strategise the technical process.

Don’t make Acceptance Criteria too specific:

Adopting non-specific acceptance criteria (AC) reinvigorates developers’ creative prowess. Keep in mind, the AC should express the purpose more than it dictates the definite solution. Additionally, by making the AC less specific, there’s a higher possibility of capturing user behaviors that may otherwise go unnoticed.

Make your criteria achievable:

This point is related to the previous one. Effective acceptance criteria define a reasonable minimum amount of functionality that you can deliver. But if you try to describe every little detail, you may end up with hundreds of small tasks.

Make Acceptance Criteria measurable and not too vague:

Vague acceptance criteria make a user story unclear. Effective acceptance criteria should outline the scope of work so that developers can plan and estimate their effort properly.

Avoid technical details:

As we said, acceptance criteria should be written in plain English. This will make them clear and easy to understand for everyone: Your stakeholders or managers may not have enough technical background.

Reach consensus:

The same problem may have different solutions for a team and stakeholders, depending on their perspectives. Make sure that you communicate your AC to stakeholders and reach a mutual agreement. The same applies to team members. Everyone should review the AC and confirm they understand and agree with each line.

Write Testable Acceptance Criteria:

This will allow testers to verify that all requirements were met. Otherwise, developers won’t know if the user story is done.

Follow these tips on how to write your Acceptance Criteria 

Write in active voice, first-person. Active voice is when the subject of a sentence does the action (verb). Using active voice is a common recommendation in Agile methodology. In this way, AC reflect the actual words the user would say. Passive voice may make it unclear who wants what. Instead of writing “Filters should be applied in search”, try giving a more informative explanation “The user should be able to apply filters to find specific items”.

Tips for the perfect Acceptance Criteria

Avoid negative sentences. It is always a good idea to avoid using the word “not” as it often makes the requirements unclear and less verifiable. However, you can use “not” when you need to present unique requirements for the system functionality. For example, “The login form should not turn red when the user enters incorrect values.”

Write simple, short sentences. It is better to use several simple sentences instead of one complex one. The fewer unnecessary words and conjunctions like “but,” “and,” “so,” and “as well as” in your acceptance criteria, the more understandable the requirements are for the development teams.

In conclusion, it’s important not to disregard the significance of acceptance criteria. Applied correctly, these seemingly simple tools can simultaneously address a multitude of challenges. They serve the purpose of capturing and documenting customer expectations and offer valuable insights from an end-user viewpoint. Moreover, they provide definitive clarity for requirements, effectively prevent potential ambiguity and aid the quality assurance process in determining whether the development goals have been successfully met.

Sample Acceptance Criteria

To help you better understand the concept of acceptance criteria and how to formulate them effectively, let’s dive into a detailed example. We’ll use a common scenario from the world of agile software development.

User Story: As a customer, I want to filter products by category so that I can find what I am looking for more easily.

Acceptance Criteria:

1. Given that I am on the product page,
2. When I click on the category filter,
3. Then I see a list of products in that category.

Explanation:

1. Given that I am on the product page: This sets the initial condition for the scenario. It specifies that the user must be on the product page before performing any actions related to filtering.
2. When I click on the category filter: This describes the action the user will take. In this case, the action is clicking on the category filter.
3. Then I see a list of products in that category: This defines the expected outcome of the scenario. After clicking on the category filter, the user should observe a list of products that belong to the selected category.

Now, let’s break down each part of the acceptance criteria further:

• Given that I am on the product page: This ensures that the user is in the right place within the application before attempting the filter action. It prevents confusion and verifies that the test is conducted under the correct context.
• When I click on the category filter: This specifies the action that triggers the test. It’s essential to define the precise user action to avoid ambiguity during testing.
• Then I see a list of products in that category: This part sets clear expectations for what the user should observe as a result of their action. It ensures that the filter function is working correctly by displaying the appropriate products based on the selected category.

In summary, the acceptance criteria for this user story provide a step-by-step description of the scenario, including the initial condition, user action, and expected outcome. By following these criteria, both developers and testers can ensure that the feature functions as intended, helping to deliver a valuable and user-friendly product.

By crafting acceptance criteria like these, your agile team can effectively communicate, collaborate, and maintain a shared understanding of user expectations, ultimately leading to successful project outcomes.

Resource Recommendation

If you’re interested in learning more about requirements and user stories in an agile world, I highly recommend the book “A Little Book about Requirements and User Stories: Heuristics for requirements in an agile world” by Allan Kelly. This book provides valuable insights into user stories and their role in agile development.

You can find the book on Amazon.