Epic template for Jira

An Epic is a large, complex piece of work that cannot be finished in a single development cycle. It gets broken down into Stories and Tasks that are prioritized by their value to the product. The trouble is that every team scopes Epics a little differently, and the same Epic written by two product managers can read like two different documents. A Jira Epic template fixes the shape so that everyone plans large initiatives the same way, every quarter. Copy the template above straight into a Jira issue, or read on for what an epic is, the field set, a strong-versus-weak example, and how to make the structure reusable with Process Templates for Jira.

What is an epic in Jira?

In Jira and in agile planning generally, an epic is a large body of work that is too big to deliver in a single sprint. It sits above Stories and Tasks in the hierarchy: an epic groups many related child issues under one goal, and its progress is the roll-up of theirs. Where a Story captures one slice of user value, an agile epic captures the whole initiative, the redesign, the migration, the new product area, that the Stories add up to. Treating the epic as a real plan, with a problem, a scope and a finish line, rather than a label you drop on a pile of tickets, is what keeps a roadmap legible.

What this Epic template captures and why

A well-formed Epic answers four questions before any Story is written: what problem are we solving, how big is it, what could go wrong, and how will we know it is done. Skip any of those and the Epic becomes a label rather than a plan.

Field-by-field breakdown

• Summary: a short, outcome-focused title. “Onboarding v2: cut drop-off in the first session” is clearer than “Onboarding improvements.”
• Description: the epic description carries the business need, the goals, and the stakeholders. This is the narrative a new engineer reads to understand why the Epic exists.
• Problem statement: the specific pain and the change you intend to make. Keep it to a sentence or two.
• Requirements: the high-level capabilities that must exist for the Epic to be complete. These become the seeds for Stories.
• Scope: what is in and, just as important, what is out. Naming the excluded work prevents the Epic from sprawling.
• Timeline: estimated start and end dates, or a target release. “Start 2026-07-01, target ship 2026.Q3” is a commitment a stakeholder can plan around.
• Budget: the people and time you are allocating, expressed in whatever unit your team plans with.
• Team: the squad that owns delivery, plus any cross-functional or external partners.
• Dependencies: prerequisites that must land first. List them so blockers are visible from day one.
• Risks: the obstacles that could derail delivery, written down before they bite.
• Acceptance criteria: the conditions that mark the Epic as done. Tie these to the success metric, not to “all Stories closed.”

Best practices

• Write acceptance criteria for the Epic itself, not only for its Stories. An Epic is done when the outcome is real, not when every child ticket is closed.
• Pin one measurable success metric in the problem statement or acceptance criteria. “Drop-off at step 4 below 20% within 60 days” beats “improve onboarding.”
• State the scope boundary explicitly. The line that says what the Epic does not cover saves more arguments than the line that says what it does.
• List dependencies and risks while planning, not after a sprint stalls. They are cheapest to manage when they are visible early.
• Keep the field set identical across every Epic so dashboards, JQL filters, and reviews behave predictably. Using variables in the template lets you fill the project name or target quarter at create time without editing the structure.

Jira epic example: strong vs weak

A weak Epic reads like this: Summary “Onboarding improvements,” Description “Make onboarding better,” no scope, no metric, no acceptance criteria. Three weeks in, nobody can say whether it is working or when it is finished.

A strong Epic from this template reads like this: Summary “Onboarding v2: cut drop-off in the first session,” Problem statement “New users abandon setup before activation; cut first-session drop-off in half,” Scope “Covers signup-to-activation, excludes billing,” Acceptance criteria “Drop-off at step 4 below 20%, no regression in signup conversion, rollout behind a flag.” Anyone can read it and know the goal, the boundary, and the finish line.

How to use this template in Jira

1. Save an Epic as a template. Open the Epic you want to reuse and save it as a template, or build one from scratch following how to create templates.
2. Add variables for what changes each quarter. Add any variables for values that change each time, such as the target quarter or the owning squad.
3. Chain the expected Story templates so they are created underneath the Epic. Process Templates for Jira preserves the links between the issues, so the Stories land already attached to the parent.
4. Create the Epic from the template whenever a new initiative starts. Prefill the create screen or skip it entirely.

Frequently asked questions

What is an epic in Jira? An epic in Jira is a large body of work that is too big to finish in one sprint. It groups many related Stories and Tasks under a single goal and tracks progress from those child issues up to the initiative.

What is the difference between an epic and a story? An epic is a large initiative that spans several sprints and contains many stories. A story is a single slice of user value that fits in one sprint. Stories roll up into epics, which roll up into initiatives.

What should a Jira epic include? A strong epic includes an outcome-focused summary, a problem statement, scope boundaries, a timeline, dependencies and risks, acceptance criteria tied to a success metric, and the Stories that roll up to it.

How do I create a reusable epic template in Jira? Install Process Templates for Jira, build one Epic with the fields on this page, save it as a template, then chain the expected Story templates so the whole hierarchy is created in one action.

Related templates

Pair the epic with the work that rolls up to it: the User story template for the slices of value underneath it, the Task template for the execution work, and the Bug template for defects found along the way. To set quarterly goals with the objective modelled as an epic, see the OKR template. Or browse the full template library for matching formats across software, ITSM and support work.