Free User Story Template with Examples
A clear, structured format for writing user stories that engineering teams can estimate, build, and test. Includes the standard persona-action-outcome template, acceptance criteria examples, and the INVEST quality checklist.
What is a user story?
A user story is a short description of a product capability written from the perspective of the person who will use it. It is the standard unit of work in agile product development. Unlike a technical specification that describes how something should be built, a user story describes what a user needs and why they need it. The development team then determines the best way to deliver that capability.
User stories originated in Extreme Programming (XP) in the late 1990s and became the dominant format for capturing requirements in Scrum, Kanban, and other agile frameworks. The key insight behind user stories is that requirements are better understood through conversation than through documentation alone. The story itself is a placeholder for a conversation between the product manager, the developer, and the designer. The acceptance criteria capture the outcome of that conversation.
Good user stories share a few properties. They are small enough to complete in a single sprint. They are independent of other stories so the team can prioritize and deliver them in any order. They describe value that a user or stakeholder can observe. And they are testable, meaning you can write specific criteria that determine whether the story has been successfully implemented.
The user story template
The standard format used by product teams worldwide. Each story follows a three-part structure that captures the who, what, and why.
Persona
The specific type of user. Avoid generic labels like “user.” Use “new subscriber,” “hiring manager,” or “free-tier customer” instead.
Action
What the persona wants to accomplish. Write it as a verb phrase: “filter search results by date,” “export a report as PDF,” or “invite a teammate to my workspace.”
Outcome
The value the persona receives. This explains why the action matters: “I can find recent results faster,” “I can share progress with my manager,” or “we can collaborate in real time.”
User story examples
As a hiring manager, I want to filter candidates by years of experience, so that I can quickly find applicants who meet the minimum qualifications for the role.
As a free-tier customer, I want to see how many API calls I have remaining this month, so that I can plan my usage and decide whether to upgrade before hitting the limit.
As a team admin, I want to set default notification preferences for new members, so that new team members are not overwhelmed by notifications on their first day.
As a mobile shopper, I want to save my shipping address for future orders, so that I can complete checkout in fewer steps next time.
Writing acceptance criteria
Acceptance criteria define the conditions that must be met for a user story to be considered complete. They translate the high-level intent of the story into specific, testable requirements. Without acceptance criteria, developers and QA engineers are left guessing what “done” looks like, which leads to rework and misaligned expectations.
The most common format for acceptance criteria is Given-When-Then, borrowed from behavior-driven development (BDD). This format structures each criterion as a scenario with a precondition, an action, and an expected result. It forces clarity because you cannot write a Given-When-Then statement without specifying all three parts.
When [action],
Then [expected result].
Given I am on the candidate list page with 50+ applicants, when I select "5+ years" from the experience filter dropdown, then the list updates to show only candidates with 5 or more years of experience, and the result count updates.
Given I have an active experience filter applied, when I click "Clear filters", then all filters are removed and the full candidate list is displayed.
Given I apply an experience filter that matches zero candidates, when the list finishes loading, then I see an empty state message with a suggestion to broaden my filter criteria.
A few practical guidelines for acceptance criteria. First, keep each criterion focused on a single behavior. If you find yourself using “and” in the “then” clause, consider splitting it into two criteria. Second, cover both the happy path and important edge cases. The happy path is the scenario where everything goes as expected. Edge cases cover what happens when inputs are missing, permissions are insufficient, or the data set is empty. Third, write criteria that can be verified without subjective judgment. “The page loads quickly” is not testable. “The page loads within 2 seconds on a 3G connection” is testable.
The INVEST checklist for quality user stories
INVEST is a mnemonic that helps product managers and teams evaluate whether a user story is well-formed. Run every story through this checklist before it enters the backlog.
Independent
The story can be developed, tested, and delivered without depending on other stories in the backlog. Dependencies between stories create scheduling constraints and increase the risk that a blocked story delays an entire sprint. If two stories depend on each other, consider merging them or restructuring so each can stand alone.
Negotiable
The story is a starting point for conversation, not a rigid contract. The product manager defines the desired outcome, but the implementation details are negotiated with the development team. This keeps stories flexible enough to adapt as the team learns more during implementation.
Valuable
The story delivers observable value to a user or stakeholder. Technical chores (like database migrations or library upgrades) are important, but they are not user stories. If a story does not describe something a user would notice or care about, frame it as a task or enabler instead.
Estimable
The team can estimate the effort required to complete the story. If the team cannot estimate, it usually means the story is too vague, too large, or depends on unknowns. In those cases, create a research spike to reduce uncertainty before writing the story.
Small
The story is small enough to complete within a single sprint. Large stories (often called epics) should be split into smaller stories that can be independently delivered. A good rule of thumb: if a story takes more than half the sprint, it is too large.
Testable
You can write concrete acceptance criteria that verify whether the story has been correctly implemented. If you cannot define what "done" looks like, the story is not ready for development. Testability also means QA can write test cases before the code is written.
How to split user stories that are too large
One of the most common backlog problems is stories that are too large to estimate or complete in a single sprint. Large stories create uncertainty, delay feedback loops, and make sprint planning difficult. Here are five practical strategies for splitting stories into smaller, deliverable pieces.
Split by workflow step
If the story covers a multi-step process (for example, "As a user, I want to create and publish a blog post"), split each step into its own story. One story for creating a draft, another for adding images, another for publishing. Each step delivers independent value.
Split by user type
If the story applies to multiple personas, create a separate story for each. "As a user, I want to export data" becomes "As an admin, I want to export all team data as CSV" and "As a member, I want to export my own activity log." Each persona may have different requirements.
Split by data variation
If the story handles multiple data formats or input types, split by variation. "As a user, I want to import contacts" becomes separate stories for CSV import, vCard import, and manual entry. Start with the most common format.
Split by happy path vs. edge cases
Build the core happy path first, then handle edge cases in follow-up stories. "As a user, I want to reset my password" can be split into the happy path (email sent, link clicked, new password set) and edge cases (expired link, account locked, email not found).
Split by performance constraint
If the story includes a performance requirement (for example, "loads within 1 second"), deliver the feature first without the performance constraint, then add a follow-up story specifically for optimization. This lets you ship value early and optimize based on real usage data.
How Vantage automates user story creation
Writing user stories by hand means switching between analytics tools, Slack threads, and design files to gather context. Vantage does this automatically.
Connect your product data
Link your Slack workspace, analytics platforms (Amplitude, Google Analytics), design tools (Figma), and project management tools (Linear, Jira). Vantage indexes the context and builds a decision graph that connects data points across all sources.
Describe the capability or ask a question
Type a natural-language description like "Generate user stories for improving the onboarding flow." Vantage queries your connected data to find relevant analytics (drop-off rates, session recordings), conversations (Slack threads about onboarding friction), and designs (Figma screens for the current flow).
Review stories grounded in real data
Each generated story follows the As-a / I-want-to / So-that format with pre-written acceptance criteria. Every story includes citations back to the data source it was derived from. Click any citation to view the original Slack thread, analytics dashboard, or Figma screen.
Push to Linear or Jira with two-way sync
Once you review and approve the stories, push them directly into Linear or Jira as tickets. Vantage maintains two-way sync: when story details change in Vantage, the ticket updates. When a ticket status changes in Linear, Vantage reflects it. No manual copy-pasting between tools.
Common mistakes when writing user stories
Writing the solution into the story
Describe the desired outcome, not the implementation. "As a user, I want a dropdown menu" prescribes the UI. "As a user, I want to select my country" describes the need and lets the team determine the best solution.
Using "user" as the persona
Be specific about who this person is. Different personas have different needs, priorities, and contexts. "A first-time visitor" has different requirements than "a returning customer" or "an account administrator."
Skipping the "so that" clause
The outcome is the most important part. Without it, the team does not know why the feature matters, which makes it impossible to prioritize correctly or make tradeoff decisions during implementation.
Writing stories that are too large
If a story takes more than a few days to implement, split it. Use the strategies above: split by workflow step, user type, data variation, or happy path versus edge cases.
Related templates
Product Brief Template
Define context, hypothesis, scope, and success criteria before writing detailed stories.
View template →Feature Prioritization Template
Score and rank features using RICE, MoSCoW, and weighted scoring frameworks.
View template →Product One-Pager Template
Summarize problem, solution, metrics, and timeline on a single page for stakeholder alignment.
View template →Frequently asked questions
Generate user stories from your product data
Connect your tools, describe a feature, and get well-formed stories with traced acceptance criteria. Free to start.
Free to start. No credit card required.