What are Epics in Project Management?
Epics in Project Management
An epic is a large body of work too big to finish in one sprint, broken down into smaller stories or tasks that can each be completed and shipped on their own.
An epic is a large piece of work too big to finish inside a single sprint, big enough that it needs to be broken into smaller stories or tasks before anyone can realistically estimate or start it. Where a task is something one person finishes in a day or two, an epic is the container that holds a whole feature, campaign, or deliverable until it's broken down small enough to act on.
The term comes from Agile backlogs, sitting between the highest-level initiative (a company goal) and the individual story or task a person actually works on day to day. But the underlying problem it solves, some work is genuinely too big to estimate or assign as one unit, applies to any team planning multi-week deliverables, Scrum or not.
Epics fail in two directions. Left too big, they become a junk drawer that absorbs loosely related requests for months without ever closing. Broken down too aggressively, every piece of a project turns into its own epic and the hierarchy stops meaning anything. The right size and the right split are the two decisions that make epics useful instead of decorative.
Where Epics Sit in the Work Hierarchy
Work breaks down through a few levels, each one small enough to be estimated and owned by the level below it.
| Level | Scope | Typical duration | Owner |
|---|---|---|---|
| Initiative | A company or quarterly goal | 1+ quarters | Leadership |
| Epic | A feature or major deliverable | 2-6 weeks | One accountable owner |
| Story / Task | One shippable piece of the epic | 1-3 days | One person |
| Subtask | A step inside a task | Hours | One person |
How Big an Epic Should Be
An epic that's genuinely doing its job typically covers two to six weeks of work for a small team, and breaks down into roughly eight to twenty-five individual tasks. Outside that range, something is usually off.
Too small (finishes in a few days, breaks into 2-3 tasks) and it should just be a task with subtasks; the epic label adds overhead without adding clarity. Too large (runs for months with no clear end, absorbs dozens of loosely related requests) and it's stopped functioning as a planning unit and become a catch-all that needs to be split.
How to Split an Oversized Epic
The most common mistake when splitting an epic is dividing it by task type, all the design work in one branch, all the development in another, which means nothing is usable until every branch finishes at the same time. A better split divides the epic by shippable slices of value, where each piece can go live on its own.
Four techniques that work in practice: split by user workflow step (login, then browsing, then checkout), split by platform or variant (desktop first, mobile second), split by priority or MVP slice (core function first, edge cases and polish later), and split by data type or scope (one client type before all client types).
Splitting an Epic: A Worked Example
A 10-person agency scopes an internal tool as one epic: "Build client portal." As written, it's 14 weeks of work with over 60 tasks and no clear midpoint, too large to plan a sprint around or report progress on. Splitting it by shippable slice turns one unmanageable epic into five that can each ship and close independently.
| Epic slice | Tasks | Duration | Ships on its own? |
|---|---|---|---|
| Login and single-project view | 12 | 2 weeks | Yes |
| Invoice history and download | 8 | 1.5 weeks | Yes |
| File upload and sharing | 10 | 2 weeks | Yes |
| Notifications and comments | 9 | 1.5 weeks | Yes |
| Branding and white-label settings | 6 | 1 week | Yes |
Owning and Tracking an Epic
Every epic needs exactly one accountable owner, the person who can say whether it's on track, even if five different people are doing the actual work inside it. Without one owner, each contributor reports their own slice as fine while the epic as a whole quietly stalls.
Progress on an epic should roll up from its child tasks: percentage of tasks completed gives a reasonable proxy, as long as tasks are similarly sized. An epic is done when every task inside it is done and the epic's own closing criteria, not just the tasks', have been checked, things like a final client walkthrough or a combined QA pass across all its slices.
Why Epics Stall
Two failure patterns account for most stalled epics. The junk-drawer epic absorbs every vaguely related request that comes in, growing indefinitely instead of closing, until nobody remembers what finishing it was even supposed to look like. The zombie epic sits at 80% complete for months because the last few tasks, usually the least interesting ones, keep getting deprioritized in favor of newer work.
Both are symptoms of the same missing piece: an epic without its own closing criteria, separate from its child tasks' Definition of Done, has no natural end point and just keeps absorbing scope.
In Melororium
Break epics into tasks and subtasks in Melororium
Common mistakes with epics in project management
What teams get wrong most often, and what to do instead.
- 1
Naming an epic after a department instead of an outcome
"Marketing Work" tells nobody what done looks like. "Launch Q3 Content Calendar" does, and gives the epic a real closing point.
- 2
Splitting an epic by task type instead of value
Breaking a portal build into "all design tasks" and "all dev tasks" instead of shippable slices means nothing is usable until every branch finishes at once, which defeats the point of splitting it at all.
- 3
Letting one epic run indefinitely
An epic with no target sprint and no closing review becomes a permanent bucket that new, loosely related work keeps getting added to instead of finished.
- 4
No single owner for an epic that spans three teams
Without one person accountable for the whole thing, each team reports their own slice as fine while the epic as a whole never actually comes together.
Frequently asked questions
What's the difference between an epic and a task?
A task is something one person can finish in a day or two. An epic is too large to estimate or assign as a single unit, so it gets broken into multiple tasks or stories first. An epic is a container; a task is the actual unit of work.
How many tasks should an epic have?
There's no fixed rule, but roughly 8-25 tasks and 2-6 weeks of total work is a reasonable range for a small team. Fewer than that and it's probably just a task with subtasks; more and it likely needs to be split.
Does Melororium support epics?
Melororium doesn't have a separate "epic" object. Teams model epics as a task with subtasks, or as a project phase, since tasks already carry subtasks with their own timers and due dates, which covers the same hierarchy without an extra layer of setup.
Can an epic span more than one project?
It can, but it gets harder to track progress and assign one clear owner. Most teams get better results keeping an epic inside a single project and treating cross-project work as its own initiative above the epic level.
Who decides when an epic is done?
The epic's owner, checking the epic's own closing criteria (not just whether all child tasks are marked done). A final review or combined QA pass across all its slices is often part of that criteria.
