Features
Product Managers write user stories that translate clients’ needs into valuable capabilities. Each user story belongs to a feature and targets the delivery of specific business value that helps clients succeed.
Principles
Feature user stories exist to translate product vision into user value. Every user story must clearly articulate the user problem being solved and the business outcome being driven.
A user story succeeds when it delivers meaningful value to users and measurable impact on the business.
A good user story must be concise, clear, and small. It must focus on a single, functional capability that delivers user value and be ready for pick-up considering the following aspects.
User Value Validation
Every user story must articulate the specific user problem it solves and the business value it creates. Stories that cannot clearly demonstrate user impact should be reconsidered or reframed.
Product Managers should validate that each story delivers standalone user value that can be measured and evaluated independently.
Example: explain clearly the “Why” of the “Order History” feature
Feature: Order History
## Why
Returning customers want to quickly reference their previous food orders to reorder favorites, or resolve order issues. Without easy access to order history, customers spend time searching through emails or calling restaurants, leading to frustration and potential order abandonment. Order history with reorder functionality reduces friction for repeat purchases and increases customer lifetime value.
Clear Definition of Done
Product Managers must define a common ground for how a user story will be tested and validated from the user’s perspective. The user story’s acceptance criteria represent the Definition of Done for the complete user capability being delivered.
The acceptance criteria must focus on user-observable behavior and business outcomes. They must be crystal clear with no room for interpretation, ensuring developers understand both what to build and why it matters to users. An unclear Definition of Done can yield different results and inefficient, preventable back-and-forth on a user story.
Example
User Story: As a user, I can view my past orders
## Acceptance Criteria
- Display a chronological list of my last 20 orders, most recent first
- Each order entry shows: order date, restaurant name, order total, and order status
- Show "No orders yet" message when user has no previous orders
- Display order status as: "Delivered", "Cancelled", or "Completed"
- Each order entry is tappable to view more details (handled in separate story)
Implementational Resources
When writing user stories, Product Managers must envision how all the pieces will fit together in the grand scheme. Often, it includes thorough research, UX/UI walkthroughs, product discussions, documentation, etc.
The Product Manager must ensure all critical information is shared in the user story so that developers have everything they need to implement the feature as envisioned.
Example
User Story: As a user, I can view my past orders
## Resource
- API endpoint specification for retrieving user's last 20 orders with required fields (order_id, date, restaurant_name, total_amount, status)
- Order status mapping documentation ("delivered", "cancelled", "completed" enum values)
- UI mock-up for order list layout
- Analytics tracking specification for measuring user engagement with order history
Core Components
Product Managers construct user stories with three core components: Why, Who, When, and What.
Why
It articulates the user problem being solved and the business value being created. This component connects the story to user needs and business objectives, ensuring every story delivers a meaningful impact. It also provides essential context to engineers, helping them understand the purpose behind the implementation and make informed technical decisions.
The Why component is mandatory and should clearly demonstrate how the story contributes to user success and business goals while giving the development team the context they need to build the right solution.
Who
It identifies which “user” the user story is for. It is commonly a specific end-user role (e.g., user, admin, patient, etc.) or type of user (e.g., a registered user, a guest user, etc.).
When
It refers to the condition that triggers the user story. It can be a specific or a general condition, e.g., when the account balance is empty, if the camera permission is declined, when the server is under maintenance, etc.
What
It corresponds to the functionality delivered via the user story, e.g., processing a payment, registering an account, creating a new resource, etc.
The What component also comprises extensive details on how the functionality must work, e.g., the UX/UI, the business logic, the data handling, etc. These details are written in the user story description to form the acceptance criteria.
User Story Template
Title
The user story’s title comprises the Who, When, and What components.
The following alternative formats must be used:
As a (Who), (When), I (can/must) (action verb) (What)
As a (Who), I (can/must) (action verb) (What) (When)
Description
The user story’s description mainly comprises the Why and the What component.
## Why
What it will solve or what value it delivers to end-users.
### Acceptance Criteria
List down how the feature must work and what criteria are necessary for the user story to be accepted.
## Technical Considerations
(Optional) Provide implementation guidance, technical constraints, or architectural notes that help developers understand the approach while maintaining focus on user outcomes.
## Design
(Optional) Add design screenshots or Figma links for UI/UX-related stories.
## Resources
(Optional) Add useful resources such as links to documentation, implementation ideas, or best practices.
Story Writing Guidelines
User-Focused Stories
Each story should deliver a complete, valuable capability that users can benefit from independently. Product Managers should avoid breaking stories based on technical layers or implementation convenience.
Standalone Value
Every story should provide value to users even if other related stories are not yet implemented and must clearly answer: “What user problem does this solve?” and “What business outcome does this drive?” Users should be able to accomplish something meaningful from each individual story, with measurable impacts on their experience or business objectives.
In Practice
Feature Breakdown into User Stories
Below is a complete example of a feature breakdown of a Login feature into user stories:
User-Centric Approach
- As a user, I can securely access my account using Facebook authentication
- As a new user, when logging in with Facebook for the first time, I can create my account seamlessly
- As a returning user, when my Facebook login fails, I can understand what went wrong and take appropriate action
Learn more how the Product Managers organize the backlog
User Story Example
Below is a complete example of a feature breakdown of an Order History feature into user stories:
- As a user, I can view my past orders to see what I've ordered before
- As a user, I can reorder my previous order with one tap to quickly get the same meal again
- As a user, I can filter my order history by date range to find specific past orders
- As a user, I can view detailed information about a specific past order to see exactly what I ordered
Example of a user story
As a user, I can view my past orders to see what I've ordered before
## Why
Returning customers want to quickly reference their previous food orders to reorder favorites, or resolve order issues. Without easy access to order history, customers spend time searching through emails or calling restaurants, leading to frustration and potential order abandonment. Order history with reorder functionality reduces friction for repeat purchases and increases customer lifetime value.
## Acceptance Criteria
- Display a chronological list of my last 20 orders, most recent first
- Each order entry shows: order date, restaurant name, order total, and order status
- Show "No orders yet" message when user has no previous orders
- Display order status as: "Delivered", "Cancelled", or "Completed"
- Each order entry is tappable to view more details (handled in separate story)
## Technical Considerations
- Implement efficient database pagination for users with extensive order history
- Cache recent orders locally for offline viewing
- Handle deleted restaurants gracefully by showing restaurant name with "(No longer available)" indicator
- Optimize API queries to retrieve only necessary fields for list view
- Implement pull-to-refresh functionality for updated order statuses
## Resources
- API endpoint specification for retrieving user's last 20 orders with required fields (order_id, date, restaurant_name, total_amount, status)
- Order status mapping documentation ("delivered", "cancelled", "completed" enum values)
- UI mock-up for order list layout
- Analytics tracking specification for measuring user engagement with order history
## Design
[Link to Figma design]
Best Practices
The following guidelines must be followed to avoid common pitfalls:
- DO restrict the Who to a specific user role or type of user
- Do NOT use “As a system” or “As a developer” in story titles
Every story must be from a user perspective. While technical-focused stories might invite Product Managers to formulate user stories from the perspective of a non-application end-user, it is an anti-pattern. In most cases, the feature user stories can be rephrased to focus on the end-user or turned into chores.
As a developer, I can implement the Facebook Login API
As a system, I only reset the employees' leave balances for not expired contacts
As a user, I can log in with Facebook
As an employee, my leave balance is only reset if my contract has not expired
- DO validate that each story delivers meaningful user value
- Do NOT split stories based on technical implementation layers
Before writing a story, ask: “What user problem does this solve?” and “How will we measure success from the user’s perspective?” If you cannot answer these questions clearly, the story needs to be reframed or reconsidered.
- DO collaborate with the development team on implementation approach within user-focused stories
- Do NOT let technical complexity dictate story boundaries
While technical considerations are important, they should be documented within user-focused stories rather than driving how features are broken down. The goal is to deliver complete user value in each story while providing sufficient technical guidance.
Learn more about engineering support in writing user stories