Feature user stories allow Product Managers to translate their product vision into actionable developer tasks and subsequent value for the end users.
A good user story must be concise and clear. It must also be ready for pick-up considering the following two aspects.
Clear Definition of Done
Product Managers must define a common ground for how a user story will be tested and validated. The user story’s acceptance criteria represent the Definition of Done for the user story.
The acceptance criteria must be crystal clear; there must be no room for interpretation. An unclear Definition of Done can yield different results and inefficient, preventable back-and-forth on a user story.
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.
Areas of Implementation
Each user story targets a particular area of implementation for the following purposes:
- Push the Product Manager to understand how things work technically and formulate the user stories to deliver features in an iterative process.
- Allow developers to estimate more accurately. The smaller the surface of implementation, the more accurate the estimation.
The areas of implementation vary depending on the platform.
UI user stories cover the application’s UX and UI. It is the client-side implementation to handle workloads on a user’s web browser, e.g., UI implementation, local validation of an input field, static UI navigation, the behavior of a search input field, etc.
Web projects usually have a clear line between frontend and backend. Backend user stories cover the business logic of the application and are implemented on the server side, e.g., server-side validation to check if a room is available, data handling logic, calling an external API endpoint to book a flight, etc.
API user stories cover the API part for projects when the backend and the API are separate layers, e.g., REST or GraphQL request implementation, API authentication, etc.
UI user stories cover the application UI and UX. It is an area where the visual is implemented without relying on any data source, i.e., it is a static visual only, e.g., UI implementation, local validation of an input field, simple UI navigation, etc.
Backend user stories cover data fetching – which can be either from the APIs or other sources, such as local databases – and data manipulation, e.g., an API request to the backend, an API request to a third-party service, data fetching from a local database, response mapping, etc.
Integrate user stories cover the part where the UI connects with the backend. It is a bridge between the visual and the backend data, e.g., call-to-action of an API request, data handling logic, validation at the API level, conditional display of a mapped error message, etc.
Product Managers construct user stories with three core components: Who, When, and What.
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.).
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.
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
The user story’s title comprises the Who, When, and What components.
The following alternative formats must be used:
[UI/Integrate/Backend] As a (Who), (When), I (can/must) (action verb) (What)
[UI/Integrate/Backend] As a (Who), I (can/must) (action verb) (What) (When)
The user story’s description mainly comprises the What component and, optionally, the Why.
## Why (Optional) 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. ## 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.
Feature Breakdown into User Stories
Below is a complete example of a feature breakdown of a Login feature into user stories:
- [UI] As a user, I can log in with Facebook
- [Integrate] As a user, I can log in with Facebook
- [Backend] As a user, I can log in with Facebook
- [Integrate] As a user, when logging in with Facebook for the first time, I can register an account
- [Backend] As a user, when logging in with Facebook for the first time, I can register an account
- [API] As a user, I can log in with Facebook
- [API] As a user, when logging in with Facebook for the first time with an existing email, I can connect my account with Facebook
User Story Example
Below is a complete example of a UI user story:
[UI] As a user, I can log in with Facebook
## Acceptance Criteria - Show the "Continue with Facebook" button on the login screen. - When clicked, the button triggers the Facebook Login OAuth flow. - Do NOT implement the redirection to the application as this will be done in [[Integrate] As a user, I can log in with Facebook](link to the integrate user story) - If Facebook returns an error, navigate the user back to the login screen and display the error message sent by Facebook. ## Design ![highlighted-screenshot](https://i.imgur.com/hh8ymnc.png) https://www.figma.com/file/GjRPOjDyZ6f4EDL3wKarRK/Challenge-Mobile-App?node-id=34%3A1450
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
👉 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.
[Backend] As a developer, I can implement the Facebook Login API [Backend] As a system, I only reset the employees' leave balances for not expired contacts
[Backend] As a user, I can log in with Facebook [Backend] As an employee, my leave balance is only reset if my contract has not expired
- DO get feedback from the development team on the feature breakdown into user stories
- Do NOT break down features into too many stories if it slows down the development process
👉 While breaking down features into small stories targeting one of the commonly defined areas of implementation is usually the right approach, in some instances, due to the feature or stack, it might be more efficient to break down the feature into fewer user stories. The goal is to find the right balance between the number of user stories and the development process.
For example, if a feature is simple enough on a specific stack, it can be broken down into one user story. A standard indicator of inefficient user story breakdown is the estimation by developers of some stories to zero points.