User story template, with examples that are actually buildable
The format, ten examples, the INVEST checklist, and the step most templates stop before: turning a story into requirements someone can test.
Where this comes from
The role-goal-benefit format is the Connextra template, in common use since the early 2000s; INVEST is Bill Wake's checklist. The examples and the story-to-requirement section are ours, and follow how Entalpa links a story to the requirements written from it. Nothing here is a measurement.
The template
## US-001 <short name>
As a <role>,
I want <goal>,
so that <benefit>.
Priority: must | should | could | won't
Stakeholder: <who asked for it>
Acceptance criteria:
- Given <context>, when <action>, then <observable result>.
- Given <context>, when <action>, then <observable result>.
Out of scope:
- <what this story deliberately does not do>- Role is a real kind of user, not "the user". "A first-time buyer" and "a warehouse manager" want different things from the same screen.
- Goal is what they want to do, not the UI that does it. "Filter orders by status", not "a dropdown on the orders page".
- Benefit is the part most often left off and the most useful: it is what lets someone choose between two ways of building it.
Ten user story examples
| Product | User story |
|---|---|
| E-commerce | As a returning customer, I want to reorder a past order in one step, so that I don't search for the same items again. |
| E-commerce | As a shopper, I want to see delivery dates before checkout, so that I know whether the order arrives in time. |
| SaaS | As an account admin, I want to remove a user's access immediately, so that a person who left can't read our data. |
| SaaS | As a new user, I want to import my data from a CSV, so that I can try the product with real data on day one. |
| Banking | As a card holder, I want to freeze my card from the app, so that a lost card can't be used while I look for it. |
| Healthcare | As a patient, I want a reminder the day before my appointment, so that I don't miss it. |
| Internal tool | As a support agent, I want to see a customer's last five orders on the ticket, so that I can answer without switching tools. |
| Mobile app | As a commuter, I want the app to work offline, so that I can read saved articles on the train. |
| Developer tool | As a developer, I want my coding agent to read the project's requirements, so that it stops guessing what the feature should do. |
| Security | As a user who forgot my password, I want to reset it by email, so that I can get back in without contacting support. |
The INVEST checklist
| Letter | Means | The question to ask |
|---|---|---|
| I | Independent | Can it be built and shipped without another story? |
| N | Negotiable | Does it say what, and leave how open? |
| V | Valuable | Would the role notice if it shipped? |
| E | Estimable | Could the team size it, or is something unknown? |
| S | Small | Does it fit in one iteration? |
| T | Testable | Can you say yes or no to "is it done"? |
"Testable" is the one that fails most often, and it is the one acceptance criteria exist to fix. Examples of criteria that pass it are in acceptance criteria examples.
A full example, from story to requirements
## US-004 Forgotten password
As a user who forgot my password,
I want to reset it by email,
so that I can get back in without contacting support.
Priority: must
Stakeholder: Support lead (40% of tickets are lockouts)
Acceptance criteria:
- Given I request a reset, when I open the link within 60 minutes, then I can set a new password.
- Given I used a reset link once, when I open it again, then I see "link already used".
- Given I reset my password, when I return to another signed-in browser, then I am signed out there.
Out of scope:
- SMS reset. Magic-link login.
Requirements written from this story:
- REQ-001 A reset link is valid for 60 minutes from sending.
- REQ-002 A reset link can be used once.
- REQ-003 Setting a new password signs out every other session.The story says why; the requirements say exactly what. Keeping both, linked, is what lets you answer "which requirements does this story change?" when the story is rewritten. That link is also the backbone of a requirements traceability matrix.
User stories and AI coding agents
A story is written for a team that will ask questions. An agent will not: it fills every gap with the most typical answer and reports the task done. Hand an agent "As a user I want to reset my password" and it decides the link expiry, whether links are reusable, and what happens to other sessions on its own. The acceptance criteria and the requirements under the story are what turn those guesses into decisions you made.
Entalpa keeps stories, the stakeholders behind them and the requirements written from them as linked records with MoSCoW priority, and flags a requirement when its story is edited afterwards. Describe a feature in plain words and it drafts the stories and requirements for you to review; your agent then reads them over MCP. Stories export as Markdown or JSON.
Questions this raises
What is the user story template?
"As a <role>, I want <goal>, so that <benefit>." The role says who, the goal says what they want to do, and the benefit says why, which is what lets the team choose between ways to build it.
What is a good example of a user story?
"As a card holder, I want to freeze my card from the app, so that a lost card can't be used while I look for it." It names a specific role, a goal that is not a UI element, and a benefit that explains the urgency.
Do user stories need acceptance criteria?
Yes, if anyone other than the author will build them. Acceptance criteria make the story testable: each one is a check that returns yes or no, written in Given-When-Then or as a plain rule.
What is the difference between a user story and a requirement?
A user story describes a need from a user's point of view and leaves room for discussion. A requirement is a single verifiable statement of what the system must do. One story usually produces several requirements.
Entalpa gives your agent one locked source of truth
Structured, traceable requirements your agent reads over MCP — so it works from a curated spec instead of reconstructing your project every session. Free to start, no card, and reading or writing your project over MCP never spends credits.
Other guides