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:
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:
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.
