Five Jira issue template examples worth copying

Here are five worked examples you can copy. Most teams do not adopt templates because of a grand standardisation initiative. They adopt them because someone got tired of re-typing the same bug report fields for the hundredth time, or because two people raised the “same” request in three different shapes and nobody could compare them. Templating fixes the small, repeated friction that quietly eats hours every week.

Save any Jira issue as a reusable form, fill the bits that change with variables you define once, and let the rest pre-populate, and a blank create screen becomes a guided form. Onboarding and service-request examples are a documented consistency and MTTR win, not just tidiness: when every incident and every new-hire checklist captures the same fields, follow-up questions and dropped steps fall away. Below are the five places this pays off first, each with a structure you can copy. When you want a ready-made starting point for any of them, browse the Jira issue templates library.

1. Bug report template example

A bug report is only useful if it tells the engineer enough to reproduce the problem. The fields that make that possible (steps, expected result, actual result, severity) are exactly the fields people skip when they are in a hurry. Make those fields the default, not an afterthought.

What a solid bug report captures:

• Summary: [Bug] [Component] - short description
• Steps to reproduce: numbered, specific, copy-pasteable
• Expected result vs actual result: side by side
• Severity: Critical, Major, Minor
• Environment: browser, OS, app version

Copy this block straight into a Jira description field as your starting structure:

Summary:        [Bug] [Component] - short description
Steps to reproduce:
  1. ...
  2. ...
  3. ...
Expected result: ...
Actual result:   ...
Severity:        Critical | Major | Minor
Environment:     browser / OS / app version

The payoff is consistency. Every report arrives in the same shape, triage gets faster, and you stop the back-and-forth of “can you give me steps to reproduce?”. You can also lock in the right project, components and labels so bugs land where the right team will see them. For a ready-made starting point, grab the Jira bug report template, or read how smart values can auto-fill fields like the reporter or the current date.

2. Feature request template example

Feature requests arrive from everywhere: sales calls, support tickets, a comment in a stand-up. Without a fixed structure they are impossible to compare, so prioritisation becomes guesswork. Forcing every request through the same questions is what makes a backlog rankable.

A good feature-request structure asks for:

• Summary: [Feature Request] - short description
• User story: As a [user], I want [capability], so that [outcome]
• Acceptance criteria: the conditions that mean “done”
• Priority and requester

Copy this into the description field so every requester answers the same questions:

Summary:             [Feature Request] - short description
User story:          As a [user], I want [capability], so that [outcome]
Acceptance criteria:
  - ...
  - ...
Priority:            High | Medium | Low
Requester:           ...

The user-story field is the one most people leave out and most product managers wish they had. Putting it in the structure means it is always there. A dropdown variable for priority keeps everyone using the same scale instead of inventing their own. Start from the feature request template, then pair it with a story for the work that comes out of an accepted request, and define your inputs once with variables in templates.

3. Recurring task and checklist template example

Routine work (the recurring deployment checklist, the monthly report, the customer review) tends to be created from memory, which means details get dropped. Turn that memory into structure. Define the description, the standard sub-tasks, the default assignee and due-date pattern once, and every new task starts complete.

This is where reusing variables across a parent and its sub-tasks matters. Fill in a client name once on the parent and it flows through to every sub-task, so a five-step task does not become five rounds of copy-paste. A typical recurring-task structure covers a parent plus this checklist of sub-tasks:

Parent:   [Task] - short description (what done looks like)
Sub-tasks:
  - Prepare inputs / gather data
  - Run the standard procedure
  - Review and validate
  - Notify stakeholders / sign off
Assignee:  default owner (adjust at create time)
Due date:  relative to the parent due date

Browse the task template to see the structure in practice, or read using templates for how the create flow works.

4. Sprint-ready story template example

Sprint planning slows down when stories arrive half-formed: no acceptance criteria, no estimate, no clear owner. Templating your story and task formats means the team walks into planning with issues already shaped for discussion rather than spending the session cleaning up wording.

A sprint-ready story structure usually includes:

• Summary: [User Story] - short description
• Description: the full story
• Acceptance criteria: the conditions for “complete”
• Story points and assignee
• Sprint: filled from a dropdown variable at create time

A small but real bonus: when you create the same scaffolding of issues every sprint, you can build an Epic template that scaffolds the whole set in a single launch instead of clicking through the create screen repeatedly. Start from the user story template for the stories, and for an epic-level rollup begin with the epic template.

5. Onboarding and ITSM service-request template example

Onboarding is the textbook case because it is identical every time and easy to get wrong. Every new hire needs the same paperwork, the same accounts, the same orientation. Miss one step and someone spends their first day without a laptop login.

An onboarding structure captures the whole sequence as a parent issue with sub-tasks:

• Summary: [Onboarding] - new hire name
• Checklist as sub-tasks: HR paperwork, workstation setup, account provisioning, orientation
• Assignee: the responsible HR or IT owner per step
• Due date: relative to the start date

Use a text variable for the new hire’s name and it appears across the parent and every sub-task. The HR employee onboarding template shows the full structure.

The same parent-and-checklist pattern carries straight into ITSM, and here the win is measurable: when every incident and service request is captured with the same fields (impact, affected service, environment, steps already tried), agents stop chasing missing detail, follow-up questions drop, and mean time to resolution falls. Start from the ITSM incident / service request template for a repeatable capture form, or see a worked incident report.

What these five examples have in common

Every example above is a place where the same work happens repeatedly and the cost of an incomplete or inconsistent issue is real: a bug that cannot be reproduced, a request that cannot be ranked, an onboarding step that gets skipped, an incident that takes three rounds of questions to triage. Templating is the cheapest way to remove that variance. When you are ready to apply any of these, browse them all in the Jira issue templates library.

Process Templates for Jira lets you turn any existing issue (Epic, Story, Task, Bug or Sub-task) into a reusable template, add variables that get filled at create time, and choose whether to prefill or skip the create screen entirely. It is built on Atlassian Forge, Cloud Fortified, and used by more than 400 teams. It stores data in EU data centres with no personal data retained. It is free for up to 10 users, then 0.50 USD per user per month, with a 30-day trial and no credit card required.

If you are setting this up for the first time, the getting started guide walks through your first template in a few minutes.

Browse the Jira issue templates library to pick the example that is costing you the most time right now, or Install Process Templates for Jira on the Atlassian Marketplace.