What Are Acceptance Criteria?

Acceptance Criteria serve as a crucial component of product requirements in the realm of software development and project management. These criteria define the conditions and parameters that a product or feature must meet to be considered successfully implemented and accepted by stakeholders. Essentially, acceptance criteria set the boundaries for what is expected, providing clarity to both the development team and stakeholders about the requirements and desired outcomes.

According to Microsoft Press, acceptance criteria (AC) are “conditions that a software product must satisfy to be accepted by a user, customer, or other stakeholders.” They may be described, in a broader sense, as specifications that a product must meet to satisfy users or stakeholders.

Acceptance criteria typically accompany user stories when documenting the requirements for a feature or product. A user story describes a feature from the perspective of the end-user. For it to be deemed as completed, the set of requirements that must be met is captured in the AC.

Why are Acceptance Criteria Important?

In Agile, these criteria are vital and cross-functional teams depend on them for success. In what ways are they important?

Feature scope definition – A user story is incomplete without it because there will be no way to assess if it is completed to expectation. These criteria set the bounds of a solution to guide development.

Shared vision – By defining the set of requirements that marks a completed user story, AC promotes a common understanding and eliminates confusion. These factors guide stakeholders’ expectations from a feature and developers on what it should include.

User story acceptance testing – Acceptance tests offer a way of confirming the correct implementation of a user story. Without acceptance criteria, it is hard to carry out these tests. The factors are the starting point of user story acceptance testing.

Developer support – Developers also benefit from having acceptance criteria created. Since AC spells out what must be done, they only have to run with those. Developers cannot be held accountable for anything beyond the scope of these criteria.

When to Use Acceptance Criteria?

There are no strict rules on when or how write user story AC’s but they need to be created prior to the beginning of development. Acceptance criteria will not offer much value if they are considered too late in the process. It should also be stated that the criteria shouldn’t be written too early. In Agile, nothing is set in stone and things are subject to change. There may be a need to alter the priorities of user stories a little later in the process. Although anyone on a product development team may write acceptance criteria, the product manager or product owner usually does this. The reason for this is to ensure that customers’ needs truly form their basis.

Writing Good Acceptance Criteria?

For AC to be effective, the following are some of the characteristics they should ideally possess:

Brevity – There is no need for producing voluminous documentation when creating AC. Make the criteria uncomplicated and to the point.

Conditions of Satisfaction: Acceptance criteria should outline the conditions that, when satisfied, indicate successful completion of a user story or feature. These conditions are essentially the “must-haves” that define the minimum acceptable standard for the functionality or feature.

Clear and Specific Language: Acceptance criteria should be expressed in clear and specific language, leaving no room for ambiguity. This is crucial to avoid misunderstandings between the development team and stakeholders. Clear language ensures that everyone has a shared understanding of the expectations.

Testability: Acceptance criteria should be formulated in a way that makes testing straightforward. Each criterion should be testable, allowing for a clear assessment of whether the conditions have been met. Testability ensures that the development team can validate the functionality effectively.

Measurable Criteria: Whenever possible, acceptance criteria should include measurable elements. This can be in the form of specific metrics or quantifiable outcomes. Measurable criteria provide a concrete basis for evaluation and help in objectively determining whether the requirements have been fulfilled.

Realistic and Achievable: It’s essential that acceptance criteria are realistic and achievable within the given constraints, including time and resources. Unrealistic criteria can lead to frustration, delays, and potential project failures. Realism is critical for maintaining a balance between ambition and feasibility.

Inclusion of Edge Cases: Acceptance criteria should encompass a range of scenarios, including potential edge cases. Considering various situations helps in ensuring that the product is robust and can handle different user interactions or system conditions.

Dependencies and Interactions: If the functionality being described has dependencies on other features or systems, or if it interacts with other parts of the application, these dependencies should be explicitly stated in the acceptance criteria. This helps in understanding the broader context and potential impacts.

Performance Criteria: Depending on the nature of the product, it might be necessary to include performance criteria in the acceptance criteria. For instance, if a web application needs to load within a certain timeframe or support a specific number of concurrent users, these performance criteria should be outlined.

Scalability and Future Considerations: Acceptance criteria should also address scalability and future considerations. This involves anticipating potential future requirements or changes and ensuring that the current implementation allows for scalability and adaptability.

Acceptance Criteria Formats

Different formats can be used when creating the AC. However, two structures are more popular. These are scenario and rule-based acceptance criteria.

Scenario-based

This format is also known as the Given/When/Then (GWT) system. It assumes, given a precondition, when you take an action then you expect to get a particular result. This might not be clear enough unless there is an example. Let’s takes the case of a user that forgets their password. The user story can go thus: I want to be able to recover my account password if I forget it.

The acceptance criterion using the GWT format may go as follows:

• Given that a user visits the login page
• When the user clicks on “Forgot password”
• Then a password recovery link is sent after they enter their email address

Rule-based acceptance criteria

The GWT approach isn’t suitable in all situations. In some cases, the rule-based format may be more appropriate. This is also known as the “checklist” or “verification list” format. Rule-oriented AC, as the name suggests, starts with a set of rules. You work with your team to put together a list of statements that captures pass or fail scenarios. The statements spell out the conditions that must be met for a user story to be complete. The rule-based format is pretty clear-cut. Pass or fail statements are usually presented in the form of a bullet list. Scenarios are created from the set of rules defined.

Best Practices

When writing Acceptance Criteria, consider the following best practices to ensure details are covered and necissary parties are aligned:

Collaborative Approach: Foster a collaborative environment where product owners, developers, and other stakeholders work together to formulate acceptance criteria. Collaboration helps in obtaining diverse perspectives and ensures that all aspects are considered.

Use of User Stories: Acceptance criteria are often associated with user stories in agile development. Each user story should have clear acceptance criteria, outlining the specific outcomes expected from the development effort.

Prioritization: Prioritize acceptance criteria based on their importance. Clearly indicate if there are critical criteria that must be addressed before others. This helps in managing expectations and delivering high-priority features first.

Regular Review and Refinement: Acceptance criteria are not set in stone. They should be subject to regular review and refinement, especially as the development team gains a better understanding of the product and user needs evolve.

Avoiding Assumptions: Assumptions can lead to misunderstandings and misalignments between the development team and stakeholders. It’s crucial to avoid making assumptions and instead rely on explicit and well-defined acceptance criteria.

Incorporate Visuals: Whenever applicable, use visuals such as wireframes, diagrams, or flowcharts to supplement acceptance criteria. Visual aids can provide additional clarity and help in conveying complex requirements more effectively.

Consistent Format: Maintain a consistent format for documenting acceptance criteria. Consistency makes it easier for the team to read, understand, and reference the criteria throughout the development process.

Include Negative Scenarios: Don’t only focus on positive scenarios. Include negative scenarios and potential failure conditions in the acceptance criteria to ensure that the product behaves appropriately in less-than-ideal situations.

Validation by Stakeholders: Before development begins, ensure that stakeholders validate the acceptance criteria. This validation helps in confirming that the expectations align with the broader business objectives and user needs.

Update Documentation: As the product evolves, update the acceptance criteria documentation accordingly. Any changes in requirements or additional insights gained during development should be reflected in the acceptance criteria.

Conclusion

Acceptance Criteria play a pivotal role in ensuring successful product development by providing a clear and unambiguous definition of what constitutes a completed and accepted product or feature. Following best practices, such as collaborative formulation, prioritization, and regular review, enhances the effectiveness of acceptance criteria in guiding the development process.