What are Acceptance Criteria?
Smartpedia: Acceptance Criteria define conditions by which a requirement or a user story is fulfilled and accepted by the stakeholder.
Acceptance Criteria – Definition
Stakeholders formulate expectations of products – as requirements. Ideally, requirements should be unambiguous, complete, understandable, consistent, redundancy-free and correctly formulated. But in the reality of product development, this often looks different. Time and again, there are reports that projects and developments fail because the quality of requirements was insufficient. This is where acceptance criteria help. They define conditions by which a requirement is fulfilled and accepted by the stakeholder. In other words, acceptance criteria substantiate requirements.
Their purpose is to determine as unambiguously and objectively as possible whether a functionality is exactly as the user, customer, client – in short, the stakeholder – imagines it to be. Alternatively, they are therefore also declared as Confirmation of Satisfaction.
Acceptance Criteria in Agile and Classical Contexts
Acceptance criteria are frequently used in product development and especially in software development. In the context of agile approaches it is often pointed out that backlog items in general and user stories in particular must include acceptance criteria.
However, the use of acceptance criteria is also common in classic process models such as V-Modell XT. In this context, V-Modell XT speaks of criteria of acceptance, which define which aspects of the delivery must be fulfilled in order to meet the requirements. Interestingly, acceptance criteria are not mentioned in the Scrum Guide.
Advantages of Acceptance Criteria
Acceptance criteria offer several advantages:
- They bring the user’s expectations into focus.
- They increase the understanding of those involved and create clarity with regard to requirements or user stories.
- They provide clear indications of what needs to be done during implementation.
- They provide the input for acceptance tests.
- They promote communication between the participants.
Examples of Acceptance Criteria
Ideally, acceptance criteria should be formulated simply, clearly and briefly. Here you will find some examples:
User Story:
As a visitor of an online shop I would like to collect different articles in a shopping cart in order to buy them in one process and receive them by delivery service.
Acceptance criteria:
- If the visitor presses the “Add to cart” button in the online shop, the number of items in his shopping cart should increase by the selected product quantity.
- If the visitor in the online shop adds an item to the shopping cart that is already there, the number of items should increase accordingly and not the same item should be created a second time.
- The visitor in the online shop can only place an order if he has filled in all mandatory fields (name, address, e-mail, telephone number, payment method).
- If the order is placed as a guest without login, the visitor must pay for the goods in advance by credit card or PayPal.
The Creation of Acceptance Criteria
In practice, three techniques for the formulation of acceptance criteria have proven to be effective:
- working with lists,
- working with scenarios,
- the free derivation.
Example lists:
A secure password with more than 8 and less than 256 characters including upper and lower case letters, special characters and digits must be used.
| Password | Expected result | Reason |
| A$9a | fail | too short |
| AaBbCc1122 | fail | no special character |
| ??aaa11122 | fail | no upper letter |
| ??AAA11122 | pail | no lower letter |
| AbcDeFgH | fail | no digit |
| ThisIs#A1Password | pass |
As a moviegoer, I would like to be able to save my preferences online in a profile so that I am informed accordingly every week by newsletter.
- Feature/Scenario: Moviegoer saves preferences
- Prerequisite: Profile with mandatory fields e-mail address, preferred film categorys and agreement to the privacy agreement is available.
- When: If new films of the preferred film category are added to the cinema programme,
- Then: a newsletter with the corresponding content is automatically generated
- And: and sent to the cinema audience by e-mail.
This procedure is part of Behavior Driven Development and is called Gherkin syntax (Feature, Given, When, Then, And).
As a film lover, I would like to be informed about new films, so that I know which films are next in the cinema.
- How often would the film lover like to be informed?
- When does the film lover want to be informed?
- How would the film lover like to be informed?
- What kind of films does the film lover want to be informed about?
- …
Free derivation is achieved by questioning key words (verbs, adjectives and nouns), especially by W-questions (who, when, how often etc.).
In addition, a small mnemonic could also help with free derivation: Imagine that the user story is completely implemented and can now be tested. What do you look at to see that it is really finished?
Acceptance Criteria and Definition of Done – what is the difference?
Even though the Scrum Guide does not explicitly mention acceptance criteria, it does know the Definition of Done (DoD). It is a checklist of quality criteria that describes which criteria have to be fulfilled in order to consider the creation of a product as done. This leads to the question: what are the differences between the two tools?
There is one main difference: Acceptance criteria always refer specifically to a backlog item or user story. They provide clarity as to what is to be implemented within the context of the concrete user story and they are the basis for acceptance tests. The DoD refers to the general work with user stories, so the criteria are invariant. Thus, the scope between the two tools is different. Furthermore, acceptance criteria “pay” into the so-called Definition of Ready and their fulfilment can also be a criterion of the DoD.
Some publications mention that acceptance criteria can be legal requirements, standards or rules, but this makes little sense. Acceptance criteria substantiate specific requirements, invariant aspects such as compliance with standards are much better off in a Definition of Done. A DoD is rarely adapted, but acceptance criteria are always redefined per user story.
Tips for Working with Acceptance Criteria
Here you will find a list of tips on how to use acceptance criteria to make working in organisations easier:
- >Acceptance criteria should be formulated before implementation, because this increases the probability of addressing the customer’s expectations and not the developers’ needs. It may also be possible to identify additional requirements that can be discussed with stakeholders or a representative, e.g. the product owner or product manager, before implementation.
- Each requirement, each backlog item, each user story should have at least one acceptance criterion before implementation.
- Acceptance criteria should be independently testable so that acceptance tests clearly fail or pass.
- They should aim at the result – the WHAT – and not at the solution – the HOW. It is not about technical details.
- They may be formulated by team members / developers, but must be verified by the product owner / product manager as the representative of the stakeholders.
- They should not be formulated too specifically so as not to restrict the developers too much. The point is to understand corresponding intentions and not to implement 100 small tests for a single requirement. At the same time, they should be clear and unambiguous enough that corresponding efforts can be estimated.
- They can also be formulated as examples, because examples make it easy for participants to understand what the content is about.
- It is also advisable to gain a common understanding of the criteria with stakeholders.
Download the Acceptance Criteria Guide for free now.
Everything important about acceptance criteria at a glance.
- What are acceptance criteria?
- How are acceptance criteria used in an agile and classical context?
- How are acceptance criteria created and what are the advantages of using them?
- What examples are there and what tips are there for working with acceptance criteria?
Knowledge on 8 pages to take away.
Is there a fundamental reason why examples are rarely used as acceptance criteria?
Notes:
A recommendation for the practical use of acceptance criteria can be found in the article: Boost your backlog.
Here you can find a German-language podcast on the topic: Using acceptance criteria correctly. A conversation by Oliver Winter and Tim Klein.
And here you will find additional information from our Smartpedia section:
What is stated in the Scrum Guide and what not?
Why are stakeholders so important?
Which types of backlogs exist?