# Backlogs and User Stories Write value-bearing user stories and distinguish acceptance criteria from the Definition of Done. Duration: 12 min Use the words “so that” to connect backlog work to a real benefit. Treat a story as Card, Conversation, and Confirmation—not as a card-sized contract. ## fmap-m3-l2-v1 The restored approved narration and storyboard are retained in the source pack. This placeholder does not activate media or publication. ## fmap-m3-l2-digest ### Backlogs and user stories The Product Backlog is a **single, ordered, living** list. Single means one source of choices. Ordered means it has a real top. Living means evidence can change it; a frozen backlog is a requirements document wearing agile vocabulary. A common story pattern is: **As a [type of user], I want [goal], so that [benefit].** The “so that” is the outcome link. If it merely repeats the feature—“I want a form so that I can fill in a form”—the item is an output in disguise. Ask what the author hoped would change. The three Cs explain what a story is: - **Card:** a deliberately small placeholder, not a full specification. - **Conversation:** the detail and shared understanding discovered by talking. - **Confirmation:** concrete checks that show whether this story is right. Those checks are its **acceptance criteria**. They belong to one item. The **Definition of Done** is the shared quality bar that applies to every item. Acceptance criteria ask whether the team built the right thing; the Definition of Done asks whether it built the thing right. Both must be satisfied. An **epic** is simply too large to work on safely and should be split. Story quality mnemonics such as INVEST can help, but the practical test is shorter: is the story small, valuable, and clear enough to trigger a useful conversation? Stories are not tasks in costume. Their value comes from naming who benefits and what changes for that person. ## fmap-m3-l2-i1 The same cases and explanations are available in the text digest for learners who do not use the controls.