What is the difference between a user story and an acceptance criterion?

The acceptance criteria are not the same as the user story, but rather complement it. The user story is a brief description of the customer's needs, including their goals and the problems they want to solve.

And the adoption criteria define what needs to be done to achieve these goals.

In this way, the user story describes the "why" of the work, while the acceptance criteria describe the "what". The "how" is decided by the developers during the sprints.

Why is the acceptance criterion important and what is its purpose?

Let's now look at the specific objectives of the acceptance criterion in the project work.

Details the scope of the function

The acceptance criterion details the functionality that will help the team understand whether the user story is complete and working as expected.

Description of negative scenarios

Acceptance criteria may, for example, require the system to detect insecure passwords and prevent the user from proceeding. The invalid password format is also a common example of the so-called negative scenario.

It therefore defines certain negative scenarios and how the system should respond to them.

Fine-tuning communication

The adoption criteria synchronise the vision of stakeholders and the development team. They ensure that the requirements are understood in the same way by everyone. So there is consistency in what customers or users and other stakeholders expect, and developers know how certain features should work in relation to these expectations.

Simplifying the acceptance test

The acceptance criteria are the basis for the user story acceptance test. Each criterion must be independently testable and have clear success or failure scenarios. They can also be used to verify the story through automated tests.

Carrying out functional assessments

The acceptance criteria define exactly what the team needs to develop. Once the requirements are clearly laid down, user stories can be broken down into correctly estimable tasks.

As different people may have different views and ideas about how to solve a problem, it is necessary to develop a common view on what the function should know.

Who formulates the acceptance criteria?

Acceptance criteria are the answer to what a customer expects from a finished product, as the aim of any development is to satisfy those who use it.

Projects are often run in specific industries, so the criteria may not necessarily come from a traditional customer, but may be driven by the product owner or stakeholder, or by the expectations of a different type of customer or user.

How do we create the acceptance criteria?

These can be defined as follows:

• Following consultations with clients or customers
• Based on discussions with stakeholders
• During Scrum refinement
• Scrum sprint planning
• Product backlog during management activities
• Team brainstorming during
• After assessing feedback from customers or end users

In scrum teams, the product owner is usually responsible for writing these acceptance criteria, but the development team can and should be involved to provide expertise and feedback to help meet the expectations of the PO.

The scrum master can support the process by examining any concerns about the criteria, helping the team understand the purpose of the criteria, and encouraging developers to flag them if they are unclear.

In this way, teamwork can really be established, even if the product owner's proximity to the customer is often the starting point for the development of criteria.

When should the acceptance criteria be ready?

In scrum, product backlog elements are constantly discussed as part of the planning and refinement process. The initial criteria are often defined during the refinement of the backlog, but finalisation should be done just before development starts. 

This ensures that work can proceed on the basis of the most up-to-date information. The criteria should be finalised at the sprint planning stage. The scrum team reviews the criteria, discusses any problems or issues that need clarification, and decides whether the work can be included in the sprint.