User story template guide with examples and acceptance criteria

Product launches and feature updates fail for many reasons, and one of the most common is that customers can’t see the value. A user story keeps that value in view from the first backlog item. It describes a feature from the perspective of the person who will use it, and Agile teams use it to agree on what to build and why.

This guide walks through 6 user story template formats with examples and acceptance criteria. It also shows how monday dev and monday agents in the monday AI Workspace help teams write and refine stories in the place where sprint planning already happens.

Key takeaways

• A user story template gives every feature the same structure, so each story states who the user is and the outcome they need.
• Standard templates give business and technical teams a shared language, which cuts misunderstandings and rework.
• Every story needs testable acceptance criteria, and the Given/When/Then format works well for user flows.
• AI speeds up drafting, but the product owner and engineers should review every AI-drafted story before planning.
• monday dev keeps stories connected to their epics and sprints, and monday agents such as Sprint Planner take on recurring backlog work.

What is a user story template?

A user story template is a reusable structure that captures who the user is and what they need, along with the reason behind the request. Standardizing the format makes stories clearer and speeds up sprint planning.

The most common format is “As a [role], I want [goal], so that [benefit].” Many teams call it the Connextra format, after the UK team at Connextra that created it in 2001. Treat the format as a prompt for the team conversation, with the details agreed in discussion.

3 key components of a compelling user story

Most user story templates build on these components:

• Role (who) names the user or persona who benefits from the feature (e.g., “As a project manager …”).
• Goal (what) states what the user wants to accomplish or the problem to solve (e.g., “… I want to assign tasks to team members …”).
• Benefit (why) explains the value the user gets from the feature (e.g., “… so that I can improve project visibility and keep everyone aligned”).

Together, these components tie each story to a real user need and a business outcome. For a company that builds flight information software, a user story could read: “As a frequent traveler, I want to receive notifications about flight delays so that I can adjust my schedule.”

User story templates vs. traditional requirements documents

Traditional requirements documents describe what a system must do, often in detailed specs written before development starts. A user story template keeps the focus on the person using the feature and leaves room for the team to shape the details together.

What are the INVEST criteria for user stories?

The INVEST criteria are a widely used framework for judging the quality of a user story. Each letter stands for a property of a well-structured, actionable story:

• Independent: The story stands alone and can be developed and delivered without relying on other stories.
• Negotiable: The story stays open to discussion and refinement as the team gives feedback.
• Valuable: The story delivers clear value to the user or business by addressing a real need.
• Estimable: The scope is clear enough for the team to estimate the effort involved.
• Small: The story fits within a single sprint or workflow iteration.
• Testable: Clear acceptance criteria let the team test and validate the story on completion.

How user story templates help Agile teams

A user story looks simple, but writing a good one takes more thought than its length suggests. A template does part of that thinking for the team:

• Faster story creation: A predefined structure helps teams draft and prioritize stories quickly during sprint planning.
• A shared language: A consistent format removes ambiguity, so product and engineering teams interpret requirements the same way.
• Built-in quality checks: Templates prompt writers to include acceptance criteria and user outcomes from the start.
• A backlog that’s easier to manage: When every story follows the same structure, the team can scan and prioritize the backlog with fewer errors.
• Real-time visibility: In a platform like monday dev, each story shows its progress and owner at a glance, so stakeholders can spot blockers and adjust plans early.

Essential components of a user story template

A story statement covers who, what, and why, but a developer needs more context before pulling a story into a sprint. A complete template puts that context in one place and gives every squad a shared standard for story quality.

• Title and ID: A short, outcome-focused name and a unique ID make the story easy to find and reference.
• Story statement: The role, goal, and benefit, written in the “As a / I want / so that” format.
• Acceptance criteria: Testable conditions that confirm the story works as intended.
• Priority and business value: A clear ranking and the expected impact, so the team knows what to build first.
• Estimate: Story points or whichever sizing method your team uses for sprint planning.
• Dependencies and links: The parent epic, related stories, and any work that must finish first.
• Definition of done: Your team’s shared quality standard, such as code review, testing, and documentation.
• Attachments and notes: Designs, PRDs, and research that add context without crowding the story.

Copy-ready user story template

Paste this template into your backlog, doc, or spreadsheet, then adjust the fields to match your team’s process.

Title: [Short, outcome-focused name]
As a [specific user role],
I want [goal or action],
so that [benefit or business value].
Acceptance criteria:

• Given [context], when [action], then [expected result].

Priority: [High / Medium / Low] Estimate: [story points]
Parent epic: [link] Dependencies: [items]
Definition of done: [team standard]

How to write acceptance criteria with Given/When/Then

Acceptance criteria are the specific, testable conditions the finished work must meet, written from the user’s point of view. The Given/When/Then format, borrowed from Gherkin-style behavior-driven development, frames each condition as a scenario: the starting context, the user’s action, and the expected result.

A rules-based checklist works too, especially for simple stories with fixed constraints. Here’s when to use each format:

Scenario-based criteria turn the frequent traveler’s story into checks QA can run and the product owner can sign off on:

• Scenario 1: Given my flight is delayed by 15 minutes or more, when the airline updates the departure time, then I receive a push notification within 5 minutes.
• Scenario 2: Given I’ve turned off push notifications, when a delay occurs, then I receive an email instead.
• Scenario 3: Given the delay is resolved, when the airline restores the original time, then I receive a confirmation update.

6 user story template examples

Teams often add fields to the basic story format so it fits how they plan and track work. The 6 templates below are the most common variations, and each suits a different kind of development team.

1. Simple user story template

A simple template covers one story at a time and keeps the focus on the user’s need. Beyond the story statement, it usually adds only a priority and an estimate of the effort involved.

2. Epic user story template

Agile teams use epics to group related stories under one larger goal. An epic might follow the same user across several needs, with each need written as its own story, so the team can track progress toward the bigger outcome.

3. Thematic user story template

A thematic template groups stories by business theme. It goes a step beyond epics by starting each story from your organization’s goals and strategy, which keeps development work aligned with your Agile strategy.

4. SAFe® user story template

Organizations that follow the SAFe framework often add data drawn from SAFe’s feature and prioritization practices, such as:

• Nonfunctional requirements: System attributes such as security, reliability, performance, and scalability that constrain a solution’s design
• Time criticality: How urgently the team needs to complete the work
• Cost of delay: The value lost if the release is postponed
• Risk reduction: The value of work that lowers risk or opens future opportunities

Learn more about the SAFe vs. Scrum Agile frameworks.

5. Job story template

Job stories swap the persona for the situation. The format reads: “When [situation], I want to [motivation], so I can [expected outcome].” Putting context ahead of persona helps when the same person needs different things depending on circumstance.

Job stories suit UX and research-heavy work, where the trigger counts for more than the user’s title. They pair well with customer interviews, since the situation often comes straight from what people describe. For example: “When I land with a tight connection, I want to see my next gate, so I can reach my flight on time.”

6. User story template with acceptance criteria

This template combines the story statement with acceptance criteria, so the team can estimate and test the work from one place. Here’s a filled-in example for a common Agile team scenario.

Title: Export sprint report as PDF
As a product manager,
I want to export the sprint report as a PDF,
so that I can share sprint results with stakeholders who work outside our development platform.
Acceptance criteria:

• Given a sprint is complete, when I select “Export,” then a PDF downloads with velocity, completed stories, and carried-over work.
• Given the sprint has 50 or more stories, when I export the report, then the PDF generates in under 10 seconds.
• Given I have view-only access, when I select “Export,” then I see a message explaining how to request report permissions.

Priority: High Estimate: 5 story points
Parent epic: Sprint reporting Definition of done: Code reviewed, tested, and documented

Each criterion uses concrete numbers and actions, so QA knows exactly what to test. Vague words like “fast” or “easy” become measurable thresholds.

Which user story template fits your team?

Use this summary to match each template to the work it suits best.

How to write a user story in 5 steps

Condensing a long feature explanation into a few clear sentences is harder than it looks. Working backward helps: define the user and their motivation first, then write the story.

Step 1: Define the end user

Start with a user or buyer persona. Consider the person’s job, skills, pain points, and day-to-day behavior, since these shape the decisions they’d make about your product.

Step 2: Identify what the end user wants

Look at how users work with your product today, then trace a path to the feature that would meet their need. Market research, surveys, focus groups, and reported issues all show what users expect from your product.

Step 3: Define why the user wants it

Once you know what users want, dig into the reason behind the request. Ask how the feature would help them reach their goals or get more value from your product.

Step 4: Outline your acceptance criteria

Acceptance criteria set the conditions the story must meet before the team can call it done. Write them from the user’s perspective: the story is complete when the user can do what they set out to do.

Step 5: Review, split, and refine with your team

Review each story together before it enters a sprint. The review turns the template into a shared conversation and catches missing details while they’re still quick to fix. Focus on these checks:

• Check it against INVEST: Confirm the story is independent, valuable, small, and testable.
• Split stories that are too big: When a story won’t fit in one sprint, split it by workflow step, business rule, or user role.
• Confirm shared understanding: Walk through the acceptance criteria with product and engineering so everyone agrees on what done looks like.

Backlog refinement sessions are a natural home for this review. A story that passes these checks is ready for estimation and sprint planning.

User story template best practices

Even well-structured templates can drift into habits that slow a team down. Use this table as a quick check during backlog refinement.

Pick 1 or 2 rows to focus on each sprint, and the small fixes will add up across a busy backlog.

How AI helps teams write user stories and acceptance criteria

Writing and refining dozens of stories each sprint takes real coordination. Product managers draft, engineers ask clarifying questions, QA adds edge cases, and the cycle repeats for every backlog item. A solid AI-generated first draft can shorten much of this back-and-forth.

Developers already work with AI every day. The Stack Overflow 2025 Developer Survey, based on 49,000+ responses, found that 84% of developers use or plan to use AI in their development process, and 51% of professional developers use it daily. Google’s DORA 2025 report, based on about 5,000 technology professionals, found that 90% use AI and over 80% report productivity gains.

Leadership attention is growing too. In Microsoft’s 2025 Work Trend Index, a survey of 31,000 knowledge workers, global leaders ranked product development among their top areas for accelerated AI investment.

For user stories, AI is most useful on the repetitive parts of drafting and refinement:

• Drafting story statements: AI turns PRDs, feedback, or meeting notes into first-draft stories in your template format.
• Suggesting acceptance criteria: It proposes Given/When/Then scenarios and edge cases your team might miss.
• Flagging INVEST issues: It highlights stories that are too large or missing a “so that” clause.
• Grouping feedback: It sorts customer requests into themes your team can turn into stories.
• Splitting epics: It suggests ways to break large epics into sprint-sized stories.

AI drafts still need a human check. The same Stack Overflow survey found that 46% of developers distrust the accuracy of AI tools, compared with 33% who trust it. Treat every AI-drafted story as a starting point, and have the product owner and engineers confirm the criteria before planning.

A user story template also makes AI output easier to review. When AI drafts into fixed fields like role, goal, benefit, and criteria, reviewers can compare drafts quickly and spot what’s missing.

How to choose a platform for managing user story templates

Once your team agrees on a template, the next decision is where those stories live. Look for a platform that keeps stories, criteria, and sprint status in sync as your squads grow. Each criterion below maps to a point where story quality tends to slip at scale.

• Customizable fields and templates: Add the components your team needs, such as priority, estimate, and definition of done.
• Hierarchy: Connect epics, stories, and sub-items so epic progress updates automatically.
• Acceptance criteria and definition-of-done tracking: Keep criteria attached to each story and visible during review.
• Sprint and backlog connection: Move stories from the backlog into sprints and track status in real time.
• Integrations with your development stack: Link stories to code work in GitHub, GitLab, and your IDEs.
• AI assistance with human control: Get AI-drafted stories and criteria that your team reviews and approves.
• Cross-functional visibility: Give design, leadership, and go-to-market teams a clear view of progress without extra reporting.
• Security and governance: Look for permissions and compliance features that match your organization’s requirements.

Excel and Word templates are a fine place to start. As you scale, copies drift between teams, and someone has to update a static file by hand because it has no link to sprint status. Platforms like monday dev keep each story connected to the epic and sprint it belongs to.

Before you commit, run a short pilot with one squad. Move a sprint’s worth of stories into the platform, then check that criteria, estimates, and epic links stay intact through review and release.

Build and manage user story templates with monday dev

monday dev, part of the monday AI Workspace, gives developers and Agile teams one place to plan and run their work. Its Agile templates include boards for user stories and epics, built around the who/what/why structure covered above. These features support user story creation directly.

Agile workflows and templates

Beyond user stories, monday dev includes templates for other Agile workflows. You can build a product roadmap, prioritize a feature backlog, plan sprints, and run a sprint retrospective, all connected to the stories they draw on.

Customizable stories with extra fields and statuses

On monday dev boards, you can add detail to each story without crowding the story statement. Assign a reviewer, attach supporting documents, add comments, or set timelines and deadlines, and every detail stays on the story’s item.

Multiple work views

Work views let your team see the same stories in different ways. The Kanban view suits user story workflows because it shows small tasks moving toward done, and the Timeline view shows how far you are from taking your product to market.

Connect stories to epics, sprints, and releases with hierarchy

The Hierarchy view in monday dev connects epics, features, and stories, so each story sits inside the larger goal it supports. As stories move to done, progress rolls up to the parent epic automatically.

Story points feed burndown charts and Agile Insights, which tracks velocity and planned vs. unplanned work across sprints. The Capacity Planner then helps you balance sprint scope against your team’s available time, so sprint commitments stay realistic.

Write and refine stories faster with AI and monday agents

AI in monday dev works inside the workflow where your stories already live. It can summarize PRDs, generate tickets, draft acceptance criteria, and categorize incoming requests and bugs. AI Daily Standups and sprint summaries keep everyone current with less meeting time.

monday agents take on the recurring work around your backlog. Agents that fit user story workflows include:

• Sprint Planner: Turns a prioritized backlog into sprint goals that fit your team’s capacity.
• Ticket Management Agent: Classifies incoming tickets and routes them by priority.
• Feature Request Agent: Collects and organizes feature requests so product owners can turn them into stories.
• Feedback Digest Agent: Groups customer feedback into themes with sentiment.
• Dependency and Risk Mapper: Maps dependencies and risks across related work.
• Status Reporter: Drafts progress updates for stakeholders.

Agents work within the guardrails and permissions you set, so your team stays in control of every story.

Teams can also use monday vibe to build custom apps on their dev data, such as a sprint-readiness dashboard. Through monday MCP, supported AI assistants can read and update monday dev work items, limited to actions their connected user already has permission to take.

How monday dev compares for managing user story templates

Where your stories live shapes how easily your team keeps them consistent. Here’s how monday dev compares with traditional issue trackers and with docs and spreadsheets.

Customer story: Vistra increased feature delivery speed by 28% with monday dev, according to monday.com’s Vistra customer story.

Build better stories with a user story template

A strong user story template gives your team a shared language for every feature. Pair it with testable acceptance criteria and AI-assisted refinement, then manage your stories in monday dev so each one stays connected to the sprint it ships in.