Getty Images
The fundamentals of writing effective acceptance criteria
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 statements help developers make sense of individual user stories, as well as provide the details necessary to code and test a particular application. However, teams also need to determine how to calibrate acceptance criteria to meet their specific business's needs and goals.
Let's dive further into the purpose of writing acceptance criteria in Agile development, and examine two different styles of acceptance criteria -- scenario-based and rule-based -- that development teams can use to shore up requirements gathering efforts.
What are acceptance criteria?
From a testing standpoint, acceptance criteria provide specific testing 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.
On the development side, acceptance criteria help development teams understand 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 that acceptance criteria within the user story before the development team gets involved.
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. However, both can play a key role in defining user requirements and design goals.
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.
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:
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.
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:
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.
Choosing an acceptance criteria approach
The format choice for acceptance criteria typically depends on the overall preference of team members. However, it's worthwhile to facilitate a conversation where team members agree on which format will be the most effective. The format of the acceptance criteria isn't what's important. Instead, what's important is that the product team communicates customer requirements in a way that the development and testing teams understand.
For instance, 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.
What to include in acceptance criteria
When writing acceptance criteria, it's important that all the statements are succinct and to the point, describing exactly what a specific application function does and what users expect from it. However, it should also account for the unique needs of both developers and testers.
For instance, development teams need the acceptance criteria to clearly state when certain dependencies or integration points come into play, such as any API-enabled database updates. This helps communicate the intended scope of application features and guides the process of updating functionality down the line.
For QA professionals and UATs, meanwhile, 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.
