PWPM Wiki
🎯 Scope, Requirements & WBS🔁 Agile, Scrum & Product

User Story

A user story is a short, plain-language description of a feature told from the user’s perspective — "As a [user], I want [goal] so that [benefit]" — designed to spark a conversation, not to be a full specification.

A user story is a lightweight requirement expressed in the user’s voice, capturing who wants something, what they want, and why. The classic template is "As a [type of user], I want [some goal] so that [some reason]." A story is intentionally small and non-exhaustive; its purpose is to represent a unit of value and to trigger a conversation between the team and the customer that fills in the detail. Good stories follow the INVEST guideline — Independent, Negotiable, Valuable, Estimable, Small, Testable — and carry acceptance criteria that define when they are done.

User Story at a glance

Category
Scope, Requirements & WBS · Agile, Scrum & Product
Type
Concept
Appears in
2 sections
Related
Requirements Traceability Matrix, User Story Mapping, Requirements Traceability

Why it matters

User stories keep requirements focused on user value rather than technical tasks, and their small size makes work estimable, prioritisable and shippable in a single iteration. By deferring detail to a conversation, they avoid the waste of exhaustively specifying features that may change or be cut. The "so that" clause keeps everyone honest about why a feature exists, which helps the team make good trade-offs.

When to use it

Use user stories in Agile delivery to express backlog items that deliver user-facing value. They fit software and product work especially well. For non-user-facing work (infrastructure, compliance) teams often use technical stories or a different format, and for very large items an epic is split into multiple stories.

How to use it

  1. Write the story in the user’s voice: As a [user], I want [goal] so that [benefit].
  2. Check it against INVEST — especially that it is small and independently valuable.
  3. Add acceptance criteria describing the conditions for "done".
  4. Split stories that are too large to finish in one sprint into smaller ones.
  5. Refine and estimate the story with the team before it enters a sprint.

Example

"As a returning customer, I want to save my delivery address so that I don’t have to re-enter it each time." Acceptance criteria: a logged-in user can save one or more addresses; a saved address auto-fills at checkout; the user can edit or delete a saved address.

Template

A user-story template captures the role/goal/benefit sentence plus acceptance criteria and a definition of ready; keep them on cards in the backlog tool.

Browse templates →

Tools

JiraAzure DevOpsLinearTrello

Formula

As a [user], I want [goal], so that [benefit]

FAQs

What is the difference between an epic and a user story?
An epic is a large body of work that is too big for one sprint and is broken down into multiple user stories. A user story is small enough to complete within a single iteration.
What does INVEST stand for?
Independent, Negotiable, Valuable, Estimable, Small, Testable — a checklist for whether a user story is well-formed.
Are acceptance criteria part of the user story?
Yes — the story sentence states the intent; acceptance criteria define the specific, testable conditions that must be true for it to be considered done.

Alternatives

  • Use case — a more detailed, step-by-step interaction description
  • Job story — "When [situation], I want [motivation], so I can [outcome]"
  • Traditional requirement statement — "The system shall…"