How to Write User Stories and Acceptance Criteria

Perhaps everyone who works in Business Analysis has encountered the task of writing user stories. In every business analyst interview I've been a part of, either as an interviewer or interviewee, there have always been questions about user stories, such as:

• Do you write user stories?
• Provide an example of a user story.
• How do you break down user stories?
• What are the characteristics of a good user story?
• Given a certain task, write three user stories.
• What acceptance criteria would you propose for a specific user story?
• How to write acceptance criteria for user stories?

Writing requirements is a key skill for a business analyst. In the modern world, where agile software development methodologies are increasingly chosen, user stories often serve as the primary requirements in most projects.

Becoming a business analyst without the ability to write user stories correctly is extremely challenging. It involves not only understanding what constitutes a user story but also the skill of formulating them correctly, supplementing them with appropriate acceptance criteria to ensure there are neither too many nor too few. It also requires an understanding of what else can be added besides criteria, such as design, diagrams, call recordings, or request emails.

Let's explore at a high level what a user story is, what it consists of, and look at examples of user stories.

What is a User Story?

In the realm of Agile methodologies and software development, a user story is a brief narrative of the requirements, needs, or goals of a specific user. Unlike traditional exhaustive requirement documents, user stories are oriented towards simplicity and user-centricity. They serve as windows into the world of users, providing a vivid representation of their desires and expectations.

Components of a User Story

A well-structured user story comprises three main components: User Role (sometimes User Persona), Action, and Benefit.

Role: At the core of each user story lies the user or persona. This component clarifies around whom the user story revolves and provides context to subsequent elements.

Action: The action defines what the user wants. It can be an action, task, or goal that the user aims to achieve with the help of the software.

Benefit/Value/Goal: This component describes the value or advantage the user gains by reaching the set goal. It reveals the "why" or "for what" behind the user's desired action.

Example User Story:

"As a registered user, I want to reset my password to regain access to my account." In this case, the role is a registered user. The role could be more specific, but the crucial point is that this user already has an account.

"I want to..." - this is essentially our goal, what the user wants to achieve.

However, sometimes the final goal is not what we think it is; sometimes the action itself is not the ultimate objective unless you are a samurai.

For instance, we need a key for the lock not just to pen or close the door. Opening a door is needed, for example, for entering some room, office, apartment. Entering or exiting is usually not the final goal; there's usually more to it (so you decide what is the goal that might be truthful and valuable enough, and general enough to fit all the users named in the story).

Getting money from an ATM usually is also not the ultimate goal because the goal here is either to give those funds to someone for specific services or to buy something where cards are not accepted.

In conclusion, the final benefit is what gives us more context. If a user needs access to their account, resetting the password might not be the only solution. For example, we could send a "magic link" to the user's email, allowing them to access the account automatically without entering a password.

This aspect is crucial for the team to find the best solution among all possibilities and feel that the task serves a specific, tangible benefit to someone. And that is gratifying!

Maintain Simplicity and Purpose

When crafting user stories, prioritize brevity and clarity. Express user stories in a concise manner, steering clear of unnecessary technical jargon and intricate details. This approach ensures that the core of user needs is maintained, fostering better understanding among all involved parties.

It may sound straightforward – communicate clearly and succinctly. However, honing this skill is like working a muscle – it requires experience and human review (because it is actually possible to run/swim/workout incorrectly). Essentially, you write the stories, and someone else takes a look.

Examples of user stories:

1. "As a new visitor, I want to watch a product demonstration video to save time on learning about it."
2. "As a regular customer, I want to save products in my wish list for future purchases."
3. "As an administrator, I want to generate monthly sales reports to monitor business effectiveness."

What else is needed in a user story?

Surely, you've already guessed that what's described above is clearly not enough to implement this functionality. But why then do they emphasize the need to write user stories and not talk about something else? Because user stories encompass much more than what has been described above.

Component, Without Which User Stories Won't be taken Into Development - Acceptance Criteria.

How to write acceptance criteria for user stories

In other words, for a user story like, for example, "As a registered user, I want to reset my password to regain access to my account," it's impossible to carry out the task—how does the business analyst want the developer to accomplish this? Details are needed here since there can be many variations.

Acceptance Criteria, or AC, delineate these criteria. Let's try to write them all.

1. The user has access to the password reset function on the login page. (Note: it's written quite abstractly, but details can be seen in the design.)
2. When clicking the "Forgot Password?" link (let's imagine we decided the link is the password reset function), the user is redirected to the password reset page.
3. On the password reset page, the user is prompted to enter the email address associated with the account.
4. After filling in the email address field with a valid format and submitting the form, the user sees a message. (Note: the definition of a valid format should be explained somewhere, but it's not suitable for the system requirements, as it would make the system too complex to check and manage. In addition, the message could be described in the notes of the story or on a separate page where all messages in the system are stored, so that when writing a new one, it adheres to the format of the others. A link to this document should be linked to the user story. How and where the message is displayed is a design question (the design should also be linked to the story). And yes, a message like "if an account is registered with this address, you have been sent an email" should be displayed even if there is no account associated with this address, as otherwise, you give attackers a loophole to obtain "valid" email addresses—knowing the address registered in the system, one can already "break" the account by trying different passwords.)
5. If the entered email address is associated with a registered account, the user receives a password recovery email. (Note: the development of the email itself can be in a neighboring user story, and then the user story with the email blocks the development of this one, meaning it must be developed before completing this.)
6. The email contains a unique link that, when clicked, takes the user to a secure password reset page.
7. On the password reset page, the user can enter a new password and submit it.
8. The password input field contains password complexity checking rules. (Note: for example, minimum length, inclusion of uppercase and lowercase letters, numbers, and special characters. These details are either described somewhere or adhere to the general rules of the project's accepted password complexity requirements—they can vary. In any case, in the story, provide a link to these rules or describe them in the notes. But by the time the story is developed, the team must have already completed the registration implementation, where the password complexity requirements should have been described.)
9. If the user submits the form with a password that does not fit the criteria, the user sees a message, and the password is not replaced.
10. After entering the new password that fits the criteria, clicking the "Reset Password" button updates the user's password.
11. After a successful password reset, the user is automatically redirected to the login page. (Note: this is also a security rule, as automatic login introduces vulnerabilities.)
12. The user can log into the system using the new password.
13. The user cannot log into the system using the old password. (Note: a criterion for added security)
14. When attempting to use a password reset link from email, that was already used to reset the password, an error message appears indicating that the link has expired or has already been used. (Note: and here we come up with the idea that the link actually must have a limited validity period, so we add the next AC—a acceptance criterion. And yes, don't forget to write about this in the email—the user should understand how long they can count on it.)
15. The password reset link is valid for 1 hour after sending. (Note: the validity period of the link can vary; for example, for banking systems, this time may be shortened to 10 minutes. There are security rules, especially in your company or the client's company—it's better to find out what they are rather than invent your own. If they don't exist, adhere to standards, for example, https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Forgot_Password_Cheat_Sheet.md. OWASP is an online community that creates freely available articles, methodologies, documentation, tools, and technologies in the field of web application security.)
16. No confidential information should be disclosed or available to unauthorized persons. (Note: it may seem like a vague criterion, but it is verifiable—somewhere, indicate what data the system stores, and QA will check if they haven't "leaked" somewhere in the process—such as the email address, name in the link, messages on pages, etc.).

In summary, when trying to write criteria for one user story, there were a total of 16. Guided by Characteristics of Good Requirements in Software Engineering, we check if everything is written well. After all, each user story is a requirement. We see immediately that we did not pass the 1st and 3rd—Atomicity and Conciseness.

Regarding Atomicity, some criteria can "move" to another full-fledged user story. Go back up and try to think about which ones exactly?

As for Conciseness, a "good user story" at first glance contains 2-8 criteria (this is not a mandatory rule, but a guideline). Yes, we almost doubled that. Decomposition of requirements will help us here.

Step 2 in writing a good user story is an attempt to evaluate the user story against the criteria of quality requirements. Then, if necessary, we break down the user story, remove all ambiguities, consider whether all criteria are described, and continue fine-tuning.

In the end, a user story should emerge that solves one user problem (yes, a user story cannot be unfinished—if, for example, the user story contains criteria 1-4, it does not complete the task from start to finish, so it is no longer a user story—hardly the user's goal is to see the message).

While "fine-tuning" the user story, don't forget about all the additions—text messages, designs, diagrams, rules, including non-functional requirements—for example, the email should not be sent later than...

It's not that simple, but you can learn it. I can help—proofread your stories and give recommendations for improvement—either based on your project or as an educational example, in which case I'll provide the assignment - if interested, contact me at iamthebagirl@gmail.com or connect with me on LinkedIn at https://www.linkedin.com/in/nataliiachausova/. Or, if you are a business owner or a manager, I can check user stories of your Business Analysts or Product Owners.

Conclusion

User stories form the foundation of user-oriented software development, bridging the gap between developers and end-users. Understanding the role of user stories and mastering the art of writing them allows business analysts to create synergy with the team and stakeholders, leading to the development of products that genuinely cater to user interests.

Well-crafted user stories not only optimize the development process but also contribute to close collaboration among stakeholders, resulting in the realization of projects aligned with user needs and business goals. A well-thought-out user story is more than just a requirement; it is a narrative that unites aspirations, intentions, and outcomes. This narrative should be concise, clear, achievable, testable, and meet the quality criteria of requirements.

Effective user stories not only streamline the development process but also contribute to close interaction among stakeholders, leading to the implementation of projects that align with user needs and business goals. A well-thought-out user story is more than just a requirement; it is a narrative that unites aspirations, intentions, and outcomes.

To create a good user story, one shall understand how to write acceptance criteria for user stories, and what other elements shall be added to a user story to make it meet the Definition of Ready.

This narrative should be concise, clear, achievable, testable, and meet the Quality Characteristics of Software Requirements.

Writing user stories is just one thing business analysts should master. Read more about Business Analyst Skills