“Epic vs Feature vs Story vs Task”

epic vs feature vs story vs task is a key topic in modern project management and teamwork. A team spends a week turning a 40-page product brief into 312 tickets. Six months later the roadmap says “checkout redesign: 68% complete”, and nobody can explain what the missing 32% is, because the backlog contains 108 tasks with no parent, 14 stories that are really features, and three “epics” that are single afternoons of work. The hierarchy did not fail because people used the wrong words. It failed because the words had no size attached to them.

Epic, feature, story, and task describe four levels of one hierarchy, and the only thing that makes them useful is an agreement about scale, ownership, and estimation unit at each level. Teams that define the levels but not the units end up with stories estimated in months and epics that close in a week, which destroys forecasting without producing any visible error.

This guide gives you the working definitions, a hierarchy table with estimation units and expected counts per parent, and the arithmetic that keeps the four levels honest.

What is the difference between an epic, a feature, a story, and a task?

Short answer: an epic is a large body of work spanning weeks to months that you can only finish by completing several features. A feature is a coherent, user-visible capability that takes one to three sprints. A user story is a single sliver of that capability, written from the user’s perspective and completable inside one sprint. A task is the hours-level unit of execution a developer picks up on a Tuesday morning.

The confusion starts because the same noun appears at different levels in different companies. One product team’s “feature” is another’s epic. The test that resolves it is not the label but the answer to three questions: how long is it, who owns the outcome, and what unit do you use to estimate it?

• If the answer is “a quarter, the product manager, and a number of periods”, it is an epic.
• If the answer is “two to six weeks, the product manager with a tech lead, and a point range in the dozens”, it is a feature.
• If the answer is “under two weeks, the team, and story points”, it is a story.
• If the answer is “under a day, one person, and hours”, it is a task.

Anything that cannot answer all three consistently is mislabeled, and mislabeled work is the root cause of most “our velocity chart is nonsense” complaints.

What is the full hierarchy with estimation units?

Use this table as the convention document. Paste it into your team wiki and change the numbers to fit your context, but change them once and keep them.

Two conventions do the heavy lifting here. First, only stories get story points. Points on epics and features are a planning shorthand, not an estimate, and mixing them produces the classic error of comparing a 34-point epic to a 3-point story as if the units were the same. Second, tasks are estimated in hours and should not exceed eight, because a task that cannot be finished in a day cannot be tracked honestly.

The “expected children” column is the most useful part and the one teams skip. It tells you when a level is misused: three features under an epic is thin, and 30 stories under a feature means the feature should have been an epic.

How do you size a whole epic from the bottom up?

Short answer: count the stories, multiply by the average story point value, divide by velocity to get sprints, then add a buffer for discovery and integration. Do the arithmetic before committing to a date, not after.

Worked example 1 — sizing a checkout epic. A payments epic decomposes into four features: saved payment methods (9 stories), address validation (5), multi-currency pricing (7), and receipt emails (4). Total: 25 stories. Historical average story size is 3.4 points, so the story load is 25 × 3.4 = 85 points.

Team velocity is 42 points per two-week sprint. Base duration: 85 ÷ 42 = 2.02 sprints, or about four weeks of delivery work. Now add the parts that are not in the point total:

• Discovery and vendor selection: 8 working days.
• Integration and regression testing: 15% of build effort = 0.3 sprints.
• One week of buffer for a compliance review.

Realistic calendar estimate: four weeks of build, two weeks of discovery, one week of testing, one week of buffer — eight weeks, against a naive estimate of four. That gap is exactly why epics are sized in periods rather than points.

How many tasks should sit under a story?

Short answer: two to six. Fewer means the story was really a task; more means the story was really a feature and should be split.

Tasks are where estimation finally touches reality. A story with no tasks cannot be started by a developer without a conversation; a story with 14 tasks will sit “in progress” for nine days and make the board look broken.

Worked example 2 — story to task decomposition. The story “As a returning buyer, I want my saved card to appear at checkout so I can pay in one tap” is estimated at 5 points. Break it down:

At roughly four productive engineering hours per point in this team’s history, 5 points predicts about 20 hours. The task list lands at 19. That agreement is not luck — it is what happens when both levels are estimated honestly. When task hours total 60% of the point prediction, one of the two numbers is fiction.

What is the right ratio between levels?

Short answer: approximately 1 epic : 3–8 features : 15–40 stories : 50–150 tasks. Ratios outside that band almost always indicate relabeling rather than genuinely unusual work.

The ratio is a cheap audit. Pull a random sample of epics from your tracker and count descendants.

Worked example 3 — the two-level model, costed. Some teams deliberately skip features and run epics straight into stories. That is fine, with one caveat: reporting granularity disappears. A 40-story epic at 3.4 points average is 136 points. At a velocity of 42, that is 3.2 sprints of work with no intermediate milestones, so stakeholders get no signal until the epic is 70% done.

Adding the feature layer costs about two hours of product-manager time per epic to define the slices. In return you get four checkpoints instead of one. If an epic slips, you learn it in week three rather than week nine — usually worth more than the two hours.

How do estimation units change with team size?

Short answer: the units stay the same, but the meaning of a point inflates with team size, which is why cross-team comparisons of velocity are meaningless.

A five-person team might average 30–40 points per sprint; a twelve-person team might average 70–90. That does not mean the larger team is twice as productive. Points measure relative effort within one team’s own history, and nothing else.

What does scale is the number of levels you need. Below eight engineers, a two-level model (epic → story, with tasks as checklist items) works well and reduces ceremony. Above twenty engineers, you need the feature level plus a clear owner for each feature, or planning becomes a negotiation between twelve people in one meeting.

Worked example 4 — sprint capacity versus story load. A six-engineer team has 12 working days per sprint each, minus two days of meetings and reviews, giving 10 productive days. At 6 hours of real focus per day, that is 60 hours per person, or 360 hours per sprint. At the team’s 4 hours per point, capacity is 90 points — but the last three sprints delivered 38, 44, and 41 points, so the honest number is 41.

The gap between theoretical and historical capacity is 55%. Teams that plan against the theoretical number overcommit every sprint and then describe themselves as bad at estimating. They are not bad at estimating; they are planning against arithmetic that no one verified.

How do you handle spikes, enablers, and technical debt in this hierarchy?

Technical work has no user-facing outcome, which is why it keeps escaping the hierarchy and landing in a folder called “misc”. The clean solution is to classify it rather than hide it.

A spike is time-boxed research with a question as the deliverable, not code. Size it in hours or days, cap it, and attach the answer as a decision record. A two-day spike under a feature is normal; a two-month spike is an epic pretending to be research.

An enabler is infrastructure work a feature genuinely depends on: a queue, a migration, an API contract. Model it as a story with a technical persona (“as the platform, we need…”) so it carries acceptance criteria and appears in the same backlog as everything else.

Technical debt is best treated as an epic with a measurable goal, not a bottomless label. “Reduce checkout p95 latency from 1,800 ms to 600 ms” is an epic with features; “tech debt” is a feeling.

The ceilings matter more than the labels. When a spike passes its time box, the outcome is a decision, not a silent extension.

Why do teams keep misusing these four words?

Four mechanisms explain nearly every case.

Tool defaults. Most trackers let you rename issue types freely. When “epic” can be any shape, teams use it for whatever needs a colored label. Convention beats configuration: publish the table above.

Roadmap pressure. Executives ask for dates, so a PM splits work until it looks schedulable. Splitting an epic into 30 stories makes the plan look detailed and the forecast no more accurate. Detail is not precision.

Estimation anxiety. Story points feel abstract, so teams convert them to hours, then estimate in hours but call them points. The unit becomes a rumor, and velocity becomes uncomparable across sprints.

Ceremony without definitions. Refinement sessions argue about acceptance criteria while the item’s level is wrong. A five-minute level check at the start of refinement — duration, owner, unit — prevents most of it.

What are the trade-offs of a strict hierarchy?

A strict four-level hierarchy buys forecasting accuracy and costs speed. Every level needs a title, a description, an owner, and a link to its parent, and in a small team that is real overhead for work that will be done by Thursday.

A loose hierarchy buys speed and costs traceability. Two levels and a good board can run a startup for two years. The cost appears later, when someone asks which customer-facing capability got delayed and the answer requires reading 200 tickets.

The workable middle is asymmetric: enforce the hierarchy on anything that crosses a quarter boundary, and let anything smaller be a story or task. That keeps the roadmap honest without turning Friday’s bug fix into a four-level tree.

There is also a reporting trade-off. Feature-level tracking gives stakeholders meaningful percentages, but only if features are sized comparably. A feature ratio of 9 stories to 22 stories makes “50% of features complete” a number that means nothing. Normalize feature size before you publish a completion chart.

How does Doitify handle this hierarchy?

Doitify is our product, so treat this as disclosure rather than review. It uses projects, tasks, sub-tasks, checklists, owners, and due dates as its native structure, with boards, Gantt charts, roadmaps, calendars, and workload views over the same items. Goals link upward to the work that serves them, and Doitify Copilot can turn a stated goal into tasks, sub-tasks, and a plan.

That maps cleanly onto a three-level model — goal or epic, story-level task, and sub-task — without requiring you to configure a separate issue-type hierarchy. It is not a Jira replacement for organizations that need 40 custom issue types, cross-project dependency graphs, and portfolio-level program management. If your hierarchy discipline lives in a scaled agile framework, keep the tool that supports it and apply the estimation units above; if your problem is that nobody can see how daily work connects to quarterly goals, a flatter native structure is an advantage.

Conclusion

Epic, feature, story, and task are not four opinions about how to name work. They are four time horizons with four estimation units, and the hierarchy only works when duration, owner, and unit agree at every level. Get that agreement in writing, put the table in your wiki, and audit the ratios once a quarter.

Then use the numbers rather than the labels. A story over eight points, a task over a day, an epic with two features, or a team planning against theoretical capacity are all the same failure wearing different badges: a level doing a job it was not sized for. Fix the size and the vocabulary fixes itself.

If this post on epic vs feature vs story vs task was helpful, you might also enjoy How to Turn Meeting Notes Into Action Items (Step-by-Step) and Project Management Software for Architecture Firms in 2026.