Getty Images
Acceptance criteria: What it is and its best practices
Acceptance criteria plays a key role in shaping an application from the user standpoint. We review some of the basic things to remember when it comes to acceptance criteria.
In Agile software development scenarios, acceptance criteria play an essential role in aggregating customer requirements and creating benchmarks for application performance. Specifically, they communicate functionality between the software development team roles within product, development and QA. These descriptions assist team members in understanding users' requests.
Acceptance criteria help developers make sense of individual user stories, while also providing the details necessary to code and test a particular application.
Teams must determine how to calibrate acceptance criteria to meet specific business needs and goals. Dive further into the purpose of acceptance criteria in Agile development and learn how an organization can use different criteria styles to shore up requirements gathering efforts.
What are acceptance criteria?
Acceptance criteria are a set of conditions that a product or feature must meet to be considered complete. These conditions help ensure a product or features provides positive customer experiences, aligning development teams with user expectations and needs.
For development teams, acceptance criteria clarify what functionality users are looking for and how the application should behave. Acceptance criteria should contain a customer-centric focus that enables development teams to ensure expected functionality throughout the coding process. Ideally, the product team should define the acceptance criteria within the user story before the development team gets involved.
From a testing standpoint, acceptance criteria provide specific objectives for application QA teams and user acceptance testers (UATs). The criteria should describe customers' requirements and demands when it comes to application features and functionality. Ideally, product managers or teams would create acceptance criteria alongside user stories and form those criteria descriptions into testable benchmarks.
There are two distinctive approaches to writing acceptance criteria: scenario-based and rule-based. Each one takes a slightly different focus and has its own set of appropriate use cases. Both can play a key role in defining user requirements and design goals.
Acceptance criteria vs. user stories
Acceptance criteria and user stories are both similar Agile development concepts. While acceptance criteria are designed to describe the specific, testable conditions that define when a feature or product is complete, a user story is a high-level description of a product or feature from the user’s perspective.
Both ideas relate to the user perspective, but the user story focuses more on the what and why behind a product from the user perspective, while acceptance criteria focuses on how to get the product or feature to behave in a way that meets user needs.
What to include in acceptance criteria
It's important that all the statements within acceptance criteria are succinct and to the point. They should describe exactly what a specific application function does and what users expect from it. Acceptance criteria should also account for the functional and non-functional needs of both developers and testers, such as:
- Timing. Development teams need the acceptance criteria to clearly state when certain dependencies or integration points come into play, such as API-enabled database updates. This helps communicate the intended scope of application features and guides the process of updating functionality down the line.
- Clarity. For QA professionals and UATs, acceptance criteria need to provide clearly defined and readily testable workflow expectations. For example, if information saved by the user gets passed to the database using an API, testers need to know when and how that transaction occurs. This way, they can know exactly what to look for when things go wrong.
- Scope. Acceptance criteria should accurately describe what an item or feature should do. They should also state what a product or feature should not do, in accordance with the user story and experience. This can help reduce confusion by focusing on customer needs.
- Consistency. Criteria should be written clearly, so each requirement is interpreted the same way. Clearly written expectations will help a team understand the scope of the work that needs to be done, minimizing the chance of any misunderstandings.
- Continuous improvement. Acceptance criteria should be reviewed after each delivery, to continually improve and refine quality.
How to choose an acceptance criteria approach
The approach to acceptance criteria typically depends on the overall preference of team members. Team members should agree on which acceptance criteria format will be the most effective. Two common approaches include scenario-based and rule-based acceptance criteria.
Scenario-based acceptance criteria are useful when describing a workflow that includes multiple entry or exit points or when a new feature is added into an already complex functional sequence. On the other hand, rule-based acceptance criteria documentation leaves little room for interpretation and is often more effective at limiting scope creep. Teams must be mindful to include all the rules, and every rule needs a clear description of the expected result.
The format of the acceptance criteria isn't what matters most. What matters is that the product team communicates customer requirements so that the development and testing teams understand.
Scenario-based acceptance criteria
The scenario-based approach aims to describe how a function or general application task operates within the context of a user scenario. Using a scenario-based acceptance criteria format reinforces a focus on patterns regarding the user's expected workflow and navigation of the application.
This process might follow an approach called the Given-When-Then syntax, also called the Gherkin acceptance criteria:
- Given the start of a scenario,
- When a specific action is made,
- Then the expected outcome occurs.
In some instances, an additional “And” step is added at the end to indicate the continuation of any previous statements.
For example, imagine a healthcare tracking application that enables patients to create daily medication logs. In a scenario-based acceptance criteria format, the scope of each field that the user interacts with, as well as actions they'll need to perform, define the specific workflow steps and expected application behavior:
Scenario-based format
Users log in to the application daily via a dedicated login screen. After the app successfully authenticates the user's identity, they are brought to a screen that displays where they are in their dosage schedule for a specific medication. The interface uses a MM/DD/YYYY format that overlays a monthly calendar background. For each day's login, the interface shows three data entry fields:
- Dose taken.
- Dosing method.
- Patient signature.
Once the patient enters both the dose taken and dosing method -- pill, injection or patch -- fields, they are required to provide a signature to confirm that the information is accurate. The user is required to complete all fields before the application saves and records the data. Once saved, the screen refreshes and displays the patient's progress to date with the updated information included.
In the Given-When-Then format, this process might be:
- Given a patient logs into a healthcare tracking application.
- When the patient submits a daily medication log with all required fields entered.
- Then the system saves the data and displays the patient's up-to-date progress.
Rule-based acceptance criteria
Similarly, rule-based acceptance criteria define the scope and functionality of a user story, but does so against a list of functional and behavioral parameters. This rule-based format for acceptance criteria bears a close resemblance to the requirements documentation typically found in traditional Waterfall development scenarios, where each expected function is listed individually.
Using the same patient logging application example above, this is how rule-based acceptance criteria style would look:
Rule-based format
Once the user is authenticated, they are brought to a daily logging interface screen. This daily screen includes three data entry fields -- dose taken, dosing method and patient signature -- displayed against a monthly calendar backdrop. These data fields are actionable.
In the 'dose taken' field, users must select an amount from a drop-down list of valid dosages for their medication.
In the 'dosing method' field, users must select from a dropdown list of valid methods: mouth, injection or adhesive.
The 'patient signature' field must be manually signed by the user with the cursor acting as a virtual pen. This signature is required to enable the Save & Continue button at the bottom of the form.
Once a user clicks the Save & Continue button, the application records the data and returns the user to a screen showing their updated progress.
Who should write acceptance criteria?
Writing acceptance criteria is often a collaborative process, with anyone on cross-functional teams able to add input. Commonly, however, the product owner or manager is the role that writes the acceptance criteria -- or at least the role that takes ownership of it.
Development teams also commonly have input on acceptance criteria, as they have the technical knowledge to contribute realistic and testable criteria. QA teams, likewise, also shape acceptance criteria by ensuring the criteria are verifiable and testable -- while also being able to identify additional criteria.
Other individuals that can write, add to or facilitate conversations around acceptance criteria include Scrum masters, requirements analysts and business analysts.
When should you write acceptance criteria?
Although its best to write them before development begins, acceptance criteria can be written in the different stages of a sprint. For example, they can be written during:
- Initial planning. At the start of a project, the team defines what the acceptance criteria are for the first few sprints. Creating acceptance criteria at the start will create a clear direction from the beginning.
- Before each sprint. Acceptance criteria are created during the planning stages of each sprint. This ensures an agreed upon scope of work before each sprint begins.
- Sprint backlogs. Acceptance criteria can be created or adjusted during sprint backlogs, giving teams a chance to further clarify requirements and reduce any uncertainties.
- Mid-sprint. Acceptance criteria can be adjusted or changed mid-sprint as long as they do not interfere with ongoing work. This is less ideal but can be useful for adapting to sudden changes.
Common challenges of writing acceptance criteria
While acceptance criteria can help organizations by clarifying what conditions a product or feature must meet to be considered complete, they still come with a number of challenges. Some, for example, include:
- Ambiguity. The use of unclear language and miscommunications between teams can lead to different interpretations, leading to less effective acceptance criteria.
- Disagreements among stakeholders. Team members might find it difficult to find a balance between criteria that are not too specific or too vague.
- Overcomplications. Some teams might be too specific when coming up with criteria, making the process overly cumbersome.
- Scope increases. Adding to a project in development might change the acceptance criteria needed, making it more difficult to change the criteria in process.
- Inconsistencies. Switching between rule-based and scenario-based criteria can make the defining of criteria more complicated.
- Collaboration. Not involving relevant teams, such as development, QA, product managers or analysts, could result in knowledge gaps.
Switching between rule-based and scenario-based criteria will make the criteria harder to follow. Learn more about how each works and how to choose between the two.
