Tasks, Epics, and the Work That Matters

This guide covers the core vocabulary behind AbleTime: what Tasks and Epics are, how they relate to Projects, and the distinction between Work and Overhead. These concepts come up throughout the application and in every other guide, so it is worth reading this one first.

What Is a Task

A Task is the smallest unit of planned work. When a Task is done, you should be able to point to what it produced — a new feature, a fixed bug, an updated process, a delivered asset. If you are already familiar with workflows like Agile or Scrum, you can map these to User Stories or Issues. It represents a single, concrete piece of work that one person can complete in a bounded timeframe.

Each Task is tied to a Category (which in turn ties it to a Project), and can optionally be tied to an hour estimate for completion, an assigned user and a lifecycle that moves it through states: Backlog, To-Do, Doing, Done, and Archived. The transition from To-Do to Doing happens automatically when a time entry is logged against the Task.

A good test: when this Task is marked as done, can you point to something new that exists? If yes, it is a Task. If not, it is probably Overhead.

What Does Not Qualify as a Task

Meetings, standups, and coordination calls do not produce a deliverable. They are necessary, but they are Overhead — not Tasks.

You should not Overhead with "Bad". Overhead is absolutely necessary in any business, but it is also very important to track separately from Tasks. You need to make sure the amount of Overhead being spent does not conflict with your expectations of available Capacity.

Vague goals like "improve performance" are not Tasks either; they need to be broken into concrete actions that each produce a measurable result. Open-ended, multi-week work that cannot be scoped to a single person and a clear done state is an Epic or multiple Tasks, not one Task.

Why Estimates Matter

Every Task can have an estimated number of hours. Estimates are rarely exact, and that is fine. Their value is not precision — it is creating a baseline. With estimates in place, AbleTime can show you estimated vs. actual hours on every Task card, in the Epic view, and in progress reports. Without them, progress tracking becomes guesswork. With estimates and a steady progression of closed/completed tasks, you gain the opportunity to improve your estimation skills, not on "gut feeling" but hard evidence.

There are also specific metrics that will help you make better estimates as time goes on. The Time Flow / Pulse Dashboard and Progress Reports surface metrics like Accuracy which tell you if your estimates are on average below or above what you initially estimated. If at the end of the project your Accuracy is 92%, you spent less time completing the work than you estimated. If it is 104%, you exceeded your estimate. The graphs, ledgers and Timeline will also help you identify which tasks completed faster and those that did not.

What Is an Epic

An Epic is a container of Tasks aimed at a specific, shippable outcome. When the Epic is complete, something tangible exists that did not exist before — a new feature, a completed migration, a delivered report. Epics are how AbleTime groups related Tasks so you can track scope, progress, and hours across a body of work.

Name your Epic after what it delivers, not how you work on it. "Client Portal" tells you what is done when it is done. "Q2 Work" does not.

How Big Should an Epic Be

A practical guideline is 3 to 15 Tasks per Epic. Fewer than 3 and the Epic is probably just a Task — there is no benefit to wrapping it. More than 15 and the scope is likely too broad or it contains work that should be split into separate Epics.

No Epic should ever have just a single Task, otherwise you are just treating them as folders or containers. Not every Task belongs in an Epic. In fact, tracking Tasks that live outside Epics is a good way to keep track of unplanned work when it occurs in small windows or as one-off Work. Again, tracking these separately from product work is very important (see Work, Overhead and Flow).

When a Task Becomes an Epic

Often when you are planning, you realize what initially felt like a Task is becoming more complicated. Good indications your task is actually an epic are:

multiple people need to be assigned to it. A task should only ever have one person assigned to it at a time
there is work that must be completed first or last, like design or testing
you anticipate more work will be attached to the task at a later date, like testing or rework.

When this happens, you can choose "Elevate to Epic" from the Tasks panel and then split out the work among as many tasks as you need. Note, however, that this is only available if a Task has no hours tracked against it. If it does, you will have to create the Epic separately and then add the Task.

If an Epic keeps growing beyond its original scope, that is scope creep. Consider splitting it into two Epics with clearer deliverables rather than letting one Epic absorb everything.

The Hierarchy: Project, Epic, Task

AbleTime organizes work in three levels, each answering a different question:

Project — who is this for? Projects exist underneath Clients (the Client could of course be you!). It holds Time Flow settings, personnel assignments, and Categories. Nearly everything in AbleTime — time entries, Tasks, Epics, reports, invoices — belong to a specfic Project.
Epic — what are we delivering? An Epic groups the Tasks needed to produce a specific outcome. A Project may contain many Epics across its lifetime.
Task — what work produces it? A Task is a single action that contributes to an Epic's deliverable. It is completable by one person and has a clear done state.

This hierarchy is how AbleTime connects planning to actuals. A time entry logged against a Task flows up to the Epic and to the Project. Estimated hours vs. actual hours are visible at every level.

Work vs. Overhead

In AbleTime, Work means Tasks that produce a deliverable. When a Task is completed, something new exists. Overhead means the necessary activities that do not directly produce a deliverable — meetings, coordination, mentoring, training, and general administration.

Critically, overhead is not waste. It is an essential part of running an organization. That said, it needs to be tracked separately from Work so you can understand your real Capacity. If a team member has a 40-hour week but spends 20 hours in meetings and coordination, planning 40 hours of Task work against them will consistently overcommit that person.

Track Overhead as time entries against appropriate Categories like "Meetings - Internal" or "Training", but do not turn meetings into Tasks inside your Epics. That hides the distinction between what your team is delivering and what your team is spending time on.

For a deeper look at how AbleTime applies this thinking — including the four types of work (Business Projects, Internal Projects, Changes, and Unplanned Work) and how to find bottlenecks in your delivery — see Work, Overhead and Flow in the Project Management section.

Common Mistakes

These are structural mistakes that silently degrade your metrics, visibility, and delivery predictability. They are easy to make and expensive to fix once habits are established.

The "folder" Epic. One Task inside an Epic. Progress is binary — 0% or 100%. Burn rate is meaningless. The Epic view becomes a flat task list with extra clicks.
The "catch-all" Epic. 40 or more Tasks mixing deliverable work, meetings, and administrative tasks. Metrics become noise because the Epic conflates different types of work.
The "phase" Epic. Named "Sprint 12" or "Q2 Work" instead of after a deliverable. These are time-based labels, not outcome-scoped containers. Use Milestones/Cycles for time-based markers and capturing the Tasks that are completed within them.
Overhead disguised as Tasks. Turning meetings into Tasks to fill the Gantt chart. Capacity looks 100% utilized, but deliverables are not moving. The team looks busy without producing results.