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

If the story is clear but the team still argues about what to ship, use the free UI Decision Brief to pin down the decision, constraints, and success check before development starts.

Related Terms

Related Articles