Here is the Perfect Guide to User Story Acceptance Criteria with real-life scenarios:

In the Software Development industry, the word “requirement” defines what our goal is, what the customers exactly need, and what will make our company increase its business.

Be it a product company that makes software products or a service company that offers services in various software fields, the prime base for all of them is the requirement, and success is defined by how well the requirements are met.

The term ‘requirement’ has different names in different project methodologies.

In Waterfall, it is referred to as a “Requirement/Specification Document”, in Agile or SCRUM it is referred to as an “Epic” or “User Story”.

What is the User Story and Acceptance Criteria

What Is User Story And Acceptance Criteria

Under the Waterfall model, the Requirement documents are huge docs of 200 or more pages as the whole product is implemented in one phase. But this is not the case with Agile/SCRUM because in these methodologies the requirements are given for small functionalities or features as the product is prepared in a step by step manner.

In this article, I have tried my best to share all my 4 years of experience on working with User stories and their related Acceptance Criteria along with easy and simple real-life scenarios for your better understanding.

Let’s re-visit the fundamentals first.

What is a User Story?

A user story is a requirement for any functionality or feature which is written down in one or two lines and max up to 5 lines. A user story is usually the simplest possible requirement and is about one and only one functionality (or one feature).

The most commonly used standard format for a User Story creation is stated below:

As a <user role/customer, I want to < goal to be accomplished> so that I can <reason of the goal>.


As a WhatsApp user, I want a camera icon in the chat write box to capture and send pictures so that I can click and share my pictures simultaneously with all my friends.

User Story and Acceptance Criterion

What is Acceptance Criteria?

The acceptance criteria is a set of accepted conditions or business rules for which the functionality or feature should satisfy and meet, in order to be accepted by the Product Owner/Stakeholders.

This is a very important part of user story completion and it should be studied by the Product Owner and Business Analyst very meticulously because missing a single criterion can cost a lot. This is a simple numbered or bulleted list.

The format is as follows:

Given some precondition when I do some action then I expect the result”.

Example (w.r.t for the above user story):

  • Please consider chatting with a friend and I should be able to capture a picture.
  • When I click on a picture, I should be able to add a caption to the image before sending it.
  • If there is some problem with starting my phone camera, an error message like “Camera could not be started.” etc., should be shown accordingly.

Hence, the User story defines the requirement for any functionality or feature while the Acceptance Criteria defines the “Definition of done” for the user story or the requirement.

As a QA it is very important to understand the user story and its acceptance criteria profoundly with not even a single doubt remaining at the start of testing. Moving forward, let’s understand why it is extremely important to dig deep into user stories and acceptance criteria.

Digging deep into User stories

To start with, let us first understand the importance of an in-depth study of a basic and fundamental thing i.e. User Stories.

The cases given below are my own real experiences.

Case #1:

Before 3 years, I was working on a Mobile Application Project and the product was an application that was designed for the delivery people.

You would have seen a delivery person coming to your place for delivery. They have a mobile phone on which they ask you to give your signature after delivery. This signature reflects on the portal of the courier service providers like DTDC, FedEx etc.

Let’s imagine that the mobile app is just launched and their portals are already existing and up.

Problem: For a Sprint your Product owner has a user story for this mobile app that “As a Portal Admin, I should be able to view the signature taken by the delivery person at the time of delivery”. Here the portal (web app) has been changed and updated accordingly to reflect the signature.

As a QA you have to verify if the signature captured in the mobile app is reflecting as expected in the portal.

If you look at this user story, it looks simple, but there is a hidden requirement here that “For historical deliveries, there was no signature reflection functionality, so what should happen if the portal guys view historical deliveries?” Should historical data be wiped out? Should we allow crashes or errors for such data?

Of course not at all, this should be handled graciously.

Solution: When the respective DB tables are updated to add a new column for the Signature location, the old data should have a NULL or 0 value which should be checked and a message stating “No signature exists” should be shown.

This can be called a miss by the Product Owner or Business Analyst, but this has to be done. Implementing one feature successfully but breaking something along with it is not desirable by the customers. This needs to be done along with the same user story and in the same sprint.

Case #2

6 years ago, I was working on a Retirement Planning Finance Application (with no BA) which was a global application where Finance folks like CA, Finance Advisors could use it for different currencies to project the investment plans, savings, etc., over a large period to their customers.

Problem: The Product Owner gives you a User Story that “As an Advisor, I want to view the report of my customer based on the financial details provided”.

There are 2 hidden requirements here and I would call it an incomplete story because:

a] The reports should consider the daily currency conversion rate and not the historical one as in the last viewed report and

b] If the currency is changed after providing the customer’s financial details, the reports should show in the changed currency.

Solution: I raised this concern directly with our Product Owner and made him aware that both of these had to be done as soon as possible. He agreed with me and created 2 different stories for the upcoming sprints with priority.

Take Away: These were caught because we were all very well aware of the products, their design, structure, etc. Such knowledge can only be achieved by understanding the product completely, by understanding the inter-operability of modules, and by studying the user story thoroughly even if it’s a 2 liner.

Make notes to make things easier and discuss with BA’s and the developers about their thinking.

An In-Depth Look at Acceptance Criteria

Understanding the acceptance criteria and all the other conditions& rules exhaustively is even more important than understating a user story. Because if a requirement is incomplete or vague, it can be taken up in the next sprint but if an acceptance criterion is missed, then the user story itself can’t be released.

I guess we all would have used net banking at some point and most of us use it every day and I download my historical statements a lot. If you observe it carefully, there are certain specific options available for downloading them.

There is an option to select the type of file to download on your statement. There is an option to choose only if you want to download the Credits/debits/both.

Now imagine that the Product Owner will give you this User story “As a customer, I want to download my account statement so that I can view all my transactions done for a specific period”.

with the following Acceptance Criteria:

  • Considering that I am on the Download Historical Statement Page, I should select the period for which I want to download the statement.
  • Considering that I am on the Download Historical Statement Page, I should select the account for which I want to download the statement.
  • Considering that I am on the Download Historical Statement Page, I should not be allowed to download the statement for a future date.
  • Considering that I am on the Download Historical Statement Page, I should not have been allowed to select a date of 10 years or more in the past.
  • Considering that I downloaded my statement, I should be able to view the downloaded file.
  • Considering that I am on the Download Historical Statement Page, I should be able to download my statement in doc, excel, and pdf formats.

If you go through this acceptance process, there are 3 things missing here:

  • Name and format of the file name that will be downloaded.
  • What information (Column names) is to be displayed in the file?
  • List the options to select what kind of transaction the customer wants i.e. only debit or only credit or both.

Such cases may happen once in a while, however still study each acceptance criteria and try to visualize it with reference to the user story. The more you study deeply about the conditions and business rules the more your knowledge will be about the feature.

Bugs found in the initial stage cost nothing compared to what they may cost in the ‘testing’ stage.

Acceptance Criteria

Importance of Finding Discrepancies in User Story/Acceptance Criteria

It is always important to do a deep dive into the user stories and acceptance criteria at an early stage even before the development or testing commences.

Since it involves:

#1) Wastage of Time:

If discrepancies or mistakes in the user story/acceptance criteria are found when development is going on or testing is going on, then a lot of rework may need to be done in the remaining sprint time.

It doesn’t happen that even if the Product Owner missed a few things, they will move the user story to the upcoming sprint. 95% chances are that they will ask the team to do the necessary implementation and release it in the same sprint.

Hence it becomes a nightmare for the team as they have to spend extra time, come on weekends or work late at night. This can be avoided by studying and discussing the user story/acceptance criteria at the earliest possible stage.

#2) Wastage of Efforts:

The developers and QA have to revisit the implemented code and test cases again. Updating, adding, and removing as per requirement is not an easy task. It becomes too painful as there is already pressure to deliver on time.

In such a situation, there are chances of mistakes in the development or testing stage. If you come across such a situation, go for a “DevQA Pairing”. With the icing on the cake, you may not get compensation for the extra work.

User Story and Acceptance Criteria discrepancies


A deep understanding of User Story and acceptance criteria can only be achieved by spending immense time studying them.

There is no specific tool or course available in the market to do this for you as this is all about logical thinking, experience, and knowledge about the product.

Participating in Pre-plan meetings actively, talking to the BA, and studying on your own can only help you to achieve this. The more effort you put in, the more you learn and grow.

Be it the QAs or developers, everybody has to be on the same page about the user stories and their acceptance criteria, only then can the expectations of the customer be achieved successfully.

Do you have anything new to share with us about your experiences working with User Stories? Please express your thoughts below!!

Genislab Technologies

NexGeneration complete end-2-end software testing & modern development operations tooling & solutions

Do you want to discuss your testing requirements with us? please don’t hesitate to hit the contact us button below, and we will get back to you at our earliest..