Epic vs story vs task

Most agile tools (Jira, Azure DevOps, Linear) ship with three tiers: epics, stories, tasks. The hierarchy is load-bearing only if each tier means something distinct. When teams point all three the same way, the tiers collapse and the planning signal goes with them.

Epic

A body of work bigger than a sprint — usually a feature or initiative the team will deliver across multiple sprints. Epics are sized in t-shirt sizes, weeks, or "story counts" (how many stories you think it'll decompose into), not story points. Points at the epic level are aggregations of the underlying stories, not direct estimates.

Story

A user-facing slice of work that fits in one sprint. Stories are what Planning Poker estimates. Points live here. The story is the unit of velocity, and the unit of "what we'll commit to this sprint."

Task

A child of a story — a checklist item, a piece of implementation. Tasks are typically sized in hours or not sized at all. Pointing tasks duplicates the story's points and makes velocity meaningless (you'll be counting the same effort twice).

The trap: pointing every tier

Some Jira workflows encourage pointing tasks under stories. Some tools push for pointing epics. Both habits produce velocity numbers that don't correspond to anything real, because effort is being counted at multiple levels of abstraction. Pick one tier — the story — and only point there.

See when the story is too big for what happens when a "story" is really an epic; should spikes have story points for the adjacent question of non-story tickets.