Getting the Most Out of Epics
Epics are "end goals". An Epic collects the Tasks that, completed together, produce something tangible you can hand over. Used well, an Epic tells you at a glance how far a deliverable has come, what it has cost against its scope, and when it's time to intervene. Used as a filing system, it tells you nothing. This guide covers what belongs in an Epic and what doesn't, how to scope one, how to read its health, and the three decisions that keep Epics honest: split, promote, and close.
What an Epic is, and isn't
An Epic is meant to deliver something that didn't exist before: a shipped feature, a completed migration, a delivered engagement. The test for membership is the Definition of Done: if a Task doesn't contribute to what the Epic delivers, it doesn't belong there.
Avoid using Epics as folders. They aren't for organizing categories of work ("Design", "Bugs", "Client X"); categories, tags, and projects already do the sorting. A folder Epic never closes, its scope means nothing, and its hours-against-scope reading is noise, which defeats the one thing an Epic is for.
A Task on its own is perfectly legitimate when it's an isolated piece of work. Not everything belongs inside an Epic. The working shape is simple: a Task is one piece of work one person can finish; an Epic is the collection of pieces that adds up to an outcome. When there's no larger outcome, there's no Epic.
The four types of work
AbleTime's planning model recognises four types of work, and each type keeps to its own Epics so the numbers stay readable.
Business Projects — the value work: deliverables your customers see. These Epics hold only Tasks that move the needle on the deliverable.
Internal Projects — the foundational work customers don't see: shared assets, internal tooling, refactoring. Internal work gets its own Epics and never mixes with external work, so you can see your investment-versus-feature ratio. Hiding "refactor the API" inside a "User Login" Epic buries that signal.
Changes — planned maintenance: pre-approved, low-risk, short. A change that takes more than a few hours likely belongs in an Internal Project, and a 40-hour "Monthly Maintenance" catch-all Epic is the failure mode, not the pattern.
Unplanned Work — the friction: the most destabilising type and the most important to keep visible. Never disguise it as planned Tasks; capacity that looks fully utilised while the team drowns in interruptions is exactly the illusion this type exists to expose.
Meetings, coordination, training, and general organisation are Overhead, not an Epic of any type.
Overhead isn't waste, it is an important category of work. As such it must be measured separately from 'delivery' work: a designer with 40 hours of weekly capacity who spends 20 in meetings can't be planned at 40.
The payoff of keeping the types separate is that your real constraint becomes visible, and any improvement not made at the constraint is an illusion. The full model is on Work, Overhead and Flow.
Scoping an Epic
Create the Epic from Time Flow → Epics with + Epic, and give it a Title you can point at when it ships: the portal, the import, the first invoice run, never the week or the phase. Put Tasks under it with + Task, or pull in loose ones with Add Existing, each one something one person can finish, each estimated. Scope is the sum of those estimates, and it's the number every health reading runs against.
An Epic in Backlog holds its children in backlog; Activate moves it to Active and pushes those children to todo. Activate when you're ready to work the slice, not before.
Reading Epic health
Health is one comparison and one shape. The comparison is Hours against Scope: on the Epics list the figure warms and then turns red as logged time overruns the estimate, and Burn% on the Dashboard's Epic Ledger gives the same reading as a percentage. The shape is the todo / doing / done split: work piled in todo with nothing in doing hasn't started, and work piled in doing with little done isn't finishing.
Neither number is a verdict on anyone. An overrun tells you the scope was wrong or the work grew; the split tells you where the flow is stuck. Both are prompts for one of the three decisions below. For the full screens behind these readings, the Epics list and Epic page are on Epics, the Epic Ledger and Pressure are on Pulse, and the metric cuts (Scope Burned, Throughput, Velocity, Lead Time, Accuracy, Momentum) are on Progress Reports.
The three decisions
Split, when a Task no longer finishes as one piece. If one Task is dragging the Epic past scope, or is really two pieces of work wearing one title, split it: open the Task and use Split Task under Task Actions (available while the Task has a scheduled date and isn't Done). Time after the chosen date moves to the new Task. AbleTime splits Tasks, not Epics; an Epic that needs splitting is two outcomes, and the second one gets its own Epic.
Promote, when a Task was really the deliverable. A Task that needs children of its own has outgrown being a Task: use Promote to Epic under Task Actions (available on a backlog Task with no time logged and no Epic), then build the real Tasks under the new Epic.
Promote deletes the original Task: the dialog states that the Task becomes an Epic and the original is deleted, not archived.
Close, when the outcome is delivered, not when the list stops growing. If Tasks keeps climbing after the deliverable shipped, a second outcome is accumulating inside the Epic; move the leftovers to a new Epic and close this one. Archive on the Epic asks what happens to the children: Remove from epic (tasks remain active) keeps leftover work on the board, and Archive tasks with epic closes it out with the Epic.
An Epic that names an outcome, holds only the work that delivers it, and closes when it ships will read honestly on every screen. Field-level detail lives on Epics, Tasks, Split and Merge, Pulse, and Progress Reports, and the reasoning behind the four types is on Work, Overhead and Flow.