# User story

> **What this teaches:** I can turn a user need into one small, testable slice without prescribing the implementation too early.

Before writing, predict the smallest observable value the user needs. After writing, ask whether two independent readers would test the same behavior.

## User need

Name who benefits, the capability they need, and the value—not a technology you want to use.

As a **[specific user]**, I want **[small capability]** so that **[observable value]**.

## Context

Give only the facts needed to understand the current problem. This teaches scope and privacy discipline.

[What problem exists now? Include only sanitized information.]

## Clarifying questions

Ask about ambiguity that could change behavior, boundaries, or acceptance. Do not hide an assumption in the implementation.

1. [Question]
2. [Question]
3. [Question]

## Acceptance criteria

Each criterion is an observable example of done. Include a normal path and a relevant boundary or failure path.

- [ ] Given **[starting state]**, when **[action]**, then **[observable result]**.
- [ ] Given **[boundary or error state]**, when **[action]**, then **[observable result]**.
- [ ] [Security, privacy, accessibility, or performance criterion relevant to this slice.]

## Non-goals

State what this slice deliberately excludes so “small” remains enforceable during the Sprint.

- [What this story deliberately does not include.]

## Evidence

Link the need to the reviewed change and its test or demonstration result.

- Issue:
- Pull request:
- Test/CI run:
- Demo or explain-back:

## Explain it back

Explain the user value, one rejected interpretation, and how each acceptance criterion could be observed without reading the implementation.