User Story Acceptance Criteria and Definition of Done

User Story is a technique allowing businesses to deliver products and services meeting customer need to the maximum. User Story acceptance criteria enhance the assessment of new Product functionalities from the user’s point of view.

User Story Acceptance Criteria – table of contents:

Introduction
How to formulate User Story Acceptance Criteria?
User Story Acceptance Criteria vs. Definition of Done
Summary

Introduction

We covered User Story and issues to tackle upon its creation in previous articles. Today, however, we will focus on User Story acceptance criteria.

The acceptance criteria should follow these guidelines:

describe the new and improved functionality of the Product from the user’s point of view
be unique for each User Story

The official Scrum Guide doesn’t define User Story and its acceptance criteria. They are optional, but very common elements of Scrum work. Still, to ease our readers’ curiosity we’ll depict them as: The conditions that a Product enhancement has to meet during a given Sprint to get approval from the User.

How to formulate User Story Acceptance Criteria?

A well-written User Story contains a clear description of the context or situation it concerns, thus meeting the acceptance criteria. Still, it is just short sentence, too vague and ambiguous to straightforwardly pinpoint necessary considerations.

Clarity and accessibility of acceptance criteria

Therefore, to prevent ambiguities, conduct and record a detailed conversation with the customer to determine the purpose of the implemented solution. Remember that the final formulation of acceptance criteria belongs to the Product Owner.

Write them down together with User Story criteria before Sprint Planning. Each Scrum Team member has to read it and confirm that they understand and agree with the User Story acceptance criteria. Usually, the acceptance criteria are on the other side of the User Story card.

Properly formulated acceptance criteria allow the user to check if testing User Story follows its description. The criteria can take the form of a checklist with bullet points to tick when completed during the Product testing at the end of a Sprint.

The matter is simple if the Product’s operation is transparent to the User. However, the more complex the product, the more difficult it gets to test. Take complex software or large-scale services. Therefore, in most cases, a useful tool to validate User Story is to prepare an acceptance test.

Acceptance test

If you decide to develop an acceptance test, put it down on the other side of the card containing the User Story. Later, the Scrum Team or an external QA team can carry it out.

The test must first and foremost contain a clear statement of whether the Product fails or passes the test. It cannot contain percentage statements or intermediate evaluation.

If the User Story has more than one acceptance criterion, each requires separate testing. This way, it is much easier to determine which product functionality needs improvement or refinement and is especially important if new functionalities included in the User Story overlap or are independent of each other.

User Story Acceptance Criteria vs. Definition of Done

Definition of Done is an integral part of working in Scrum, which is the technical equivalent of acceptance criteria. However, you shouldn’t confuse these two as they denote different commitments. What is the Definition of Done, and how and when to formulate it is an issue we covered in a separate post?

Here, we will only mention that the Definition of Done is a clear and transparent description of the expected state of the Product after the completion of the Increment in the Product Backlog. It describes the improvements made within the Increment. This stands in contrast with the acceptance criterion corresponding to User Story, which describes the Product functionality created during the last Sprint as it is perceived by the Customer.

For example, take this User Story with the content:

As a logged-in customer of an online store, I want to buy a magic wand with one click.

The Definition of Completion for the above User Story might include the following:

the creation of a login panel for store customers
integration of the payment system
adding the instant payment button to the product page template

On the other hand, the customer acceptance criteria feature:

the ability to log into the store
the possibility of defining a default payment method
working “Buy now” button for the “magic wand” product

Summary

The acceptance criteria are a set of conditions that function as a way to evaluate the implementation of the User Story. By describing new and improved Product performance from the user’s point of view, this method becomes an effective tool for working with the Customer. It presents the Scrum Team’s performance from user’s point of view.

Well-formulated acceptance criteria, for example in the form of an acceptance test, also allow us to check during a Sprint whether the created functionality enhances meeting the Customer demands.

Acceptance criteria differ from the Definition of Done primarily in the perspective they take upon expression. They do not contain a description of technical requirements that the new solution should meet, but only the functions that the product should feature after actualizing the new User Story.

If you like our content, join our busy bees community on Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Author: Caroline Becker
As a Project Manager, Caroline is an expert in finding new methods to design the best workflows and optimize processes. Her organizational skills and ability to work under time pressure make her the best person to turn complicated projects into reality.
View all posts