Skip to content
Trevin Nimaladasa

TEMPLATESJIRA · EPIC

Epic

A short, outcome-focused container for a body of work, with objective, scope, milestones and dependencies.

Paste the blank into the ticket description and overwrite the [brackets].

  1. 01Summary

    Name the outcome, not the activity. "Modernise X" is fine, "Phase 2 of X" is not. A reader skimming a board should know what changes.

    [Verb] [what changes] for [who]

    Example

    Modernise customer onboarding

  2. 02Objective / Desired Outcome

    State the result and how you'll know it worked. Put a number and a date on it. If you can't measure it, say what you'll look at instead.

    [Outcome], measured by [metric], from [baseline] to [target] by [date].

    Example

    New customers reach their first successful order in under 10 minutes, measured by median time-to-first-order, from 3 days to 10 minutes by end of Q2.

  3. 03Problem Statement

    Describe what's wrong today and who feels it. Facts over opinions: volumes, delays, complaints, costs.

    [Who] struggles to [do what] because [cause]. Today this means [evidence].

    Example

    New customers struggle to place a first order because onboarding takes six manual steps across three systems. Today 38% abandon before their first order and support handles 1,200 onboarding queries a month.

  4. 04Scope

    Be explicit on both sides. Out of scope is the more useful half: name the things people will ask for.

    - **In scope:**
  - [Capability or area]
- **Out of scope:**
  - [Capability or area]

    Example

    • In scope:
      • Self-service sign-up and identity check
      • Automated account provisioning
      • Welcome and first-order guidance
    • Out of scope:
      • Changes to pricing or contracts
      • Existing customer migration

  5. 05Users / Stakeholders

    Separate the people who use the result from the people who decide or are affected by it. Name roles, and a person where you can.

    - Primary users: [role]
- Stakeholders: [role / name, what they care about]

    Example

    • Primary users: new SME customers, onboarding team
    • Stakeholders: Head of Sales (conversion), Head of Support (volume), Compliance (identity checks)

  6. 06Solution Overview

    Two or three sentences on the approach, then links. This isn't the design. It's enough for someone to judge whether the epic is sized sensibly.

    [Approach in two or three sentences.]

Links: [designs], [architecture], [discovery notes]

    Example

    Replace the manual hand-offs with one guided sign-up flow backed by an automated provisioning service. Identity checks move to a third-party provider via API.

    Links: Discovery report (Confluence), Target architecture v2

  7. 07Milestones / Phases

    Each milestone should leave something usable or decided, with a date. Three to five is plenty. If a milestone is "development complete", split it.

    - Milestone 1: [what exists], [date]
- Milestone 2: [what exists], [date]
- Milestone 3: [what exists], [date]

    Example

    • Milestone 1: identity check provider selected and contracted, 30 Nov
    • Milestone 2: guided sign-up live for 10% of new customers, 28 Feb
    • Milestone 3: automated provisioning live for all new customers, 30 Apr

  8. 08Dependencies

    List what you need from others and by when. Note which ones would move the dates if late.

    - Teams / systems: [name, what you need, by when]
- External vendors: [name, what you need, by when]

    Example

    • Teams / systems: Platform team, provisioning API, by 15 Jan
    • External vendors: ID-check provider, sandbox access, by 15 Dec

  9. 09Risks / Assumptions

    Keep the top few. Anything serious gets its own Risk ticket and a link here.

    - Risks: [risk, link to RSK ticket]
- Assumptions: [what you're counting on]

    Example

    • Risks: provider rate limits may throttle peak sign-ups (RSK-37)
    • Assumptions: no pricing change during the programme

  10. 10Acceptance Criteria

    Check these at epic level, not story level. They answer "is this epic ready to start and properly shaped". Edit to fit.

    - [ ] Epic outcome is clearly defined and agreed.
- [ ] Scope boundaries are documented.
- [ ] Key milestones and dependencies are identified.
- [ ] Epic is broken down into deliverable stories or tasks with clear ownership.

    Example

    • Outcome and target agreed with the Head of Sales on 12 Nov.
    • Scope and out-of-scope signed off in the steering group.
    • Three milestones and four dependencies recorded and owned.
    • 14 stories created and assigned across two teams.

  11. 11Definition of Done (DoD)

    Say what has to be true for the epic to close, including the measurement. An epic can ship and still not be done if nobody checked the outcome.

    - [ ] All child stories and tasks completed and accepted.
- [ ] Required documentation updated.
- [ ] Release / change communications completed (if needed).
- [ ] Outcome metrics captured and reviewed.

    Example

    • All 14 stories accepted; no open Critical or Major bugs.
    • Support runbook and onboarding guide updated.
    • Customer and team announcement sent.
    • Time-to-first-order reviewed 60 days after launch and reported to the steering group.