What is User Story and Acceptance Criteria? Example

Master the art of crafting user stories and learn to define acceptance criteria that ensure project success. Explore all about User stories and acceptance criteria to unlock the power of clear communication in software development:

In the software development industry, the word “requirement” defines our goal, what the customers need exactly, 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

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 revisit the fundamentals first.

What is a User Story?

A user story is a requirement for any functionality or feature that 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>.

Example:

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.

What are the Acceptance Criteria?

The acceptance criteria is a set of accepted conditions or business rules for which the functionality or feature should satisfy and meet, 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 thing i.e. User Stories.

The cases given below are my own real experiences.

Case #1

3 years ago, I was working on a Mobile Application Project and the product was an application that was designed for 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 is reflected on the portal of the courier service providers like DTDC, FedEx, etc.

Let’s imagine that the mobile app has 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“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 “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 to 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 and finance Advisors could use it for different currencies to project 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 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 interoperability 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, 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, 3 things are 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 only credit or both.

Such cases may happen once in a while, however, still study each acceptance criteria and try to visualize 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.

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.

Conclusion

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!!