Acceptance Criteria for User Stories with Examples

Similar to the user story, Acceptance Criteria are crucial for successful product development. User stories articulate the “who,” “what,” and “why” of a requirement, helping the team understand the desired outcome from the user’s perspective. However, without clear acceptance criteria, user stories can be open to interpretation, leading to inconsistencies and misunderstandings. This blog explores the importance of acceptance criteria in user stories, provides examples, and outlines best practices for writing them.

What Are Acceptance Criteria?

Acceptance criteria are a set of conditions that a user story must meet to be considered complete. These are specific, measurable conditions that define when a user story is considered complete and meets the user’s needs. They serve as a checklist that the developers use to verify that the story has been implemented correctly. These ensure that the story aligns with the user’s expectations and provides a clear definition of “done.”

Why Are Acceptance Criteria Important?

It act as a bridge between the user story and the development process. It is important because

• Clarity and Alignment: They provide clear and concise guidelines on what needs to be done, ensuring that everyone on the team has a shared understanding of the story.
• Scope Management: By defining what is included and what is not, these help manage the scope of a user story, preventing scope creep.
• Testing and Validation: They offer a basis for writing test cases and help in validating that the functionality works as expected. This helps in delivering a high-quality product that fulfills the user’s needs.
• Measurable Success: Clear acceptance criteria allow for objective evaluation of a user story’s completion. This eliminates subjective interpretations and ensures the delivered functionality meets the intended requirements.
• User Satisfaction: They ensure that the final product meets the user’s needs and expectations, leading to higher satisfaction.

Best Practices for Writing Acceptance Criteria

Use Simple and Clear Language: Acceptance criteria should be easy to understand. Avoid technical jargon and write in plain language that is accessible to all stakeholders, including non-technical ones.

User-Centric: Frame your criteria from the user’s perspective. What should they be able to achieve with the completed functionality?

Be Specific and Measurable: Each criterion should be specific and measurable. Ambiguities should be minimized to avoid misinterpretations. For instance, instead of saying “The page should load quickly,” specify “The page should load within 2 seconds.”

Independent: Each criterion should be testable independently. This allows for incremental development and testing.

Define the Conditions of Satisfaction: Clearly state the conditions that must be met for the user story to be accepted. This can include functional requirements, performance criteria, and constraints.

Verifiable: Ensure each criterion can be demonstrably true or false through testing or validation.

Include Negative Scenarios: Consider edge cases and negative scenarios. Define how the system should behave in unexpected or erroneous situations.

Use the Given/When/Then Format: A popular format for writing acceptance criteria is the Given/When/Then template, borrowed from Behavior Driven Development (BDD). This format helps structure the criteria consistently and clearly:

• Given: The initial context or state of the system.
• When: The action or event that triggers the functionality.
• Then: The expected outcome or result.

Examples of Acceptance Criteria

Example 1: User Login

User Story: As a user, I want to log in to the application so that I can access my account.

Acceptance Criteria:

• Given a registered user, when they enter a valid username and password, then they should be redirected to the dashboard.
• Given a registered user, when they enter an incorrect password, then they should see an error message “Invalid username or password.”
• Given an unregistered user, when they attempt to log in, then they should see an error message “User does not exist.”
• Given a registered user, when entering a valid username and password, then a session should be created.

Example 2: Adding an Item to the Cart

User Story: As a customer, I want to add items to my shopping cart so that I can purchase them later.

Acceptance Criteria:

• Given a customer is viewing a product page, when they click the “Add to Cart” button, then the item should be added to the shopping cart.
• Given a customer has added an item to the cart, when they view their cart, then the item should be displayed with the correct name, price, and quantity.
• Given a customer has added an item to the cart, when they add the same item again, then the quantity of the item should be increased by one.

Example 3: Password Reset

User Story: As a user, I want to reset my password if I forget it so that I can regain access to my account.

Acceptance Criteria:

• Given a user is on the login page, when they click on “Forgot Password,” then they should be redirected to the password reset page.
• Given a user is on the password reset page, when they enter a valid email address, then they should receive a password reset email.
• Given a user has received a password reset email, when they click the reset link, then they should be taken to a page where they can enter a new password.
• Given a user has submitted a new password, when it meets the complexity requirements, then the password should be updated, and the user should be able to log in with the new password.

Example 4: Search for Products by Brand

User Story: As a customer, I want to be able to search for products by brand name so that I can easily find the items I’m interested in.

Acceptance Criteria:

• The search bar should be clearly visible on the product listing page.
• Entering a brand name should populate a list of relevant products.
• The search should be case-insensitive (e.g., searching for “NIKE” should return results for “Nike” and “nike”).
• Partial matches should be included in the search results (e.g., searching for “sho” should return results for “shoes”).
• Clicking on a product in the search results should take the user to the product detail page.

Additional Tips:

• Involve the entire team in crafting. This fosters collaboration and ensures everyone understands the expectations.
• Use tools like user story templates or checklists to streamline the process.
• Regularly review and update acceptance criteria as the project progresses.

Acceptance Criteria vs Definition of Done (DoD)

Feature	Acceptance Criteria	Definition of Done (DoD)
Purpose	To specify conditions that a user story must meet to be accepted. It ensures user story delivers the expected value.	To define a checklist of activities that must be completed for any work item (user story, feature, bug fix) to be considered “done”. It ensures all work meets quality standards for release or further development
Scope	Specific to individual user stories.	Applies to all user stories, features, and tasks within the Scrum team.
Detail Level	Detailed and specific to the functionality of the user story.	Broad and general, encompassing overall quality and completeness criteria.
Examples	Functional requirements, performance criteria, edge cases.	Coding standards met, unit tests passed, integration tests passed, code reviewed, documentation updated.
Frequency of Change	Changes with each user story.	Generally stable but may evolve with team practices and project needs.
Ownership	Product Owner, with input from the development team and stakeholders.	Scrum Team, often defined collectively.
Usage	Used to verify if a specific user story is complete.	Used to determine if any product increment is complete.
Evaluation	Evaluated at the user story level during the sprint.	Evaluated at the completion of each sprint and before product release,
Focus	Ensures the user story delivers the intended value.	Ensures the overall quality and readiness of the product increment.
Location	Typically documented in user stories within the Product Backlog	Typically documented as part of the team’s working agreements or in the team’s definition documents
Examples of Criteria	Given/When/Then format for specific story validation As a customer, I want to search for products by brand name so that I can find what I’m looking for easily. – The search bar is visible on the product listing page. – Entering a brand name populates relevant products.	Includes technical, testing, and documentation standards All user stories must meet these criteria to be considered “Done”: – Unit tests pass for all functionalities. – Code is reviewed and meets quality standards. – The feature is documented for future reference.

Conclusion

Acceptance criteria are essential for ensuring that user stories are well-understood, accurately implemented, and meet the user’s expectations. By following best practices and using structured formats like Given/When/Then, Scrum teams can enhance clarity, improve collaboration, and deliver high-value products. Remember, well-defined acceptance criteria are the cornerstone of a successful user story and ultimately lead to a successful product.

Frequently Asked Questions (FAQs)

What are acceptance criteria in the context of user stories?

Acceptance criteria are specific conditions that a user story must meet to be considered complete and acceptable to the stakeholders. They define the boundaries and requirements of the user story, ensuring that the functionality works as expected and delivers value.

Why are acceptance criteria important?

Acceptance criteria are crucial because they:

• Provide clear, testable requirements that help developers understand what needs to be built.
• Ensure that the product meets the expectations of the users and stakeholders.
• Facilitate communication and alignment among the Product Owner, developers, and stakeholders.
• Serve as the basis for creating test cases.

Who is responsible for writing acceptance criteria?

Typically, the Product Owner is responsible for writing acceptance criteria, often with input from the developers, stakeholders, and sometimes even users. Collaboration ensures that criteria are comprehensive and aligned with user needs and technical feasibility. The product owner typically takes the lead, but developers and other stakeholders can provide valuable input to ensure the criteria are clear, measurable, and achievable.

What format is commonly used for acceptance criteria?

A popular format for acceptance criteria is the Given/When/Then format, which originates from Behavior-Driven Development (BDD). This format helps create clear and structured criteria:

• Given some initial context,
• When an action is performed,
• Then a specific set of outcomes should occur.

How detailed should acceptance criteria be?

Acceptance criteria should be detailed enough to be unambiguous but not so detailed that they stifle development flexibility. They should focus on the “what” (desired outcome) rather than the “how” (implementation details).

Can acceptance criteria change during the sprint?

Ideally, acceptance criteria should be well-defined before the sprint begins. However, they may be refined during the sprint if new information or insights emerge. Any changes should be agreed upon by the Product Owner and the development team.

How many acceptance criteria should a user story have?

There is no strict rule for the number of acceptance criteria a user story should have. However, they should be concise and comprehensive enough to cover all aspects of the user story. Too many criteria might indicate that the user story is too large and could be broken down further.

How do acceptance criteria relate to testing?

Acceptance criteria serve as the basis for creating test cases. They define what needs to be tested and provide clear, testable conditions. Passing these tests indicates that the user story meets the defined requirements and is ready for acceptance.

Can acceptance criteria include non-functional requirements?

Yes, acceptance criteria can and should include non-functional requirements when relevant. These might cover performance, security, usability, and other quality attributes that are critical to the functionality of the user story.

What happens if a user story does not meet the acceptance criteria by the end of the sprint?

If a user story does not meet the acceptance criteria by the end of the sprint, it is not considered done. The incomplete story may be moved back to the Product Backlog or carried over to the next sprint, depending on the team’s process and prioritization.