Templates · User story template
Template 6 of 10

User story template

A user story is a slice of an epic that fits in a sprint and delivers something a user can see. Its acceptance criteria are how the team, QA and the product owner agree it's done.

Signed off by:
The product owner
Comes after:
Epic
BO-3-review-unmatched-rows.md
# <KEY>-<n> · <title in the user's words>

**Status:** Ready · **Owner:** <first name or Unassigned> · **Points:** <n> · **Epic:** <epic key>

## Story
As a <user>, I want <capability>, so that <outcome>.

Implements: FR-3, FR-4

## Acceptance criteria
- One testable behaviour per bullet. Given/When/Then when it helps.
- Include the error and edge cases from the PRD and UX spec.

## Notes
Design: <frame or "needs design">. Dependencies: <keys>.

How to fill it in

  • The story line. A real user, a capability, and the outcome they care about. "So that" is the part that tells the developer which trade-offs are fine.
  • Implements. The FR IDs this story covers. Every functional requirement should be covered by at least one story; any that isn't is a gap.
  • Acceptance criteria. One testable behaviour per bullet. Use Given/When/Then when a criterion depends on a starting state. Include the error and edge cases from the PRD and the UX spec, because that's where estimates go wrong.
  • Notes. Link the design frame, or say "needs design". List the stories it depends on by key.

Size

A story fits in a sprint: 8 points or fewer. Split bigger ones by user value (upload a .csv first, .xlsx next), not by layer. A frontend story and a backend story for the same thing deliver nothing on their own.

Acceptance criteria are test cases waiting to happen

QA writes at least one test case per criterion. If you can't imagine the test, the criterion is too vague: "works well with large files" becomes "a 1,000-row file is matched in under 10 seconds".

Common mistakes

  • "As a user, I want the system to…" with no real user.
  • Criteria that restate the story.
  • Only the happy path, so the error states become surprise work mid-sprint.

Example

BO-3 · Review and fix unmatched rows

Status: Ready · Owner: Priya · Points: 5 · Epic: BO-1

Story

As a buyer, I want to fix rows that didn't match a product before they reach my cart, so that my order has exactly what I meant to buy.

Implements: FR-2, FR-3

Acceptance criteria

  • Given an upload with unmatched rows, when matching finishes, those rows are listed first, each with up to 3 suggestions.
  • Picking a suggestion moves the row to matched.
  • A row can be dropped; dropped rows are never added.
  • Add to cart stays disabled while any row needs attention, and says how many.
  • When no suggestion fits, the buyer can type a SKU; an unknown SKU shows "No product with SKU 4471-B".

Notes

Design: Review screen frame. Dependencies: BO-2.

Have Releavo write the user story

In Releavo this lives at planning/stories/BO-3-review-unmatched-rows.story. Releavo drafts it from the docs before it and your team's conversations; every edit is a draft until the product owner approves it, and approved versions are never overwritten.