nimblehq.co

Features

Hero image for Features

Being an engineering-focused company, Product Managers write small, detailed feature user stories. Each user story belongs to a feature and targets the delivery of a specific area of implementation.

Principles

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.

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.

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.

Web

  • UI

    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.

  • Backend

    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

    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.

    When building an API application, splitting user stories into backend and API can be considered when it enables the team to deliver the feature in an iterative process. For instance, some features might require complex business logic. Thus, separating the business logic from the API implementation can help the team deliver in smaller increments (i.e., smaller pull requests).

Mobile

  • UI

    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

    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

    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.

Core Components

Product Managers construct user stories with three core components: Who, When, and What.

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.

When can be omitted if a condition does not trigger the expected functionality, i.e., the functionality is always available.

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:

[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)

Commonly used action verbs are: view, create, update, delete, search, filter, sort, etc.

Description

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.

The Why is generally documented at the feature level as the idea behind one user story is shared between all related user stories for a feature. The goal is to avoid repetitive user story descriptions, as it can lead to user stories not being concise enough, thus hindering the understanding of the feature as a whole.

However, if a user story has a specific reason or a reason that differs from the feature-level definition, the Why can be documented in the user story description.

In Practice

Feature Breakdown into User Stories

Below is a complete example of a feature breakdown of a Login feature into user stories:

Mobile

  • [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

Web

  • [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

Learn more how the Product Managers organize the backlog

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

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

👉 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.

Learn more about engineering support in writing user stories