Acceptance criteria (AC) refers to predefined conditions or requirements that a product must fulfill to gain acceptance from both the customer and the user.
Successful development projects require both the end-users and the developers to have a shared understanding of the desired final product.
One of the critical factors for achieving success and satisfaction, both for the client and the developers, is having a shared understanding of the desired final product. When a customer requests that developers create an application similar to Zoom, there may be varying ideas regarding the design and functionality of this application. To prevent misunderstandings and ensure alignment among the client, developers, and the rest of the team, acceptance criteria have been developed.
Let's delve into the details of what acceptance criteria are, their significance, the different types of acceptance criteria, and how to write them.
Table of contents
- Acceptance criteria, user stories, and the definition of done
- Goals of effective acceptance criteria
- Types of acceptance criteria
- Best practices for writing acceptance criteria
- Acceptance criteria examples
Acceptance criteria, user stories, and the definition of done
To gain a comprehensive understanding of acceptance criteria, it is essential to grasp two other closely related concepts: the definition of done and user stories. These concepts are directly tied to Scrum and Agile methodologies and serve as vital components that assist teams in prioritizing the delivery of value to end-users.
As stated above, acceptance criteria (AC) are predefined conditions or requirements that a product must fulfill to gain acceptance from both the customer and the user.
User stories are concise descriptions of functionality, written from the user's perspective. They typically adhere to this format: "As a user, I want a specific functionality to achieve a particular result." User stories offer a high-level perspective of the end user's desires.
To ensure the effectiveness of user stories, they must be comprehensible and verifiable. This is where acceptance criteria play a crucial role. Acceptance criteria define the conditions that must be fulfilled for a user story to be considered complete and approved by the customer or user.
Acceptance criteria constitute a pivotal element of a user story. They delineate the precise conditions or requirements that must be fulfilled for the user story to attain completion and approval from the product owner or customer. Acceptance criteria play a vital role in fostering clarity and establishing a shared understanding of the expected outcomes for the user story.
By incorporating acceptance criteria, potential issues late in the development process are preemptively addressed, contributing to the satisfaction of all stakeholders.
It's worth noting that while acceptance criteria are sometimes referred to as the "Definition of Done," there exists a nuanced difference between the two.
The Definition of Done (DoD) also comprises a set of requirements that must be met for a user story to be designated as complete by the team. However, it encompasses a more extensive list of prerequisites and guidelines that are applicable to all tasks within a sprint or release. The DoD serves as a guiding framework for the development team, outlining the essential benchmarks that must be attained for any work item to achieve the status of "done," thereby ensuring adherence to the team's quality and completeness standards.
In essence, the distinction between the two lies in their scope. The DoD is a universal standard applicable to all user stories, whereas acceptance criteria are tailored to specific user stories, varying based on the unique requirements of each story.
The following example illustrates the difference between the two concepts. Let's consider ordering a pizza from a restaurant to illustrate the contrast between these two concepts.
Acceptance Criteria: These are the specific requirements or conditions that the pizza must fulfill for you to deem it acceptable. For instance:
- The pizza must be large
- It should have a thin crust
- Toppings should include pepperoni, mushrooms, and green peppers
- It should be baked until the cheese turns golden brown
Acceptance criteria concentrate on the particular features or attributes of the pizza that are crucial for it to meet the customer's expectations and be considered "done."
Definition of done: In contrast, the definition of done outlines the overall quality and completeness standards that apply to every pizza order, irrespective of the individual customer's preferences. Here's a simplified example of the definition of done for a pizza:
- The pizza dough is stretched and rolled correctly
- Ingredients are fresh and of high quality
- The pizza is baked at the correct temperature and for the proper duration
- It's sliced into uniform portions
- It's packed in an insulated box for delivery
The definition of done establishes the overarching guidelines for how the pizza should be prepared and delivered, ensuring uniformity and quality across all orders.
In summary, while acceptance criteria are akin to your personalized pizza order, the definition of done guarantees that every pizza, regardless of the order, adheres to specific quality standards.
Acceptance Criteria and Definition of Done are commonly employed concepts in Agile methodologies. These tools are pivotal in promoting communication, collaboration, and transparency within Agile teams. Their primary purpose is to ensure that work items are precisely defined, fostering a shared understanding of expectations, and consistently facilitating the delivery of high-quality work.
Goals of effective acceptance criteria
Good acceptance criteria serve several essential purposes:
- Defining boundaries: Acceptance criteria establish the scope of a user story, providing precise functional details that enable the team to determine if the story is complete and functioning as intended.
- Handling negative scenarios: Acceptance criteria also encompass negative scenarios, such as when a user enters an incorrect password. They specify how the system should respond in such cases.
- Consensus building: Acceptance criteria foster alignment between development teams and the product owner, creating a shared understanding of requirements. Developers gain clarity on the expected behavior of a feature, and the customer knows what to anticipate.
- Enhancing testing: Acceptance criteria form the foundation of acceptance testing for user stories. Each criterion should be independently testable, defining clear pass and fail scenarios. They are valuable for validating a story using automated tests.
In a collaborative environment, where different perspectives and problem-solving approaches may exist, well-defined acceptance criteria are crucial for establishing a common vision of how functionality should be realized.
Types of acceptance criteria
There are several types of acceptance criteria, with the following two being the most commonly used:
- Scenario-oriented (Given/When/Then Template): This format structures acceptance criteria around specific scenarios, utilizing the Given/When/Then template to outline the situation, action, and expected outcome.
- Rule-oriented (checklist template): Rule-oriented acceptance criteria use a checklist template to define requirements and conditions that must be met for a user story to be considered complete.
Scenario-oriented acceptance criteria
As the name suggests, scenario-oriented acceptance criteria are presented in the form of scenarios that illustrate each criterion. This format follows the Given/When/Then (GWT) sequence, structured as:
- Given some precondition
- When I perform some action
- Then I expect some result
This approach, inherited from Behavior Driven Development (BDD), offers a consistent structure that aids testers in determining when to commence and conclude testing for a specific feature. Additionally, it reduces the time required to write test cases as the system's behavior is predefined.
This acceptance criteria format includes the following statements:
Scenario: This is the name of the behavior being described.
- Given: Describes the initial state of the scenario
- When: Specifies the specific action that the user performs
- Then: Outlines the expected result of the action in the "When" statement
- And: Used to continue any of the previous three statements
Together, these statements comprehensively cover all the user's actions required to accomplish the task and attain the desired result.
Now, let's explore some examples.
E-commerce checkout scenario:
- Given an empty shopping cart,
- When the customer attempts to check out,
- Then the system should display an error message and prevent the checkout process.
Password reset scenario:
- Given a user's request for a password reset,
- When the request is submitted,
- Then the system should promptly send a password reset email to the user's registered email address within five minutes.
Weather app scenario:
- Given a user without an internet connection,
- When the user opens the weather app,
- Then the app should display a message stating, "No internet connection," and it should disable any features that require online data
Using the "Given, When, Then" structure helps clearly define the context, action, and expected outcome for each scenario.
Rule-oriented acceptance criteria
In certain scenarios, acceptance criteria may not easily conform to the Given/When/Then structure. This could be the case when:
- You are dealing with user stories that pertain to system-level functionality, requiring alternative quality assurance methods
- The intended audience of the acceptance criteria does not necessitate exhaustive details of test scenarios
- Given/When/Then scenarios do not adequately capture aspects related to design and user experience, potentially leading to the omission of critical details by developers
In such cases, a rule-oriented acceptance criteria format can be employed as a solution.
A rule-oriented approach involves establishing a set of rules that define the behavior of the system, and specific scenarios can be derived from these rules. Typically, criteria generated in this format are presented as a straightforward bulleted list.
Here is an illustrative example.
Scenario: email spam filter
1. Rule: Emails containing certain keywords, such as "free," "lottery," or "urgent," are considered potential spam.
Acceptance criteria: The system should flag emails with these keywords as potential spam and move them to a separate spam folder.
2. Rule: Emails from known contacts should not be marked as spam.
Acceptance criteria: The system should recognize and prioritize emails from contacts in the user's address book, ensuring they are not incorrectly classified as spam.
3. Rule: The spam folder should automatically delete emails older than 30 days.
Acceptance criteria: The system should regularly check the spam folder and delete emails that are older than 30 days to maintain inbox efficiency.
Best practices for writing acceptance criteria
While it may appear straightforward, crafting effective acceptance criteria is a skill that demands experience and specific capabilities. The quality of your acceptance criteria directly influences the outcome of your work and, consequently, how it will be received by the customer. Therefore, adhering to specific guidelines when composing acceptance criteria is of paramount importance.
Begin early: Always draft acceptance criteria before commencing development. This enables the recording of all customer requirements upfront and ensures mutual agreement before the development process starts.
Take a user-centric approach: Write from the user's perspective. Since the product is intended for the user, their needs determine its quality, convenience, and other attributes.
Seek consensus: Given the diverse ways of problem-solving and varying perspectives, achieving consensus is vital. It's crucial for both the customer and team members to thoroughly review the acceptance criteria and confirm their agreement with each requirement.
Keep it simple: Ensure that acceptance criteria are straightforward and easy to comprehend. Each line should correspond to a specific user action. Instead of lengthy sentences describing multiple options, opt for concise, separate statements. Additionally, acceptance criteria should provide a clear Pass/Fail outcome.
Use clear language: Craft acceptance criteria in plain language that can be understood by both technical and non-technical individuals.
Avoid implementation details: Acceptance criteria should focus solely on describing user interactions with the system, such as site registration. Leave technical implementation specifics, like button colors and other details, to the developers. AC defines the "what" not the "how."
Avoid overly narrow criteria: Refrain from making acceptance criteria overly restrictive, as this can stifle developers' flexibility. Instead, aim to provide a general idea without dictating a final solution.
Steer clear of excessive broadness: On the flip side, overly broad acceptance criteria can result in vague user stories. Strive for clarity by defining the scope of work, enabling developers to plan and assess their efforts effectively.
Ensure achievability: Effective acceptance criteria should specify the minimum level of functionality required, without delving into exhaustive minutiae. Detailed descriptions of every small detail can lead to a multitude of minor tasks.
To ensure visual confirmation that all requirements have been met, write the acceptance criteria to be tested. This practice aids in providing a clear indication of whether the user story has been successfully fulfilled, preventing any ambiguity for developers.
Additionally, adhere to the practice of writing in the active voice, using the first-person perspective. This aligns with common recommendations within Agile methodology. By doing so, acceptance criteria closely mirror the actual words a user would use. Instead of vague statements like "Filters should be applied to search," opt for more informative explanations such as "The user should be able to apply a set of filters to their search."
Who is responsible for writing acceptance criteria?
There are no strict rules when it comes to assigning responsibility for writing acceptance criteria. It can be the customer, product owner, business analyst, project manager, or anyone with the requisite knowledge and experience. Furthermore, acceptance criteria initially created by one specialist can be further enhanced and refined by other team members.
Well-drafted acceptance criteria play a pivotal role in preventing unforeseen issues during the final stages of development. They contribute to ensuring satisfaction among all stakeholders and users with the end results.
Acceptance criteria examples
Now, let's explore some examples of well-crafted acceptance criteria.
E-commerce checkout process
Situation: Users want to complete an online purchase.
Acceptance Criteria:
- When a user adds an item to the cart and proceeds to checkout, they should see a summary of their order.
- Users should be able to apply a discount code if they have one.
- The system should display the total order cost, including taxes and shipping fees.
- Users should be able to enter shipping and billing information securely.
- After completing the purchase, users should receive an order confirmation email.
Weather Forecast App
Situation: Users want to check the weather forecast for their location.
Acceptance Criteria:
- The app should display the current temperature, weather conditions, and a five-day forecast.
- Users should be able to switch between Celsius and Fahrenheit temperature units.
- The system should automatically update the weather data at least once every hour.
- If there is severe weather, the app should display an alert with relevant information.
- Users should have the option to add multiple locations for weather forecasts.
Acceptance criteria plays a crucial in software development
Acceptance criteria are a fundamental component of software development that should not be overlooked. Their simplicity and accessibility make them a versatile tool that serves multiple purposes simultaneously. Acceptance criteria act as a documentation of customer expectations, offering valuable insights into the perspectives of end-users. They play a crucial role in clarifying requirements, thereby preventing ambiguity and misunderstandings within development teams.
Furthermore, acceptance criteria are an invaluable asset to quality assurance processes, enabling thorough verification that development goals have been successfully met. Whether your development approach aligns with Agile methodologies or not, the choice of the most suitable format for acceptance criteria is essential. It's even beneficial to experiment with different formats to find what works best for your specific needs.
Different types of user stories and features may require distinct formats for acceptance criteria, and the flexibility to adapt is a good practice in the ever-evolving field of software development. In essence, acceptance criteria serve as a bridge that connects the vision of the customer with the technical implementation, fostering collaboration, transparency, and ultimately, the successful delivery of high-quality software solutions.
