Writing User Stories

Hero image for Writing User Stories


The Product Manager is responsible for writing user stories of all types.

However, there are times where the developers’ input might be necessary. For example, if the developers identify a chore that is necessary to implement a feature, developers should often be responsible for writing that chore.

Developers must seek the Product Manager’s approval before adding, moving, or removing user stories in the backlog. The Product Manager is the only person owning the backlog. Read more about product backlog ownership on our blog.

Product Backlog Ownership — Why It Matters

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


For web projects, there are at least two implementation levels and sometimes more.

  • Backend: where the business logic gets implemented.
  • UI: where the UI and UX get implemented.
  • API: for projects where the backend and the API are separate layers.


  • UI: where the application UI and UX get implemented.
  • Backend: where the connection to the APIs and data fetching gets implemented.
  • Integration: where the UI connects with the backend.


For example, we will be using Nimble’s Survey app, which we use for internal certifications. Let’s also focus on the login part exclusively to keep it short.

Pivotal Tracker workspace showing the demo Survey apps backlog for web and iOS.

Pivotal Tracker workspace showing the demo Survey apps backlog for web and iOS.


Guide to estimating user stories


Bug-free software does not exist. It is unrealistic to expect no bugs in an application. However, it is essential to properly document bugs when found so that the Engineering team can identify them and fix them quickly.

Four key pieces of information are required when reporting bugs:

  • Environment, to narrow down the conditions under which developers can reproduce the bug.
  • Steps to reproduce, to let the developers know how to see the bug occurring.

Bugs reported without steps to reproduce are extremely difficult to identify and fix. It will slow the Engineering team down considerably.

  • Expected outcome/behavior, to clarify what is considered the functioning feature.
  • Actual outcome/behavior, to detail when is happening but should not be happening.


Product Managers and stakeholders are strongly encouraged to attach materials to help with the investigation work: screenshots, screencasts, references to similar or related issues, etc.

Bug Template

# Environment

- Platform: web/Android/iOS
- Device: e.g., iPhone 10
- OS: e.g., iOS 13
- Version: e.g., 0.12.0 (519)
- Environment: staging/production

# Prerequisites

Specify if there are specific conditions that must be met to recreate the issue. For example:

Use an account with no chat history / The app must be freshly launched / Launch the app from the already signed-in state with an account registered with mobile no.

# Steps to Reproduce

1. X
2. X
3. X

# Expected

Describe the expected outcome. Add screenshots if possible.

# Actual

Describe the actual behavior. Add screenshots and screencasts.