← Go Back

User Stories

What are user stories?

A user story is a short, simple description of a feature from the user’s perspective: who wants it, what they want, and why. It’s a placeholder for a conversation and for acceptance criteria, not a full specification.

Use it when: you’re turning user needs or problem statements into deliverable backlog items that the team can estimate, build, and test.

Copy/paste template

As a [user type], I want [goal/capability] so that [benefit/value].

Example: “As a returning customer, I want to log in quickly so that I can access my account without re-entering my details.”

Add acceptance criteria (bulleted, testable) so “done” is clear.

Why user stories matter

  • Keep the focus on user value instead of technical tasks.
  • Give the team a shared, readable format for requirements.
  • Support prioritisation and estimation because each story is a small unit of value.
  • Encourage conversation (the “so that” invites questions and refinement).

What a good user story includes

Checklist (INVEST)

  • [ ] Independent: can be built and shipped without depending on another story.
  • [ ] Negotiable: detail is discussed, not fixed in stone upfront.
  • [ ] Valuable: delivers value to a user or the business.
  • [ ] Estimable: the team can size it.
  • [ ] Small: completable in one iteration; slice if too big.
  • [ ] Testable: acceptance criteria make it clear when it’s done.

Common formats

  • Standard: As a [user], I want [goal] so that [benefit]. Use this by default.
  • Job story: When [situation], I want to [motivation] so I can [outcome]. Use when context matters more than persona (see Jobs to be done).

Examples

Example (the realistic one)

Story: “As a project manager, I want to assign tasks to team members so that work is distributed and everyone knows what they own.”
Acceptance criteria: User can select a task and choose an assignee from the team list; assignee is visible on the task and in their view; reassignment is possible.

Common pitfalls

  • Too technical: the story describes the implementation, not the user goal. → Do this instead: write from the user’s perspective; move technical detail to acceptance criteria or tasks.
  • Too vague: “I want a better experience” could mean anything. → Do this instead: name the specific capability and the benefit.
  • Missing “so that”: the value is unclear. → Do this instead: always include the benefit; if you can’t, question whether the story is needed.
  • Too large: the story spans multiple flows or weeks. → Do this instead: split by user outcome or by step in the flow.
  • No acceptance criteria: “done” is disputed. → Do this instead: add 2–5 testable criteria before development.
  • User story vs job story: user story = As a / I want / so that (persona-first). Job story = When / I want to / so I can (context-first). Use job stories for discovery; user stories for the backlog.
  • User story vs problem statement: a problem statement describes what’s broken for whom; a user story describes a capability you’ll deliver. Problem first, then stories that address it.
  • User story vs acceptance criteria: the story is the one-liner; acceptance criteria are the testable conditions for “done”.

Next step

Take one problem statement or feature idea and write it as a user story with 2–3 acceptance criteria. If you’re unsure who the user is, read Persona or Jobs to be done.

Related Terms