User Stories/Features

Hero image for User Stories/Features

As an engineering-focused company, our Product Managers write very small and detailed user stories. Each user story should be bite-sized. It must cover the smallest possible area, and there must be one user story for each implementation level (e.g., backend and frontend).

Key Components

User stories are a medium for Product Managers to translate their product vision into actionable tasks for developers. A good user story must be concise and clear. It must also be ready for pick-up taking into account all of the following three aspects.

Rationale Behind a Story

There is always a reason behind each user story. It is crucial to provide enough information for developers to understand the idea of a story. When a user story is well-understood, it will give developers a good platform to work their magic on the implementation with the same goal in mind.

There are times when it might feel trivial or unnecessary to write down why we need the user story (even a short explanation) when things feel obvious for Product Managers who are already familiar with the topic. However, providing context will always give value to developers who are not aware of the whole picture, unlike the PMs.

Clear Definition of Done

A common ground for how a user story will be tested and accepted by Product Managers. Product Managers must make the acceptance criteria crystal clear. It is understood that, if the acceptance criteria are not met, the user story will be rejected.

Developers are different individuals with different backgrounds. An unclear Definition of Done can yield different results.

Consequently, an unclear Definition of Done would lead to an inefficient and preventable back-and-forth on a user story.

Implementational Resources

When writing user stories, Product Managers must already have a clear vision of how all the pieces will fit in together in the grand scheme. Oftentimes, it includes thorough research, UX/UI walkthroughs, product discussions, documentation, etc.

With all the information gathered by the Product Manager shared in the user story, developers can save time and hit the ground running as soon as they pick it up.

Who, When, What, Why, and How

With all the aforementioned aspects considered, we can construct our user stories with the five pieces Who, When, What, Why, and How.

  • Who: A user role to indicate who the user of the user story is.
    • a user, an admin, a visitor, a patient, etc.
  • When: A condition for the user story. It can be left out if the user story applies with no conditions.
    • when the account balance is empty
    • if the camera permission is declined
    • when the server is under maintenance
  • What: An action of the user story.
    • make a purchase, retry the attempt, register an account, create a blog post, etc.
  • Why: The idea of the user story; what it will solve or what value it will add to end-users.
  • How: How the user story will be tested. What the key factors are for Product Managers to accept or reject it.

Let’s take a look at an example below:

[Integrate] As a user, when signing in with Facebook for the first time, I can register an account

At a glance, the developers will get the idea of Who (a user), When (when signing in with Facebook), and What (register an account).

While there are some practices to put Why in the user story title, we, at Nimble, put it in the user story description. Having long dull user story names that are not concise enough will hinder the understanding of the feature as a whole that Product Managers communicate with the developers.

Then, in the user story description, they put in the rationale behind the user story as why we are going to implement it and how we can validate that it meets the expectations. It is also important to point out that when a user story is UI/UX-related, it should include the Design section, where we put in:

  • A Figma link to the UI component/page
  • Screenshots of the design with visual highlights of what needs to be implemented and what should not be implemented. The benefits of having screenshots are:
    • To help developers clearly visualize the area(s) of focus,
    • To serve as a history log of what was done in the user story. As the application evolves, so does the design.

Areas of Implementation

Our user stories are small. They also cover a very specific and targeted area of implementation which is representative of the actual work that developers have to do on a day-to-day basis.

Writing the user stories this way has multiple benefits:

  • It represents the actual work that developers do,
  • It encourages developers to think more thoroughly about the task at hand (and estimate more accurately),
  • It pushes the Product Manager to understand how things work technically, and to formulate the user stories in a way that developers will quickly understand.

The areas of implementation vary depending on the platform.

Web

  • UI: covers the application UI and UX. 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, debounce a search input field, etc.
  • Backend: covers the business logic of the application. As web projects usually have a clear line between frontend and backend, Backend user stories are those implemented on server side.
    • E.g., server-side validation to check if a room is available, data handling logic, call an external API endpoint to book a flight, etc.
  • API: covers the API part for projects where the backend and the API are separate layers.
    • E.g., REST request implementation, GraphQL request implementation, etc.

Mobile

  • UI: covers the application UI and UX. It is an area where a developer implements UI/UX without manipulating any data from the backend side. UI user stories can be implemented without dependencies of the backend team.
    • E.g., UI implementation, local validation of an input field, simple UI navigation, etc.
  • Integrate: covers a part where the UI connects with the backend. It is a bridge between the visual and the backend data.
    • E.g., C2A of an API request, data handling logic, validation at the API level, conditionally display a mapped error message, etc.
  • Backend: covers 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, data fetching from a local database, response mapping, etc.

Feature Breakdown Example

Epic: Sign In with Facebook
Labels: #authentication @1.2.0

Check out how we organize our backlog

Mobile (iOS)

  • [UI] As a user, I can sign in with Facebook
  • [Integrate] As a user, I can sign in with Facebook
  • [Backend] As a user, I can sign in with Facebook
  • [Integrate] As a user, when signing in with Facebook for the first time, I can register an account
  • [Backend] As a user, when signing in with Facebook for the first time, I can register an account

Mobile (Android)

  • [UI] As a user, I can sign in with Facebook
  • [Integrate] As a user, I can sign in with Facebook
  • [Backend] As a user, I can sign in with Facebook
  • [Integrate] As a user, when signing in with Facebook for the first time, I can register an account
  • [Backend] As a user, when signing in with Facebook for the first time, I can register an account

Web

  • [API] As a user, I can sign in with Facebook
  • [API] As a user, when signing in with Facebook for the first time with an existing email, I can connect my account with Facebook

Estimations

Guide to estimating user stories

User Story Template

Title

[UI/Integrate/Backend] As a (Who), (When), I (can/must) (do What)

[UI/Integrate/Backend] As a (Who), I (can/must) (do What) (When)

Description

## Why

Describe the idea of the user story as in what the motive of the user story is.

## Acceptance Criteria

List down how the user story will be tested 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.

Usage Example

## Why

As the majority of our leads come from Facebook, it is important for the mobile apps to allow users to sign in with Facebook to convert more leads into our user base.

When a user signs in with Facebook and hasn't registered an account yet, we will navigate the user to the Create Account screen with the pre-filled information returned by Facebook.

## Acceptance Criteria

When calling the login endpoint with Facebook token returns 404 error code,
- Navigate the user to Create Account with the response returned by Facebook

## Design

![highlighted-screenshot](https://i.imgur.com/hh8ymnc.png)

https://www.figma.com/file/GjRPOjDyZ6f4EDL3wKarRK/Challenge-Mobile-App?node-id=34%3A1450

## Resources

- [Facebook Login - Technical Best Practices](https://developers.facebook.com/docs/facebook-login/best-practices#technical-practices)
- [Facebook Login for iOS](https://developers.facebook.com/docs/facebook-login/ios)