This user story template connects a role, goal, and benefit with the conversation and examples behind it. Split a broad feature into smaller outcomes that still give the user something useful.
Start with the visitor's goal
The original fictional club event-board goal is to help visitors find a relevant upcoming event. Two proposed story slices are:
| Story | Role, goal, and benefit |
|---|---|
| S1 | As a visitor, I want to see upcoming published events in date order so I can choose an available session. |
| S2 | As a visitor, I want to filter that usable list by topic so I can narrow the sessions relevant to me. |
S1 provides a list the visitor can use without a topic filter. S2 builds on that useful list with another outcome. Keeping the filter for a later story lets the team discuss the first increment on its own terms.
The Agile Alliance user-stories glossary describes stories as value-bearing functional increments and cautions against equating them with technical or interface components. It also emphasizes the knowledge behind the card, not just its sentence. The event-board example here is original.
Keep implementation tasks separate from the story
Choose Compare splits in the example:
| Proposed technical split | Outcome-oriented split |
|---|---|
| Build the database table. | S1: the visitor can use the upcoming published-event list. |
| Build the API. | S2: the visitor can narrow that list by topic. |
| Style the event cards. | Supporting implementation tasks belong under the relevant story. |
The technical tasks still matter. Their completion should be connected to an outcome rather than mistaken for evidence that the visitor's goal is already met.
Select S1 and ask whether a visitor could benefit if the team stopped after delivering it. Then inspect S2's additional scope. This question helps expose a slice that is only a hidden technical layer.
Use a small example to make S1 concrete
The teaching fixture has an as-of date of November 1:
| Record | Event | Date and supplied state |
|---|---|---|
| E1 | Drawing | November 4; published. |
| E2 | Coding | November 6; published. |
| E3 | Clay | October 1; past. |
For this agreed example, the upcoming published-event list should contain E1, then E2, and exclude E3. That gives the team a concrete confirmation example for S1.
The fixture does not settle every date rule. Ask how the product handles time zones, events spanning multiple dates, and the precise boundary for an event ending today. Keep those questions in the conversation instead of silently turning one small example into a complete specification.
Topic values and filter rules still need definition for S2. The event names in this fixture should not be treated as a complete topic taxonomy.
Put the conversation behind the card
A usable story record includes:
| Area | What to retain |
|---|---|
| Card | Role, goal, and benefit. |
| Conversation | Context, assumptions, open questions, and who can clarify them. |
| Confirmation | Specific examples and acceptance expectations the team has agreed. |
| Boundary | What the current slice includes and what remains for later work. |
For S1, retain the November 1 fixture and expected list beside the sentence. Leave the conversation owner open until assigned. The example does not invent story points, delivery commitments, or completed software.
The blank template helps assemble a story from role, goal, benefit, questions, and examples. It does not score the quality of arbitrary story wording automatically.
Prepare a story for your own product
Create one complete, self-contained HTML user-story working record.
User role and broad goal: [DESCRIBE]
Proposed role/goal/benefit story sentence: [PASTE]
Current product context and assumptions: [PASTE]
Smaller useful outcome slices: [PASTE]
Supporting technical tasks: [PASTE]
Concrete acceptance examples with exact fixture and expected outcome: [PASTE]
Open conversation questions and owner, if known: [PASTE]
Included scope and later work: [PASTE]
Show card, conversation, confirmation examples, and boundaries together.
Compare technical-layer tasks with user-valued slices without pretending
the supporting tasks are unnecessary. Let a reader select each story
to inspect its usable increment and the scope left for later.
Keep supplied fixtures and expected results intact. Mark unresolved
boundary rules as questions rather than inventing agreement. Do not
fabricate points, commitments, delivered software, or test results.
Include a blank role/goal/benefit record with context, questions, and
example fields. Name missing user, goal, or benefit before building a
review copy. Preserve temporary notes across views, mark old output
stale after edits, and ask before resetting. No automatic story quality
score, project integration, or claimed saved planning record.
Use text of at least 16px, labeled keyboard-accessible controls, and
a layout readable at 360px without horizontal scrolling. Put CSS and
JavaScript inline with no external dependencies. Return complete HTML.
Keep the first slice small enough to discuss
Before planning implementation, ask the product owner and developers to walk through E1, E2, and E3 together. Record which rules the example establishes and which questions still need answers.
In an HTML story record in NOS, you can edit the visible story and its boundary together. If “filter by topic” has crept into S1, move that scope back to S2 while retaining the useful first list. The next planning conversation can then focus on one deliverable outcome.