Acceptance criteria standards

Acceptance criteria are defined as the conditions that must be satisfied for a product, user story, or increment of work to be accepted. While not a part of the Scrum Guide, AC can be a useful tool teams may choose to use to improve the quality of product backlog items.

Also shortened to the acronym AC, these conditions are pass/fail. Acceptance criteria are either met or not met; they're never only partially fulfilled.

Acceptance criteria do not focus on "how" a solution is reached or "how" something is made. Instead, they illuminate the "what" of the work you are doing. For example, the criteria may be:

• Users can pay with Google Pay or Apple Pay at checkout.
• Users receive a confirmation email after completing their purchase.
• System should be able to process sales orders with valid payment information.

Approaches to Writing Acceptance Criteria¶

In writing acceptance criteria, there are several approaches teams can take to ensure clarity and effectiveness. With clear and effective acceptance criteria, these can be used in aid of test automation targeted from QA, UAT, and/or even the Production environments to reduce or eliminate a need for dedicated sessions, which can be time-consuming, resource-intensive, and risky at the same time.

Below are some of the well-known formats for writing acceptance criteria:

Checklist Format¶

The checklist format provides a simple and straightforward way to define acceptance criteria as a list of items that need to be verified. It allows the team to easily track progress and ensure all necessary conditions are met before considering a user story complete.

For example, in an invoicing system, the acceptance criteria for a feature that allows payment through Google Pay and Apple Pay may have the following items as acceptance criteria:

• Users can pay with Google Pay or Apple Pay at checkout.
• Users receive a confirmation email after completing their purchase.
• System should be able to process sales orders with valid payment information.

However, it may lack context and detail, making it harder to understand the overall flow of the user story.

Scenario-based format¶

In a scenario-based format, acceptance criteria are defined using a Given-When-Then structure, which helps to clarify the context and flow of the user story.

Scenario: Successful payment

Given the user has items in their cart
When the user proceeds to checkout
Then the user should see the option to pay with Google Pay or Apple Pay

The problem with this format is that it may not capture all the necessary details for testing, leading to potential gaps in coverage.

Scenario-based + Checklist Format¶

Combining the scenario-based format and the checklist format provides a comprehensive approach to defining acceptance criteria, without sacrificing the clarity and detail needed for effective testing. Below is an example of a scenario, including a couple of items that needs to be verified.

Scenario: Successful payment

• Given the user has items in their cart
• When the user proceeds to checkout
• Then the user should see the option to pay with Google Pay or Apple Pay

Checklist:

• Google Pay option is displayed with correct branding and logo
• Apple Pay option is displayed with correct branding and logo
• When Google Pay is selected, the appropriate Google payment dialog appears
• When Apple Pay is selected, the appropriate Apple payment dialog appears
• After successful payment, user is redirected to order confirmation page within 3 seconds
• Order confirmation page displays order number, items purchased, and total amount
• Confirmation email is sent to user's email address within 5 minutes
• Order is correctly recorded in the database with payment method information
• Inventory quantities are updated to reflect the purchased items

This format provides both the high-level context through the scenario and detailed verification points through the checklist, making it comprehensive and easy to test against. However, the use of this format on a simple user story with minimal requirements may introduce unnecessary complexity.

When is Acceptance Criteria Created?¶

Acceptance criteria are typically created during the grooming or refinement phase of the product backlog as these meetings focus on how clear the requirements are to generate a good acceptance criteria. It can also happen during sprint planning, when the specific question revolves around the complexities of implementation.

In doing so, we can identify potential issues that may arise during development and address them early on, saving time and resources.

Criteria for a Good Acceptance Criteria¶

Clarity and Conciseness¶

• Use simple and straightforward language.
• Avoid jargon and technical terms that may not be understood by all stakeholders.
• Keep acceptance criteria brief and to the point, ideally one sentence per criterion.
• Use bullet points or numbered lists for easy readability.
• Ensure each criterion is specific and unambiguous.

Testability & Measurability¶

• Define acceptance criteria in a way that allows for easy testing.
• Use clear and measurable outcomes to determine if criteria are met.
• Include specific examples or scenarios to illustrate acceptance criteria.
• Ensure that acceptance criteria can be validated through automated tests where possible.
• Avoid vague terms like "user-friendly" or "fast" that are difficult to measure.
• Include specific metrics or criteria for success. This will be helpful if the feature in question is concerned about performance.

Based on Outcomes¶

• Focus on the desired outcomes and results of the work.
• Ensure that acceptance criteria align with user needs and business goals.
• Use "user stories" or "use cases" to frame acceptance criteria in terms of user value.

Independence¶

• Ensure that acceptance criteria are independent and do not rely on other criteria.
• Each criterion should be able to stand alone and be tested individually.
• Avoid cross-referencing other criteria to maintain clarity and simplicity.

Examples¶

Good Acceptance Criteria¶

Bad Acceptance Criteria¶