User Story Template: Examples, Formats, and How to Write Them Well
User stories define what to build from the user's perspective. Here are the templates, formats, and examples agile teams actually use - plus how to generate them automatically.
A user story is a short description of a feature written from the user’s point of view. It captures what someone wants to do and why - without specifying how to build it.
The classic format is:
As a [type of user], I want to [do something] so that [I get some benefit].
That’s the foundation. But user stories in real teams go deeper: they include acceptance criteria, story points, linked tickets, and a clear definition of done. This guide covers the templates you need, with real examples across different formats.
Why User Stories Exist
Before user stories, engineering teams worked from functional specs that described systems, not people. “The system shall process payments via credit card” tells an engineer what to build, but not whether it’s the right thing to build.
User stories flip the framing. They start with the person who will use the feature. That shift forces the team to answer: who actually needs this, and what problem does it solve for them?
The format also keeps requirements small. A user story should be completable in a single sprint. If a story would take six weeks to ship, it’s an epic - break it down.
The Standard User Story Template
As a [user role],
I want to [action or goal],
So that [benefit or reason].Example:
As a product manager, I want to receive a Slack notification when a ticket’s status changes, so that I can track sprint progress without checking Jira manually.
Three components, every time:
- Who - the user role. Not “the system” or “the user” generically. Be specific: “a first-time buyer,” “a team admin,” “a mobile user.”
- What - the action they want to perform. One action per story.
- Why - the underlying goal. This is the part most teams skip, and it’s the most important. The “so that” tells the team why the feature matters.
User Story Template with Acceptance Criteria
Most teams pair user stories with acceptance criteria - the specific conditions that must be true for the story to be considered done.
As a [user role],
I want to [action or goal],
So that [benefit or reason].
Acceptance Criteria:
- Given [context], when [action], then [result].
- Given [context], when [action], then [result].Example:
As a team admin, I want to add members to a workspace, so that new hires can access the tools from day one.
Acceptance Criteria:
- Given I am a team admin, when I navigate to Settings > Members, then I see an “Invite Member” button.
- Given I enter a valid email address, when I click “Send Invite,” then the user receives an email within 5 minutes.
- Given I enter an email already in the workspace, when I click “Send Invite,” then I see an error: “This user is already a member.”
The Given-When-Then format (also called Gherkin) makes acceptance criteria testable. QA can write automated tests directly from them.
User Story Template for Different Scenarios
Epic-Level User Story
Epics are large bodies of work that contain multiple stories. The story format still applies, but the scope is broader:
As a product team, we want to redesign the onboarding flow, so that new users reach their first value moment within 10 minutes of signing up.
This is too large for one sprint. It breaks down into individual stories like “As a new user, I want to skip the tutorial, so that I can explore the product at my own pace.”
Bug Fix as a User Story
Not everything is a new feature. Bug fixes can also be written as user stories:
As a mobile user, I want the checkout button to respond to my tap, so that I can complete my purchase without refreshing the page.
This keeps bugs in the same format as feature work, which makes prioritization easier - you’re always comparing user impact to user impact.
Technical Story
Some stories don’t have a visible user-facing change but still deliver value:
As a developer, I want to migrate the database to the new schema, so that query performance improves by 50% for all users.
Technical stories are sometimes called “enablers.” They don’t ship features, but they make future features possible. Use them sparingly - if most of your backlog is technical stories, engineering and product are misaligned.
User Story Examples by Product Type
SaaS B2B
As a sales manager, I want to export my team’s activity report to CSV, so that I can share it in our weekly leadership meeting.
As an account admin, I want to set user permissions at the folder level, so that sensitive financial data is only visible to finance team members.
Consumer App
As a new user, I want to sign up with my Google account, so that I don’t have to create and remember another password.
As a returning user, I want the app to remember my preferences, so that I don’t have to reconfigure settings every time I open it.
Internal Tool
As a support agent, I want to see a customer’s full order history on the ticket view, so that I don’t have to switch between tabs to answer refund questions.
As a warehouse manager, I want to receive a low-stock alert when any item drops below 20 units, so that I can reorder before we run out.
What Makes a Good User Story
There’s a well-known checklist called the INVEST criteria. A good user story is:
- Independent - not dependent on other stories to be complete
- Negotiable - details can change; it’s a conversation starter, not a contract
- Valuable - delivers something useful to a real user
- Estimable - small enough that the team can estimate the effort
- Small - fits within one sprint
- Testable - you can write acceptance criteria for it
If a story fails any of these, refine it before putting it in a sprint.
Common User Story Mistakes
“As a user” - too generic. Which user? A new user behaves differently than an admin. A mobile user has different constraints than a desktop user. Be specific.
No “so that” - a story without a reason is just a requirement. The “so that” is what helps the team make trade-off decisions when implementation gets complicated.
Too large - “As a user, I want to be able to manage my account” is an epic, not a story. If you can’t complete it in a sprint, break it down.
Written by one person - user stories work best when written collaboratively. Product defines the “who” and “why.” Engineering adds constraints. Design shapes the “what.” A story written in isolation misses too much.
How Teams Generate User Stories Today
Manually writing 10-20 user stories per sprint takes time. You need to translate meeting discussions, customer feedback, and Slack conversations into structured stories - then format each one, add acceptance criteria, and create tickets.
Telos automates this. After a planning call or Slack discussion, it pulls together the relevant context - what was discussed, what the existing tickets say, what the code history shows - and generates draft user stories for your review. You approve, adjust, or reject each one. Telos then creates the tickets directly in Jira, Linear, or Asana.
The manual translation work is automated. The judgment about what to build stays with you.
Want to see what this looks like in practice? Start with a demo. Or read more about acceptance criteria formats and examples - the natural next step after writing user stories.