User Story Template for Jira
A user story template configured for Jira Story issues. Includes the description format, acceptance criteria structure, story point estimation guide, and Jira field configuration. Use it to standardize how your team writes stories across projects.
Writing user stories in Jira
Jira is the most widely used tool for managing user stories. But Jira itself does not enforce good story writing. The Story issue type ships with a blank description field and no structure. Teams that do not establish a standard format end up with inconsistent stories that are hard to estimate, test, and verify.
This template provides the Jira-specific configuration and formatting conventions you need to write consistent, well-structured user stories. It covers the Description field format, custom fields for acceptance criteria and personas, story point estimation, and how to link stories to epics and PRDs for traceability.
The Jira user story template
Five sections covering Jira configuration, description format, estimation, and organization.
Jira Issue Type: Story
In Jira, user stories use the "Story" issue type. Configure your Story issue type with custom fields that match the user story format. At minimum, you need the Description field (for the As-a/I-want/So-that format), Acceptance Criteria (custom text field or built into Description), Story Points, and Priority.
Example Jira Story configuration: Issue Type: Story. Required fields: Summary (title), Description (user story format), Story Points, Priority, Sprint, Labels. Custom fields: Acceptance Criteria (multi-line text), User Persona (dropdown: admin, end-user, developer, manager), Business Value (select: high, medium, low).
Tips
- Create a custom "Acceptance Criteria" text field if your Jira instance does not have one
- Add a "User Persona" dropdown field to enforce persona specification
- Use the Description Template plugin to pre-populate the As-a/I-want/So-that format
- Configure Story as a sub-task type under Epic for proper hierarchy
Description Field Format
Use a consistent structure in the Jira Description field. Start with the user story in the As-a/I-want/So-that format. Follow with a "Context" section explaining why this story matters now. Then add "Acceptance Criteria" in Given-When-Then format. End with "Out of Scope" to set clear boundaries.
Example Description field: *User Story* 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. *Context* Recruiting team reports spending 25 minutes per job reviewing unqualified candidates. Filter would reduce this to under 5 minutes. *Acceptance Criteria* # Given I am on the candidate list page, when I select "5+ years" from the experience filter, then only matching candidates are shown and the count updates. # Given I have a filter applied, when I click "Clear filters," then all filters are removed. *Out of Scope* Saved filter presets (separate story). Filter by education level (separate story).
Tips
- Use Jira wiki markup (*bold*, # for numbered lists) for consistent formatting
- Keep the user story statement to one sentence — no compound actions
- Write 3-7 acceptance criteria per story, covering happy path and key edge cases
- The "Out of Scope" section prevents scope creep during implementation
Story Point Estimation
Jira supports story point estimation on the Story issue type. Use the Story Points field during backlog refinement. Most teams use Fibonacci values (1, 2, 3, 5, 8, 13) where each number represents relative complexity, not hours. Establish reference stories for each point value so the team has a shared baseline.
Example point scale: 1 point — Simple config change, copy update, or single-field form addition. Known pattern. Example: "Add tooltip to filter button." 2 points — Small feature with clear requirements. Example: "Add experience filter dropdown." 3 points — Feature with moderate complexity or 1 unknown. Example: "Implement candidate search with fuzzy matching." 5 points — Complex feature with multiple components. Example: "Build multi-criteria filter panel with saved presets." 8 points — Large feature that should probably be split. 13 points — Too large. Must be split before sprint planning.
Tips
- Create reference stories (one per point value) that the whole team agrees on
- If the team cannot agree on an estimate, the story probably needs to be refined further
- Use Planning Poker during refinement for unbiased estimation
- Track estimation accuracy over time to calibrate the team's pointing
Linking Stories to Epics and PRDs
Every Jira story should link to its parent Epic. The Epic represents the larger feature or initiative. Use the "Epic Link" field (Jira classic) or parent issue (Jira next-gen) to create the hierarchy. Additionally, add a link to the PRD or product brief in the story description or a custom URL field.
Example: Story "Filter candidates by experience" — Epic Link: HIRE-100 "Advanced Candidate Filtering." Related PRD: [link to Confluence PRD page]. Related stories in the same epic: HIRE-101 "Filter by education," HIRE-102 "Filter by skills," HIRE-103 "Save filter presets." This hierarchy helps sprint planners see which stories contribute to the same feature.
Tips
- Use Jira Epic Link field to maintain story-to-epic hierarchy
- Add a custom URL field for linking to external PRDs (Confluence, Notion, Google Docs)
- Use Jira "relates to" links to connect dependent stories within the same sprint
- Review the epic completion percentage during sprint planning to track feature progress
Labels and Components for Organization
Use Jira Labels and Components to categorize stories for filtering and reporting. Labels are flexible tags (e.g., "frontend," "backend," "ux-debt"). Components are predefined categories tied to a Jira project (e.g., "Search," "Authentication," "Billing"). Use both to create useful sprint board filters.
Example Labels: frontend, backend, api, database, ux-debt, tech-debt, quick-win. Example Components: Search (lead: Sarah), Authentication (lead: James), Billing (lead: Alex), Onboarding (lead: Priya). Quick Filter on sprint board: "Frontend only" — label = frontend. "My Component" — component in (Search).
Tips
- Define component leads so every story has a default owner for code review
- Use labels for cross-cutting concerns (tech-debt, accessibility) that span components
- Create sprint board Quick Filters for each component to focus daily standups
- Avoid label proliferation — review and clean up unused labels quarterly
Related templates
User Story Template
Tool-agnostic user story template with examples, acceptance criteria, and the INVEST checklist.
View template →Acceptance Criteria Template
Write clear acceptance criteria in Given-When-Then format with examples.
View template →Sprint Planning Template for Jira
Plan sprints in Jira with board config, JQL filters, and burndown tracking.
View template →Frequently asked questions
Generate user stories for Jira with Vantage
Connect your tools and Vantage generates well-formed stories with acceptance criteria, then pushes them directly to Jira. Free to start.
Free to start. No credit card required.