Skip to content
Back to Architecture Decisions

User Story Format

The 'As a X, I want Y, so that Z' format and when to use it vs. job-stories.

Why

The user story format forces the writer to name the user, the need, and the value — in that order. The 'so that' clause is the part that prevents feature-factory behavior: if you can't articulate the value, the feature probably isn't worth building. The format also makes estimation easier because each story is a unit of user-visible behavior, not a unit of engineering work. Teams that write stories without the 'so that' clause routinely ship features that work but solve no measurable problem.

When

When decomposing a PRD into buildable units. Takes 5 min per story. Use job-stories instead when the 'user' is a system or the value is emotional.

How

1. Start: "As a [specific user role]"
   - Not "As a user" — name the role (admin, guest, billing-owner)
2. Need: "I want [observable capability]"
   - Must be something the user can see or do, not an implementation detail
3. Value: "so that [measurable outcome]"
   - If you can't fill this, the story isn't ready — go back to the PRD
4. Add acceptance criteria as a sub-list (Given/When/Then or bullet points)
5. Estimate only after the story has acceptance criteria — no criteria = no estimate

Example

✓ As a billing-owner, I want to download a CSV of all invoices
  so that I can reconcile with my accounting software.
  Acceptance:
  - Given 50 invoices, the CSV downloads in < 3s
  - CSV columns match the QuickBooks import schema

✗ As a user, I want a dashboard.
  (No role specificity, no value, no acceptance criteria — not a story)

Common Problems

  • ⚠Writing 'As a user' for every story — the role matters because an admin's need and a guest's need are different features.
  • ⚠Putting implementation in the need clause ('I want a Redis cache') — the story should describe what the user gets, not how you build it.

Best Practices

  • ✓Write the 'so that' clause first, then work backwards — starting with value prevents solution-in-search-of-problem stories.
  • ✓Keep stories small enough to finish in one sprint; if a story spans 3 sprints, it's an epic and needs decomposition.

Related Resources