Blog ·

Jira epic template: what to put in one, and how to reuse it

A Jira epic template is a fixed outline for the one work item that holds a large body of work together: a summary pattern, a description with the same headings every time, and a known set of child stories. Jira Cloud has no built-in store of saved epics, so you keep the outline somewhere and reuse it by cloning a model epic, by a Jira Automation rule, or by a template app. If the same epic comes back on a calendar (a quarterly security review, a monthly release, a yearly audit), the outline is only half the job, and the other half is making it appear on time. This article gives you the outline first, then the ways to reuse it.

What an epic is for in Jira Cloud #

Atlassian's own definition (checked September 2026) describes an epic as "the default work type your teams can use to capture a large body of work", and "essentially a large user story that can be broken down into a number of smaller stories". The same page notes that "Epics are almost always delivered over a set of sprints" and that scope changing inside an epic is normal.

Two consequences for a template:

A Jira epic template you can copy #

Paste this into the description of a model epic, or into whatever tool you reuse it from. Every heading earns its place by answering a question someone asks in the middle of the work.

Summary: <Outcome> for <scope>, <period>. For example, Access review for production systems, Q4 2026.

Description:

  1. Goal. One or two sentences saying what is true when the epic is done.
  2. Why now. The trigger: a customer commitment, an audit date, a release.
  3. In scope. A short bulleted list.
  4. Out of scope. Just as short. This is the section that stops the epic from growing for ever.
  5. Done when. Three to five checkable conditions.
  6. Owner and stakeholders. Who decides, who is informed.
  7. Links. The design doc, the dashboard, the previous epic of the same kind.

Fields worth setting every time:

Field What to put in it Why it matters
Summary Outcome, scope, period Scannable on the timeline and in search
Labels A stable label per epic family, eg. access-review One filter finds every past cycle
Assignee The owner, one person An epic owned by a team is owned by nobody
Due date The date "done when" must hold Shows lateness on the calendar view
Priority Your normal scale Sorts it among other epics
Components The area it touches Routes questions to the right people

Child stories. List the stories the epic always needs, with a one-line summary each. For an access review, for example: export the user list, review admin accounts, review service accounts, remove leavers, record sign-off. Those are the items you do not want to retype.

Four ways to reuse a Jira epic template #

Clone a model epic Jira Automation rule Template app Recurring rule
Who starts it A person A trigger you choose A person A schedule
Copies the description Yes Yes, as written in the rule Yes Yes
Brings the child stories Only if you include them Only if the rule creates them Yes, as saved One recurring story per rule
Changes the period in the title By hand With smart values Varies by app With tokens
Runs on a calendar No Yes, with a scheduled trigger No Yes

Option 1: clone a model epic #

Keep one epic, say OPS-100 Access review TEMPLATE, closed or parked where nobody works on it, and clone it each cycle. Atlassian's clone documentation (checked September 2026) says cloning copies "most information from a work item like the Summary and Description fields and more", and lists what is not copied automatically but can be included:

Attachments Subtasks Links Custom fields (if they're set up to be cloned) Comments Child work items (for Epics).

So the children come along only if you tick them in the clone dialog, and the docs add that "the prefix Clone is automatically added to the Summary of a cloned work item", which you then edit out. You also need the Create work items permission in the space.

Cloning is the right tool when a person always starts the epic and the model epic is kept tidy. It is free and needs no admin. For more on what cloning carries and misses, see bulk clone issues in Jira.

Option 2: a Jira Automation rule #

An Automation rule can create the epic from a trigger, with the description written into the rule, and then create further work items whose parent is the epic it just made. With a scheduled trigger it runs on a calendar too. The trade-offs are the ones every Automation-based template has: the template lives inside a rule that only an admin can edit, and every run counts against your plan's automation limits. Those limits are laid out in Jira Cloud automation limits, and Jira automation templates covers what the ready-made library does and does not include.

Option 3: a template app #

Apps such as Issue Templates for Jira and Easy Templates for Jira save a whole hierarchy, epic plus stories plus subtasks, and let people pick it when they create work. That is the most complete answer for a structure that is started by hand. Both are covered, with their prices, in Issue Templates for Jira and Easy Templates for Jira.

Option 4: a recurring rule, for epics that come back on a calendar #

Many epics are one-offs: a new feature, a migration. Some are the same every cycle, and those are where the template is least of the problem. The quarterly access review, the monthly release, the yearly renewal of certificates all need the same epic on a known date, and "someone remembers to clone it" is the step that fails.

Recurring Work Items for Jira handles the calendar part. A rule holds the issue template (work type, summary, description, assignee, labels, priority) and a schedule, and creates the item when the date comes, only in the project it belongs to. Two ways to use it with epics:

  1. A new epic each cycle. Set the work type to Epic and put date tokens in the summary, so each run is titled with its own period: Access review, {{now.monthName}} {{now.year}} becomes Access review, October 2026 on the October run. The token vocabulary is on the dynamic titles and dates page.
  2. Recurring stories inside a standing epic. Keep one long-lived epic, such as Platform maintenance 2026, and give each recurring rule that epic's key in Parent issue. Every monthly patching story then lands under it, and parent = <key> lists the whole year.

Each item a rule creates carries a label naming that rule, so every past cycle is one filter away. What a rule does not do is build the whole tree in one go. It creates one work item per run, with its own subtasks if you define them. For an epic whose stories must all appear together, pair the options: a recurring rule for the epic and one rule per story that repeats, or a template app when a person starts it anyway.

How to choose #

When the manual way is enough #

If your team creates a given kind of epic twice a year, a pinned Confluence page with the outline above and a model epic to clone will serve you well. Tools earn their place when the epic is frequent, when people forget to create it, or when several teams need the identical structure. Start with the outline, because a good template in a plain description is worth more than a poor one in any tool.