Jira User Story Template: Format, Examples & Reuse

Jira user story template guide for agile and scrum teams

Sprint planning starts. Someone opens a story and it reads: "Add export feature." No acceptance criteria, no context, no scope. The engineer asks what "export" means. The PM explains. Someone else asks about permissions. Ten minutes later you're still on the first ticket. This is what happens without a consistent Jira user story template — a structured description that every story starts from. This guide gives you a ready-to-use template, four copy-paste examples for different team types, and three ways to make it the default for every new story your team creates.

Why user stories use this format​

A user story is not a task description — it is a statement of intent from the perspective of someone who needs something done. The three-part format exists for a specific reason:

• As a [persona] — forces you to name who the work is for, which rules out building the wrong thing for the wrong person
• I want [goal] — keeps the focus on the outcome, not the implementation (you can't accidentally write a technical spec in this field)
• So that [outcome] — captures the business reason, which is what engineers need when they hit an unexpected edge case and have to make a decision without asking

The Acceptance Criteria block then answers: "how do we know this is done?" — written in Given/When/Then so it can be verified by QA without asking the author what they meant.

If a story can't be written in this format, it usually means the requirement is either too large (break it into smaller stories) or it is not actually a user-facing feature (use a Task or Spike instead — see When NOT to use user stories below).

The Jira user story template (copy-paste ready)​

Use this as your default description template for every new user story in Jira:

## User Story

**As a** [persona — who is this for?],
**I want to** [goal — what do they want to do?],
**so that** [outcome — why does it matter?].

---

## Acceptance Criteria

- [ ] Given [initial context], when [action], then [expected result].
- [ ] Given [initial context], when [action], then [expected result].
- [ ] Given [initial context], when [action], then [expected result].

---

## Out of scope

What this story explicitly does NOT cover:
-

---

## Notes / open questions

-

---

<!-- Jira fields (set before sprint planning)
  Epic Link: [link to parent epic]
  Story Points: [estimate]
  Priority: Medium
  Labels: [team or feature label]
-->

The commented block at the bottom is a reminder for the reporter — it will not render in the Jira description view but serves as a prompt when filling in the issue. If you are using Templify, set these as actual Jira field defaults in the template editor instead.

Recommended Jira fields to set in the template:

• Story Points — add a placeholder or a team default to prompt estimation at every story
• Priority — default to Medium; change only when there is a specific reason
• Epic Link — always link before sprint planning so the backlog is filterable by initiative
• Labels — add the team or feature label (e.g. payments, onboarding, api)
• Assignee — leave unset in the template; assign at sprint planning, not at creation

Here is what the template looks like once a reporter fills it in and saves the issue in Jira:

4 Jira user story template examples​

The format above works across team types, but the specifics change. Here are four fully filled-in examples you can adapt directly.

## User Story

**As a** registered user,
**I want to** receive an email notification when my order status changes,
**so that** I can track my order without having to log in and check manually.

---

## Acceptance Criteria

- [ ] Given an order status change occurs (any status), when the user has email notifications enabled, then they receive an email within 5 minutes containing the new status and a direct link to the order.
- [ ] Given email notifications are disabled, when the order status changes, then no email is sent and no error occurs.
- [ ] Given the email fails to deliver, when the delivery failure is confirmed, then the event is logged and an alert is raised in the #platform-alerts channel.

---

## Out of scope

- Push notifications (covered in STOR-482)
- SMS notifications

---

## Notes / open questions

- Confirm 5-minute SLA with product — is this a hard requirement or a target?

## User Story

**As a** backend engineer integrating with the payment service,
**I want** the webhook handler to verify Stripe signatures before processing any event,
**so that** we can reject spoofed requests before they reach our order pipeline.

---

## Acceptance Criteria

- [ ] Given a POST to `/webhooks/stripe` with a valid `Stripe-Signature` header, when the payload matches the signature, then the event is processed and returns HTTP 200.
- [ ] Given a POST with an invalid or missing signature, when validation fails, then the request is rejected with HTTP 400 and nothing is persisted.
- [ ] Given Stripe retries a previously processed event (idempotency key match), when the duplicate is detected, then it returns HTTP 200 without reprocessing.

---

## Out of scope

- Handling event types beyond `payment_intent.succeeded` (follow-up stories in the Payments epic)

---

## Notes / open questions

- Webhook secret stored in AWS Secrets Manager — confirm key name with platform team.

## User Story

**As a** project manager using the reporting module,
**I want to** export the current project report as a PDF,
**so that** I can share it with stakeholders who don't have access to the system.

---

## Acceptance Criteria

- [ ] Given the user is on the Project Report page, when they click "Export as PDF", then a PDF download starts within 3 seconds.
- [ ] Given the report includes more than 100 issues, when the export runs, then it completes within 15 seconds and includes all visible issues.
- [ ] Given the export is triggered, when the PDF is generated, then it is named `[Project Name]_Report_[YYYY-MM-DD].pdf`.
- [ ] Given the user does not have "Export" permission, when they open the report page, then the export button is not shown (not just disabled).

---

## Out of scope

- CSV export (PROJ-211)
- Scheduled automatic exports (PROJ-240)

---

## Notes / open questions

- Do we need a loading indicator for large reports? Check with design.
- Confirm max report size with infrastructure — 100 issues is an assumption.

## User Story

**As a** data analyst on the revenue team,
**I want** the sales pipeline data to be automatically exported to our Google Sheet every morning,
**so that** the sales team always has up-to-date numbers without asking me to run the export manually.

---

## Acceptance Criteria

- [ ] Given it is 06:00 UTC, when the scheduled job runs, then the Google Sheet is updated with the current pipeline snapshot within 10 minutes.
- [ ] Given the previous day's data is in the sheet, when the new export runs, then the existing rows are overwritten (no duplicates).
- [ ] Given the export job fails for any reason, when the failure is confirmed, then a Slack message is posted to `#data-alerts` with the error type and timestamp.
- [ ] Given an analyst wants to change the export schedule, when they update the schedule field in the pipeline job configuration (Settings → Data Jobs → Pipeline Export), then the new schedule takes effect on the next run without restarting the job.

---

## Out of scope

- Real-time pipeline sync (out of scope for Q2)
- Exporting to tools other than Google Sheets

---

## Notes / open questions

- Confirm Google Sheets API quota limits with the platform team before finalising the export frequency.
- "Pipeline job configuration" refers to the internal admin UI at `/admin/data-jobs` — confirm exact path with the platform team before development starts.

How to save and reuse your Jira user story template​

Having the template text is step one. Making it the default — so every new story starts from it automatically — is step two. There are three paths depending on your team size and Jira setup.

Option 1: Paste manually (works for one project, one team)​

The simplest approach: copy the template text into your clipboard, then paste it into the Description field every time you create a new story.

When this works:

• Single project, small team (3–5 people)
• Template adoption is the immediate goal, tooling is secondary
• You want zero setup time

When this breaks down:

• Multiple projects — each team creates their own "standard"
• New team members don't know the template exists
• Template gets edited on individual issues and drifts back to blank descriptions within a few weeks

This approach does not scale. It is a valid starting point, but plan to graduate to Option 2 or 3.

Option 2: Jira Automation (free, moderate setup)​

Jira Automation can pre-fill the Description field when a new Story is created. Here is the rule setup:

Rule: Pre-fill description on Story creation

1. Trigger: Issue created
2. Condition: Issue type = Story
3. Action: Edit issue → Description → set to the template text (paste the full markdown template from above)

Limitations to be aware of:

• The automation fires after the issue is created, so the description appears in the issue but was not visible during creation — the reporter sees a blank description on the Create dialog and the template only after saving.
• If the reporter types anything in the description during creation, the automation overwrites it.
• You need Jira project admin permissions to set up automation rules.
• This creates one rule per project — if you have 20 projects, you manage 20 rules.

For a complete walkthrough including child issue automation, see Jira Automation for issue templates: epics, tasks, and child issues.

Option 3: Templify — template available at creation time, across all projects​

Templify is a Jira Cloud app that lets you define issue templates and make them available directly in the Create Issue dialog. The template is selectable before the reporter submits the form, so the description is never blank.

Why this beats Automation:

• Template is visible and selectable during creation, not injected after saving
• Multiple templates per issue type (e.g. "Story — Feature", "Story — Tech Debt", "Story — Bug-Driven")
• One template definition covers all projects — no per-project rule management
• Reporter can choose a different template or no template — it is not forced

Which option should you choose?​

If you manage more than one Jira project and want the template to appear before the reporter submits the issue, Templify is the right path. If you have a single project and need something working today, start with manual paste or an Automation rule and migrate later.

Related guides:

5 common mistakes in Jira user story templates​

1. "As a user" — a persona that tells you nothing​

The most common anti-pattern. "As a user" carries no context — it does not tell you what the person is trying to accomplish or what constraints they work under. Replace it with a specific role: "As a project manager using the billing module", "As a new developer onboarding to the codebase", "As a support agent handling tier-2 tickets".

The persona is not about the job title. It is about the context that makes the goal and outcome make sense.

2. Acceptance criteria that describe implementation, not behaviour​

Wrong: "The system calls the Stripe API endpoint /v1/charges."
Right: "Given a successful payment, when the user completes checkout, then the order status updates to Paid within 5 seconds."

Acceptance criteria define what success looks like from the outside — in test language, so QA can verify them without reading the code. If your AC reads like a technical spec, rewrite it in Given/When/Then.

3. No "Out of scope" section​

Without it, a story's scope is "everything the words could possibly mean". A one-sentence out-of-scope block eliminates the most common sprint blocker: mid-sprint scope expansion disguised as a clarification.

4. Story Points and Epic Link left blank in the template​

A template with blank Story Points signals that estimation is optional. Set a placeholder or a team default in the template itself. Same for Epic Link — if it is blank in the template, it will be blank in the majority of created issues.

5. One template for all Story types​

A tech debt story needs different context than a customer feature story. A bug-driven story needs different AC than a greenfield feature. Start with one template, then watch for the signal to split: when you notice that more than roughly 20% of your stories consistently need the same extra fields or sections that don't belong in a generic story (e.g. a "Regression risk" block for every tech-debt story, or a "Customer impact" section for every external-facing feature), that is the point to create a second template variant. Creating variants too early adds overhead before you know the pattern; creating them too late means your single template becomes a kitchen-sink document that nobody fills in properly.

When NOT to use the user story format​

The user story format works well for user-facing features. It breaks down in three common situations:

A simple test: if you cannot complete the sentence "So that [a real person] can [do something valuable]" without making it up, you are probably looking at a Task or Spike, not a Story.

Jira user story template setup checklist​

Use this before your next sprint planning:

If more than three of these are unchecked, manual paste will not hold. Move to Jira Automation or Templify before your next sprint.

External references:

• Atlassian: user stories — official guide to the format
• Scrum.org: the product backlog — context on where user stories live in Scrum