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:

  1. Introduction
  2. How to formulate User Story Acceptance Criteria?
  3. User Story Acceptance Criteria vs. Definition of Done
  4. Summary


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.

user story acceptance criteria

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

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


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.

Scrum Guide | 22. User Story Acceptance Criteria caroline becker avatar 1background

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.

Scrum Guide:

  1. Glossary of basic terms, roles and notions
  2. What is Scrum?
  3. Scrum values
  4. How to implement Scrum in your company?
  5. Scrum Team - what is it and how does it work?
  6. Who is a Product Owner?
  7. The most common mistakes of Product Owner
  8. Who is the Scrum Master?
  9. Characteristics of a good Scrum Master
  10. The most common mistakes of Scrum Master
  11. What statistics and metrics should the Scrum Master track?
  12. Cooperation between Product Owner and Scrum Master
  13. Development Team in Scrum
  14. The most common mistakes of Developers
  15. Scrum artifacts
  16. Scaling Scrum
  17. Sprint Backlog
  18. What is the Product Backlog?
  19. What are User Stories?
  20. Creating the best User Story with INVEST
  21. The most common User Story mistakes
  22. User Story Acceptance Criteria
  23. Estimation and Story Points in Scrum
  24. Planning Poker
  25. Team Estimation Game
  26. Defining Increment
  27. Scrum events
  28. What is Sprint in Scrum?
  29. Scrum Team Commitments - Product Goal, Sprint Goal and Definition of Completion
  30. What is a Burndown Chart?
  31. How to create and interpret a burndown chart?
  32. Advantages and disadvantages of the burndown chart
  33. Kanban boards in Scrum and Scrumban
  34. Velocity in Scrum - Speed of the Development Team
  35. Daily Scrum
  36. Sprint Planning
  37. Sprint Review
  38. What is a Sprint Retrospective?
  39. Common mistakes during a Sprint Retrospective
  40. Product Backlog nurturing