The Complete User Story Playbook: From Basics to Best Practices (Part 2) + Template
Welcome to the second part of the Complete User Story Playbook. In the previous article I have explained the basic components of a user story, namely User Persona, Action and Benefit, and how they are used. I have also provided some examples on each component.
Additionally, I’ve offered some techniques for writing meaningful users stories - INVEST, 3 Cs, User Story Mapping. Here is the link to the previous article.
Now let’s talk more about best practices, mistakes and some examples of user stories.
Best Practices for Crafting User Stories
Collaboration and Simplicity
As a product manager, I never write user stories alone. Of course, technically I write them by myself, but I invite my colleagues to collaborate. First of all, collaboration is a cool thing. Secondly, several people working on the same stories add important context or allow for looking at the same thing from a different angle.
Especially technical guys, such as developers immediately see possible complications on this stage before moving further to write a specification.
Collaboration is a great tool and cannot be underestimated.
Apart from collaboration I stick to another unwritten rule of keeping the user story simple and avoiding technical jargon. A user story should be composed and executed in such a way that any person, even a stranger, understands what it is about.
Prioritization
There are always many user stories awaiting to be discussed and implemented. Some of them will go first, other will go next, and some will be put away for always. Key here is prioritization. There is no one common rule for prioritization, and different frameworks exist. I wrote about prioritization in the How to Build Your First Roadmap - A Step-by-Step Guide article.
My absolute favorite method is RICE by Intercom. The RICE acronym stands for reach (how many users will be affected), impact (how much each user will be affected), confidence (how sure you are about your estimates), and effort (how much work it will take to implement).
Acceptance criteria
Acceptance criteria are a set of conditions or requirements that a user story must meet to be considered complete and acceptable by users or stakeholders. When writing acceptance criteria for a user story, you must focus on user needs and make sure that the criteria are concrete and measurable.
Always collaborate with other stakeholders. Ask them to read the criteria before finalising them. Iterate and refine the criteria in the course of work. Here is an example of a story and its acceptance criteria:
User Story
As a customer, I want to be able to reset my password online so that I can regain access to my account if I forget my password.
Acceptance Criteria
The customer can initiate the password reset process from the login page.
The customer must provide their email address associated with the account.
A password reset link is sent to the provided email address.
The link expires after 24 hours.
The customer can click the link to access a page where they can create a new password.
The new password must meet specific complexity requirements (e.g., minimum length, combination of letters and numbers).
After successfully resetting the password, the customer is automatically logged in to their account.
An email confirmation is sent to the customer, confirming the successful password reset.
Common Pitfalls and How to Avoid Them
Vagueness
There are some common pitfalls that may affect your user stories. One of them is vagueness. When I say vagueness I mean lack of details necessary for efficient development and testing. To be more specific, user stories should be:
Concise and clear describing user’s needs and goals.
Include the acceptance criteria that I have described in the previous section.
Use concrete examples where possible.
Example of a vague user story
As a user, I want a better login experience.
Example of an improved user story
As a user, I want to log in using my social media accounts so that I can access the platform quickly without creating a new password.
Over-Detailing
Over-detailing is a common mistake that make all product managers when they want to add as much information into a user story as possible. I did this mistake many time trying to do better, and as a results my user stories where too difficult for the development team to be implemented.
If you want to avoid over-detailing, you should:
Focus on the What and not on the How. You should describe the user needs, but not the way of how to implement them.
Prioritize essential information only. This means including details necessary to explain user’s goals and needs.
Always collaborate. Looks like this is the third time I’m writing about collaboration. You should allow your development team to discuss and decide the best implementation approach.
Example of an Over-Detailed User Story
As a user, I want the login button to be blue, positioned in the top-right corner, and to use the Arial font so that it matches the design guidelines exactly.
Example of an Improved User Story
As a user, I want a clearly visible and easily accessible login button so that I can log in without searching for it.
Neglecting Non-Functional Requirements
Non-functional requirements or NFRs specify quality attributes, performance and constraints that the system must adhere to, such as security, usability, reliability, and performance standards. And they are often neglected which, in turn, leads to future problems in the product.
Here are some tips on how to effectively add NFRs:
Identify NFRs as early as possible. They might be such things as performance, scalability, usability or security.
Integrate NFRs into your user stories. You can either include them into the user story itself or add as acceptance criteria.
Review and update NFRs regularly. As your product evolves, so evolve the non-functional requirements. Review and adjust them as needed.
Example of a User Story Missing NFRs
As a user, I want to upload my profile picture so that my profile is complete.
Improved User Story with NFRs
As a user, I want to upload my profile picture quickly and securely so that my profile is complete and my data is protected.
Real-World Examples
Good User Story Examples
Example 1
User Story
As a shopper, I want to filter products by price range, so I can find items within my budget quickly.
Why It Works
Clarity: The story focuses and clearly defines the specific user need - filtering of the products.
Specificity: The user story is specific about the price range as the criteria for filtering.
Value for a user: The value is obvious - helping user’s budget.
Acceptance Criteria
The user can access a price filter option on the product listing page.
The filter allows selecting a minimum and maximum price range.
Only products within the selected price range are displayed after applying the filter.
Example 2
User Story
As an account holder, I want to receive email notifications about unauthorized login attempts so that I can take immediate action to secure my account.
Why It Works
Clarity: The story focuses on a specific user need - to receive email notifications about unauthorized logins.
Relevance: The story addresses a security issue which is highly relevant to account holders.
Value for a user: The story emphasizes ability of the user to take immediate action to secure their account.
Acceptance Criteria
An email notification is sent to the account holder for any login attempts from an unrecognized device.
The email contains details of the login attempt (time, location, device).
The email provides a link to secure the account and reset the password.
Bad User Story Examples
Example 1
User Story
As a user, I want a better search function.
Why It Needs Improvement
Vagueness: The term "better search function" is too vague and lacks specific user needs.
Lack of detail: It doesn't specify what "better" means – is it speed, accuracy, filters, etc.?
Improvement
Improved User Story: As a user, I want to filter search results by categories so that I can find relevant items more efficiently.
Acceptance Criteria
The user can filter search results by predefined categories.
The selected categories are displayed prominently on the search results page.
Only items matching the selected categories are shown after applying the filter.
Example 2
User Story
As a customer, I want the website to be fast.
Why It Needs Improvement
Vagueness: "Fast" is subjective and not clearly defined.
Lack of Measurable Criteria: There are no specific metrics or performance goals mentioned.
Improvement
Improved User Story: As a customer, I want the website pages to load within 2 seconds so that I have a smooth browsing experience.
Acceptance Criteria
All main website pages load within 2 seconds under standard conditions.
Performance is measured and verified using common performance testing tools.
Users receive a feedback message if a page takes longer than 2 seconds to load, suggesting potential reasons and solutions.
By reading the examples you can see that good user stories are very specific and focused on user needs. Also, they have clear acceptance criteria. At the same time bad user stories lack details or do not clearly identify user goals, or value.
User Story Template and AI Prompt to Check It
You are a product manager with 20 years of experience, and I want you to review my user story. I will provide you with the user story {instructions} and {review questions}. The following sections are optional: Non-Functional Requirements, Priority, Notes. If they are marked with N/A, just skip them. The result of your review should be a summary outlinin…
Instead of a conclusion
Please subscribe to support my work. If you have any question connect with me using: