What is Acceptance Criteria?
The success of any product is determined by its ability to fit user needs. The other side of this truism is that the most common reason for failure is the user’s disappointment.
Users usually like to speak up about their expectations from a product or a feature. Yet, to incorporate users’ expectations into development is a different story. To manage the development process, businesses need to describe users' expectations in a format understandable for the development team so that they can create what the client wants as accurately as possible. This description is generally known as Acceptance Criteria.
Acceptance criteria is a formalized set of properties and qualities by which the user evaluates the product and assesses how it matches their expectations. They define how a particular feature can be used from the user’s perspective.
At the same time, predefined Acceptance criteria serve as a guideline for the product team:
- to define the development team’s goals for the product
- to develop test requirements for the QA team.
Acceptance Criteria Format
Acceptance criteria is a list of criteria that directly represent customers’ expectations. To be effective, they need to meet specific requirements as to their format:
- Only a binary assessment can be applied.
- They are clearly defined. All concepts that can be interpreted in different ways should be further clarified.
Acceptance Criteria Types
There are several acceptance criteria types:
- scenario-oriented (the Given/When/Then template);
- rule-oriented (the Checklist template); and
- custom formats.
The first two types are more common and more rigid in their structure.
Scenario-oriented acceptance criteria
This acceptance criteria type comes in the form of a scenario and touches upon each criterion. It is approached through the Given/When/Then (GWT) sequence, as follows:
Example:
Scenario: Login into the app
- Given: I have an in-app account.
- And: I see a login form that I need to use to login into my account
- When: I paste my login and password
- Then: I might access the app
- And: I should be able to get to the app home screen
This approach covers all actions that are required from the user to complete a certain task. It not only defines happy path scenarios but also helps in scenarios when something does not work as intended. In this way, this acceptance criteria type also helps QA engineers conduct behavioral testing by defining when to begin and end the tests.
Rule-oriented acceptance criteria format
Sometimes, system-level functionality might need other methods of quality assurance, rather than relying on a specific scenario. In this case, it is possible to develop a set of rules that describe the behavior of a system.
It is one of the easiest ways to work with acceptance criteria that looks like a checklist. The team defines a set of criteria and values to make an unambiguous assessment of pass/fail.
Other formats
Every team can always invent their own acceptance criteria given they serve their purposes, are clear, and can’t be misinterpreted. In the end, the format of the acceptance criteria is less important as long as the team delivers features that are attractive for the customers.
Yet, it is essential that the development team defines Acceptance Criteria before they move to product development. In this way, a business can avoid the user's disappointment after the product is released.
