What is User Story and Acceptance Criteria (Examples)

A Detailed Tutorial on User Story Acceptance Criteria using practical instances:

In the realm of Software Development, the phrase ‘Requirement’ outlines our purpose, consumer demands, and the ways it can boost our business.

Whether it’s a product firm that develops software products or a service company that delivers software-related services, the bedrock for both is the requirement, and victory is gauged by how effectively those requirements are satisfied.

Requirements bear different designations in various project methodologies:

In Waterfall, it’s known as ‘Requirement/Specification Document’, while in Agile or SCRUM, it’s called ‘Epic’ or ‘User Story’.

In the Waterfall model, requirement documents are broad, spanning over 200 pages as the complete product is developed in a single phase. Yet, Agile/SCRUM methodologies involve smaller requirements for individual features or functionalities, as the product is developed incrementally.

This guide seeks to share my rich 4-year experience with User stories and their interconnected Acceptance Criteria, incorporating real-world examples for improved understanding.

Let’s rehash the basics first.

Alternate Terms for User Story:

A user story portrays a requirement for a functionality or feature, succinctly written in one to five lines. It mainly encapsulates a single functionality or feature.

The most common template for creating User Stories is as follows:

As a <user role/customer>, I want < objective to be attained> so that I can <Justification for the objective>.

Example:

As a WhatsApp user, my preference is a camera icon in the chat textbox to seize and distribute pictures, thereby enabling real-time sharing with friends.

Alternate Terms for Acceptance Criteria:

An acceptance criterion comprises authorized conditions and business norms that must be satisfied for a functionality or feature to be accepted by the Product Owner/Stakeholders.

This is a pivotal element of accomplishing a user story and should be meticulously studied by the Product Owner and Business Analyst, as neglecting a single criterion can have noteworthy consequences. Acceptance criteria are generally presented in a numerated or bulleted list format.

Here is the format:

“Given certain conditions, when I execute a particular action, then I expect a specific outcome”.

Example (connected to the above user story):

• Assuming I’m engaging in a conversation with a friend, I should be capable of seizing a photograph.
• When I select a photo, I should possess the capability to add a caption prior to sending it.
• If there’s an issue with deploying the phone camera, an appropriate error notification like ‘Camera could not be activated’ should be exhibited.

Thus, the User story outlines the requirement for a functionality or feature, whereas the Acceptance Criteria defines the ‘Definition of done’ for the user story or the requirement.

It’s vital for a QA professional to have a comprehensive comprehension of the user story and its acceptance criteria, leaving no scope for uncertainty when commencing the testing process. Let’s now look into why it’s crucial to investigate thoroughly into user stories and acceptance criteria.

Diving deep into User Stories

Above all, it’s imperative to understand the importance of studying a fundamental component – User Stories.

The following instances are drawn from my personal experiences.

Case #1:

Three years ago, I was engaged in a Mobile Application Project that aimed to develop a delivery application.

You might have experienced delivery personnel soliciting your signature upon delivery, which then appears on the courier service provider’s portal (e.g., DTDC, FedEx, etc.)

Let’s assume that the mobile app has just been launched and the portals are already operational.

Challenge: In one sprint, the Product Owner introduced a user story for the mobile app: “As a Portal Admin, I should have the ability to view the delivery person’s signature at the time of delivery”. Subsequently, the portal (web app) was updated to embody the signature.

As a QA professional, your responsibility is to ensure that the signature recorded in the mobile app is correctly exhibited on the portal.

Although this user story may seem simple, it carries a concealed requirement: “What should occur if the portal exhibits historical deliveries?” Should historical data be removed? Should malfunctions or errors develop for such data?

Obviously, this should be addressed professionally.

Solution: When the pertinent database tables are updated to encompass a new column for Signature location, the old data should bear a NULL or 0 value. This should be verified, with a message appearing stating ‘No signature exists’.

Although this could be an omission on the part of the Product Owner or Business Analyst, it nonetheless needs to be resolved. Successfully implementing one feature at the expense of disrupting another is not favorable for customers. It’s crucial to address this issue in the same sprint and within the same user story.

Case #2

Six years ago, I contributed to a Retirement Planning Finance Application (without a Business Analyst), which was globally launched for finance professionals like Chartered Accountants and Financial Advisors. It enabled planning for different currencies, predicting investment plans, saving, etc., over a long period.

Challenge: The Product Owner presented a User Story: “As an Advisor, I want to view my customer’s report based on the provided financial details”.

Here, two concealed requirements remained unaddressed, rendering this story incomplete:

a] The reports should contemplate the daily currency conversion rate, not the historical one from the last viewed report.

b] If the currency is altered after providing the customer’s financial details, the reports should be exhibited in the updated currency.

Solution: I directly communicated this issue to the Product Owner, stressing the urgency of resolving these requirements. He concurred and generated two separate user stories for the upcoming sprints with a higher priority.

Takeaway: These issues were detected as we had a comprehensive knowledge of the products, their design, and blueprint. Such understanding can only be acquired by rigorously comprehending the product, its modules, and studying the user story in detail, even if it is merely a few lines. Take notes to facilitate conversations with Business Analysts and developers about their thought processes.

Comprehensive scrutiny of Acceptance Criteria

Understanding the acceptance criteria and all other prerequisites and rules is even more critical than understanding a user story. Incomplete or nebulous requirements can be addressed in the next sprint, but missing acceptance criteria can hinder the release of a user story.

We have all utilized net banking at some point, and for those who use it frequently, we are aware of the available options for downloading statements.

We can choose the type of file for downloading our statements, opt to download only credits/debits/both, and much more.

Let’s consider this User story: “As a customer, I want to download my account statement so that I can view all my transactions over a specific period.”

With the following Acceptance Criteria:

• Assuming I am on the Download Historical Statement Page, I should be able to select the required period for statement download.
• Assuming I am on the Download Historical Statement Page, I should be able to choose the required account for statement download.
• Assuming I am on the Download Historical Statement Page, I should not be permitted to select a future ‘To’ date for the statement.
• Assuming I am on the Download Historical Statement Page, I should not be permitted to select a ‘From’ date older than 10 years.
• Assuming I have downloaded my statement, I should be able to view the downloaded file.
• Assuming I am on the Download Historical Statement Page, I should be able to download my statement in doc, excel, and pdf formats.

If we thoroughly inspect these acceptance criteria, three aspects are missing:

• File name and format for downloading.
• The information (Column names) to be included in the file.
• The options to select the required transactions, such as only debits, only credits, or both.

While such occurrences may happen from time to time, it’s still pivotal to diligently examine each acceptance criterion and envision it in relation to the user story. The deeper your analysis of the conditions and business rules, the better your comprehension of the feature will be.

Bugs detected in the early phases incur a negligible cost compared to the cost they may generate during the testing phase.

Importance of identifying Discrepancies in User Story/Acceptance Criteria

It’s critical to delve deep into user stories and acceptance criteria at the preliminary stages, even before the commencement of development or testing.

This is because:

#1) Time Misappropriation:

If discrepancies or errors in user stories/acceptance criteria are discovered during the development or testing phase, considerable rework may be necessary within the remaining time of the sprint.

It’s not assured that if the Product Owner neglected certain aspects, they will defer the user story to the subsequent sprint. In 95% of instances, they will insist on implementation within the same sprint. Consequently, the team may be loaded with supplementary work, inclusive of working on weekends or late into the night. Such situations can be forestalled by studying and discussing user stories/acceptance criteria at the earliest possible stage.

#2) Exertion Misappropriation:

Developers and QA specialists will need to revisit executed code and test cases, integrating updates, additions, and deletions based on requirements. This is not a walk in the park, particularly when there is already pressure to meet deadlines. Under such circumstances, there is a higher risk of committing errors in the development or testing stage. If you encounter such predicaments, consider participating in ‘DevQA Pairing.’ Additionally, you may not receive remuneration for the extra work.

Conclusion

An exhaustive comprehension of User Stories and acceptance criteria can only be gained through dedicated exploration and analysis.

There are no explicit tools or courses available in the market to accomplish this task for you; it all narrows down to logical reasoning, experience, and thorough knowledge of the product.

Active engagement in pre-planning meetings, correspondence with Business Analysts, and individual study are key to attaining this level of understanding. The more labor you invest, the more you will assimilate and evolve.

For both QA professionals and developers, it’s crucial to be in sync concerning user stories and their acceptance criteria to effectively fulfill customer expectations.

Do you have any fresh insights or experiences to share about your work with User Stories? We would love to hear your thoughts below!