What are the acceptance criteria and their role in projects?

Acceptance criteria (AC) are the conditions that a software product must meet to be accepted by a user, a customer, or other systems. They are unique for each user story and define the feature behavior from the end-user’s perspective.

Acceptance criteria are the criteria used in projects or contracts to establish whether job was done properly. Objectives of project or contract can be stated generally and be not precise enough to tell if task was done. For example, objective can state “to build a house with 3 bedrooms”. But how large those bedrooms should be? What should be height? Is cellar/basement required? Is kitchen required? What technology should be used to build walls? Therefore, we need acceptance criteria which tell precisely when we agree that the contract/project is done.

In case of agile projects, when we know budget and time span, but we don’t know the scope, it is more difficult to define acceptance criteria. Usually criteria are defined as:

• functional criteria – related to specific functions,
• non-functional criteria – related to e.g. layout, look, design,
• performance criteria – related to efficiency.

In Agile, acceptance criteria refer to a set of predefined requirements that must be met to mark a user story complete. Acceptance criteria are also sometimes called the “definition of done” because they determine the scope and requirements that must be executed by developers to consider the user story finished.

As a product manager or product owner, you may be responsible for writing acceptance criteria for the stories in your product backlog. This article will define acceptance criteria, look at a few examples, and explore some best practices for writing it.

In agile methodologies, acceptance criteria refer to a set of predefined requirements that must be met to mark a user story complete. They are a form of agile requirements documentation. As with most things agile, there are varying definitions of acceptance criteria.

• Acceptance Criteria Definition 1: “Conditions that a software product must satisfy to be accepted by a user, customer or other stakeholder.” (via Microsoft Press)
• Acceptance Criteria Definition 2: “Pre-established standards or requirements a product or project must meet.” (via Google)

Acceptance criteria are also sometimes called the “definition of done” because they define the scope and requirements of user stories. They give developers the context needed to execute on a user story.

Acceptance criteria main purposes

Clarifying the stakeholder’s requirements is a high-level goal. To make the purposes of AC clearer, let’s break them down.

Making the feature scope more detailed. AC define the boundaries of user stories. They provide precise details on functionality that help the team understand whether the story is completed and works as expected.

Describing negative scenarios. Your AC may require the system to recognize unsafe password inputs and prevent a user from proceeding further. Invalid password format is an example of a so-called negative scenario when a user does invalid inputs or behaves unexpectedly. AC define these scenarios and explain how the system must react to them.

Setting communication. Acceptance criteria synchronize the visions of the client and the development team. They ensure that everyone has a common understanding of the requirements: Developers know exactly what kind of behavior the feature must demonstrate, while stakeholders and the client understand what’s expected from the feature.

Streamlining acceptance testing. AC are the basis of the user story acceptance testing. Each acceptance criterion must be independently testable and thus have clear pass or fail scenarios. They can also be used to verify the story via automated tests.

Conducting feature evaluations. Acceptance criteria specify what exactly must be developed by the team. Once the team has precise requirements, they can split user stories into tasks that can be correctly estimated.

What are a few traits of effective acceptance criteria?

• Acceptance criteria should be testable. Since these requirements help formulate the definition of done for your engineers, they need to be easy to test. And the results of these tests must leave no room for interpretation. Tests should reveal straightforward yes/no or pass/fail results.
• Criteria should be clear and concise. You aren’t writing comprehensive documentation here. Keep your criteria as simple and straightforward as possible.
• Everyone must understand your acceptance criteria. Your criteria is useless if your developers can’t understand it. If you’re unsure about whether something is clear, take the time to ask and make adjustments until things are clear.
• Acceptance criteria should provide user perspective. Acceptance criteria is a means of looking at the problem at hand from a customer’s standpoint. It should be written in the context of a real user’s experience.

Acceptance criteria types and structures

Based on the initial task and the complexity of requirements, acceptance criteria can be written in different formats, namely:

• scenario-oriented (the Given/When/Then template);
• rule-oriented (the checklist template); and
• custom formats.

Most commonly used, the first and the second formats have very specific structures, so we’ll mainly focus on them. However, you may find that other formats fit your product better so we’ll briefly touch on them as well.