Acceptance Criteria and User Stories are some of the terms we hear day-to-day in an Agile Software Engineering environment. Working with multiple client teams over the years at Quantum Mob, we've noticed that not everyone uses them, and those that do typically misuse them. They can be directly responsible for making a software engineer's life a confusing nightmare without having a clear indication on what is expected for deliverables.

What do these terms mean and how can we use them to ensure software projects get delivered to everyone's expectations? In this article, we will deep dive into the Acceptance Criteria and User Stories in software development with examples and demonstrate how they can be used to create accountability and ensure a project's delivery.

Definitions

User Stories

User Stories are generalized details of the system's user requirements and what the client hopes to gain from this functionality. In Scrum we have User Acceptance Criteria to simplify the understanding of the client’s intent or translate the intent to an actionable item.

Acceptance Criteria

Acceptance Criteria are a formal list that fully enumerates user requirements and all the product scenarios put into the account. It states the intent of the client and not the solution; it is up to the team to understand them and ask for clarification where it’s complex and find the solution.

Acceptance Criteria in Software Development

A software development project is typically divided into a set of tasks, and after each task is completed, it is confirmed whether they meet the requirement of the project development scope. This is made possible by the use of the Acceptance Criteria.

Before the actual coding of any project can begin, planning and estimation of resources and timeline information are required. The use of Acceptance Criteria allows for the easy division of tasks, which can then be easily budgeted and assigned.

Feature development with User Stories and Acceptance Criteria
Flowchart of Acceptance Criteria

How to write Acceptance Criteria

Acceptance Criteria should describe achievable and sensible information. It should provide the minimum level of functionality the product is to achieve, allowing space for some flexibility. Also, it should not be overestimated or underrated, but set at a realistic level.

Great criteria are well detailed and defined so that the team members can easily comprehend what is required of them and easily employ the information in development. Just as the project is divided into tasks with the help of Acceptance Criteria, the criteria should also have a reference checklist to see whether the User Story is covered.

Using Acceptance Criteria to ensure development standards
Acceptance Criteria doesn’t need to be strictly used for describing the intention of the client. As a development team lead, you might want to ensure certain standards. If you’re adding new components to a component library like Storybook, you might want to add certain knobs and settings to be implemented as acceptance criteria. If you wish to ensure unit testing, you may list a specific unit test as a part of the acceptance criteria.

How do I know if I have written good acceptance criteria?
A good Acceptance Criteria is readable and understood by all stakeholders who are concerned with the User Story. In order to ensure clear Acceptance Criteria that all stakeholders can derive value from, avoid the use of jargons.

Formats with Examples

We recommend following the formats below to create clear definitions your team can act on.

User Story:

Let's use the following User Story to consider what the Acceptance Criteria may be.

Displays text: As a (user) I can (function) so that (rationale/achieve some result)
As a Registered ABC Company user
I can see the membership expiry date
so that I know when I have to manually renew or enable auto-renew.

Acceptance Criteria (not formatted):

The membership expiry date is calculated.
The membership expiry date is displayed.
The manual renew option is displayed.
Option to opt-in to auto-renew is displayed.
Membership details are not displayed if the user is not registered/authenticated.

Acceptance Criteria (formatted)

Displays Acceptance criteria format: Scenario - This is the title of the condition to be acted upon. Given - an initial condition. When - something happens. Then - this is the result.

Scenario — Displaying options to renew ABC Company membership on Billing Details page
Given — A valid user is logged in
When — Has a valid ABC Company membership with an expiration date
Then — Show the option to renew membership manually or opt-in to auto-renew

Wrap-up

In summary, Acceptance Criteria describes the intent of the client, i.e. his/her idea of what the User Story should be like. It is up to the team to develop the solution to the User Story.

Writing a good User Story and an Acceptance Criteria is difficult but a really important task in Software Development that determines whether the software does what the user is expecting or not and finally measures the quality of the product.