What this template is for
Epics are where most product teams lose the plot. They start with a clear goal, slowly accumulate scope, ship most of what was planned, and then quietly close months later without anyone checking whether the original outcome was achieved.
This template fights both failure modes:
- Required fields on the create screen - goal, success metric, in-scope, out-of-scope. The in-scope/out-of-scope pair is the single most useful piece of discipline: it makes scope creep a conversation (‘do we expand scope or defer this?’) instead of an assumption.
- STM-created kickoff and close-out sub-tasks - the structural work that isn’t story- shaped: instrument the metric before shipping, set status cadence, retrospective at the end. Created automatically so they’re not forgotten in week one.
When to use it
Use this template for product work that takes more than a sprint and less than a quarter to ship. For single-sprint work, use a story. For cross-team or multi-quarter initiatives, use a program-management tool with Jira epics as constituent parts.
A signal that your ‘epic’ is really a project: more than two teams are involved, or you’re having steering-committee meetings about it, or you can’t fit the stakeholder list in the ticket. When that’s true, the epic is the wrong unit.
Fields to add to your Jira create screen
These are the fields a project admin should make sure exist on the Create Issue screen for this issue type (Project settings → Screens). Without these on the screen, reporters can't provide the information triage needs - and STM can't reference them either.
| Field | Example value | Required |
|---|---|---|
Summary | Checkout v3 - reduce step count from 4 to 2 for returning users | Yes |
Goal (custom) | What outcome does success look like - not what we're building | Yes |
Success Metric (custom) | Returning-user checkout completion rate from 78% to 88% by Q3 | Yes |
In Scope (custom) | What this epic covers - bullet list | Yes |
Out of Scope (custom) | What this epic does NOT cover - bullet list | Yes |
Product Owner | @pm.who.is.accountable | Yes |
Engineering Lead | @em.who.owns.delivery | No |
Design Lead | @design.partner | No |
Target Start | 2026-06-01 | No |
Target End | 2026-09-30 - reviewed at each sprint | No |
Status (custom) | Discovery / In Progress / Ramping Down / Done | No |
Note on custom fields. STM currently supports up to 5 custom fields per template. You can add as many custom fields as you like to your Jira Create Issue screen - the 5-field limit only applies if you want STM to set or update those custom fields itself.
Sub-tasks STM creates automatically
Build an STM sub-task template containing the items below, then wire it to an On Create Issue Executor scoped to this issue type. Whenever a new issue of this type is created in the project, STM creates the full sub-task set in one step - with assignee, due date, and components inherited from the parent unless you override them.
- Kickoff: confirm goal, scope, success metric with stakeholders
- Instrument the success metric BEFORE shipping (you can't measure what isn't tracked)
- Break in-scope work into stories; defer or document out-of-scope items
- Set up a regular status update cadence (weekly is typical)
- Sprint review checkpoints: progress against goal, scope adjustments
- Close-out: did the metric move? Document what was learned
- Retrospective: what worked, what to do differently next epic
Common questions
What's the difference between a Jira epic and a project?
An epic is a single coherent piece of product work that fits inside one team's backlog. A project is multi-epic, cross-team, or has a separate plan and governance. If your 'epic' has 50+ stories, multiple teams, or a steering committee, you have a project - use a program-management tool, with Jira epics as components.
How big should a Jira epic be?
One to three months of one team's effort, broken into stories that each fit inside a sprint. Epics under a month often don't justify the overhead; epics over a quarter become impossible to track and lose stakeholder confidence. If your epic stretches past 3 months, split it - the first half should ship and learn before the second half is fully scoped.
When is a Jira epic 'done'?
When the success metric is hit, or when the team explicitly decides to stop. 'We shipped all the stories' is not done if the metric didn't move - that's a learning, and it changes the next epic. Define the success metric before stories are written, not after they're shipped.
Should epics have sub-tasks?
Sub-tasks on the epic itself are for cross-cutting setup and close-out work that isn't story-shaped: kickoff, stakeholder alignment, success-metric instrumentation, retrospective. Story-level work lives on the linked stories, not as epic sub-tasks.
Automate the sub-tasks with STM
STM Issue Templates saves the sub-task list above as a reusable template and creates them on every new issue of this type - via an Executor on issue creation, on status transition, or triggered manually from the issue's "Create bulk sub-tasks" menu. STM does not change the parent issue's create screen (that's a Jira project-settings job) but it removes the manual work of creating the sub-tasks every time.
Try STM on the Atlassian Marketplace ↗ See how STM templates are built →