User Stories

8 min read

User Stories

A short sentence that captures who needs something, what they need, and why — written from the user’s perspective, not the developer’s.

What is a user story?

A user story is the smallest unit of work that delivers value to a real person.1 It’s not a technical specification. It’s not a task list. It’s a one-sentence description of what someone wants to accomplish and why it matters to them.

The format is always the same:1

As a [who], I want [what], so that [why].

For example:

As a citizen, I want to see which democratic instruments
apply to my problem, so that I know how to act.

That’s it. One sentence. The power is in the constraint — by forcing everything into this structure, you’re forced to answer three questions you might otherwise skip: who is this for?, what do they actually need?, and why does it matter?

In plain terms

A user story is like a wish on a sticky note. Someone writes down what they need in plain language, sticks it on a board, and the team figures out how to make it happen. The sticky note doesn’t say how — it says what and why.

At a glance

How do user stories work?

The three Cs

Every user story follows a pattern called the 3 Cs, introduced by Ron Jeffries:2

CWhat it isExample
CardThe written story itself — short enough to fit on a sticky note”As a citizen, I want to see which instruments apply…”
ConversationThe discussion the team has about it — this is where the real detail lives”What happens if multiple instruments apply? Do we rank them?”
ConfirmationThe acceptance criteria — testable conditions that prove the story is done”Given a housing problem, the system shows at least petition and motion”

The story is a placeholder for a conversation

The sticky note is not the requirement. The conversation about the sticky note is the requirement. The card exists to trigger a discussion, not to replace one.1

The format

As a [persona], I want [goal], so that [benefit].

Each part answers a specific question:

PartQuestionBad exampleGood example
As aWho is this for?”As a user” (too vague)“As a first-time voter under 25”
I wantWhat do they need?”I want a good interface” (not actionable)“I want to see which instruments apply to my problem”
So thatWhy does it matter?(often missing entirely)“so that I know how to take action”

The most common mistake

Skipping the “so that” clause. Without the why, the team builds features without understanding purpose. A story without a benefit is a task, not a story.1

INVEST criteria

Good user stories follow the INVEST checklist:3

LetterMeansWhy it matters
IIndependentCan be built without depending on other stories
NNegotiableDetails can be discussed and refined
VValuableDelivers something useful to the user
EEstimableThe team can roughly size the effort
SSmallFits within one sprint (1-2 weeks of work)
TTestableHas clear criteria for “done”

Think of it like...

Ordering dishes at a restaurant. Each dish (story) should be independent (you don’t need the starter to eat the main), valuable (worth ordering), small enough to arrive in a reasonable time, and testable (you’ll know if it’s what you ordered when it arrives). If a dish is too complex, you split it into courses.

Acceptance criteria

Every story needs acceptance criteria — specific, testable conditions that define when the story is complete.1

Story: As a citizen, I want to see which democratic instruments
apply to my problem, so that I know how to act.

Acceptance criteria:
- Given a housing-related problem, the system shows at least
  petition and motion as options
- Each instrument shows: name, requirements, timeline, and
  a one-line description
- If no instrument matches, the system says so explicitly
  (not an empty page)
- Results load within 3 seconds

Concept to explore

See acceptance-criteria for how to write criteria that are testable, complete, and unambiguous.

Why do we use user stories?

Four reasons

1. They keep the user visible. It’s easy for a development team to lose sight of who they’re building for. The “As a…” format forces every piece of work to name a real person with a real need.1

2. They invite conversation. Unlike a 50-page spec that nobody reads, a sticky note demands discussion. The team talks about what the story means, what’s in scope, and what’s not.2

3. They’re the right size for iteration. A story is small enough to build in a sprint, test with users, and learn from. This fits naturally with iterative-development and vertical-slices.3

4. They separate what from how. The story says what the user needs. The team decides how to build it. This gives developers creative freedom while keeping the outcome fixed.

When do we use user stories?

  • When breaking a prd into buildable pieces
  • When planning a sprint or iteration
  • When a feature is too big to build at once — split it into stories
  • When communicating requirements between non-technical stakeholders and developers
  • When using AI to build — each story becomes a clear, bounded instruction

Rule of thumb

If you can’t describe a piece of work as something a specific person wants for a specific reason, it’s probably a technical task, not a user story. Both are valid — but they serve different purposes.

How can I think about user stories?

The restaurant order

A user story is a customer’s order at a restaurant. The customer says what they want (“the salmon, medium-rare, no sauce”) and why (“I’m allergic to dairy”). They don’t tell the kitchen how to cook it — that’s the chef’s expertise.

  • “As a” = the customer’s dietary profile
  • “I want” = the dish they’re ordering
  • “So that” = why this matters to them
  • Acceptance criteria = “medium-rare, no sauce, served within 20 minutes”
  • Conversation = the waiter asking “would you like a side with that?”

The travel itinerary

A user story is a single stop on a trip. Your overall holiday plan is the epic. Each stop (visit the museum, hike the trail, eat at the local restaurant) is a story — small enough to do in one day, valuable on its own, and independent of the other stops.

If a stop is too ambitious (“explore the entire city”), you split it: “visit the old town,” “see the waterfront,” “eat at the market.” Each is now small, estimable, and testable (“I’ll know I’m done when I’ve taken photos at the market”).

Concepts to explore next

ConceptWhat it coversStatus
acceptance-criteriaHow to define “done” with testable conditionscomplete
epicsLarge features that contain multiple user storiesstub

Some of these cards don't exist yet

They’ll be created as the knowledge system grows. A broken link is a placeholder for future learning, not an error.

Check your understanding

Where this concept fits

Position in the knowledge graph 

graph TD
    PR[Product Requirements] --> PRD[PRD]
    PRD --> US[User Stories]
    PRD --> SM[Scope Management]
    US --> AC[Acceptance Criteria]
    US --> EP[Epics]
    US -.->|maps to| VS[Vertical Slices]
    US -.->|drives| ID[Iterative Development]
    style US fill:#4a9ede,color:#fff

Related concepts:

  • technical-specification — turns user stories into precise system behaviour (the story says what, the spec says how exactly)
  • vertical-slices — each story naturally maps to a slice that touches every layer (UI, API, database)
  • iterative-development — stories are the unit of iteration: build one, test it, learn, build the next

Sources

Further reading

Resources

Footnotes

  1. Parallel. (2026). How to Write User Stories: 2026 Guide. Parallel. ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  2. UserVoice. (2026). A Step-by-Step Guide to Creating User Stories. UserVoice. ↩ ↩2

  3. Agilemania. (2025). What Is a User Story? Definition, Types & Examples. Agilemania. ↩ ↩2

Graph View

Backlinks