nimblehq.co

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.

Note that the rationale for a user story is detailed at the feature level (every user story must belong to a feature).

Writing a feature’s why

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, Product Managers can construct our user stories with the four pieces Who, When, What, 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.
  • How: How the user story will be tested. What the key factors are for Product Managers to accept or reject it.

Each user story must belong to a feature, and each feature must detail the “why”:

  • Why: The idea behind the feature; what it will solve or what value it will add to end-users.

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, Product Managers at Nimble put it in the feature 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, Product Managers define how the team 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 including the following:

  • 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 Product Managers organize their 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

## 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

Feature

Starting at the feature level Product Managers need to detail the “why” and outline the context of the feature.

Feature: User can authenticate with Facebook

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

To make this happen, we need to integrate Facebook Login which means:

- Setting up a Facebook application
- Loading up the Facebook SDK
- Configuring the "Login with Facebook" feature in each app
- Implementing the necessary UI in the apps, including the error states

Keep in mind that Facebook will only be _one_ of the possible ways a user can "continue" (i.e., register or log into the application).

## Documentation

- Feature documentation: https://www.notion.so/nimblehq/feature-documentation-link
- Facebook Login documentation: https://developers.facebook.com/docs/facebook-login/
- Facebook Login - Technical Best Practices: https://developers.facebook.com/docs/facebook-login/best-practices#technical-practices

User Story

[UI] As a user, I can log in with Facebook

This story would belong to the feature “User can authenticate with Facebook.”

## Acceptance Criteria

- Show the "Continue with Facebook" button on the login screen
- When clicked, the button will trigger the Facebook Login flow (detailed in the integrate 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