Epic, User Story and Task: The Difference, with Examples from Inside and Outside IT

An epic is a goal too big to fit in a sprint. A user story is a piece of that goal that delivers value to a person. A task is the concrete work someone does to deliver the story. The confusion happens because all three look like "things to do," but they answer different questions: what and why, for whom, and how.

Understanding the difference isn't Scrum fussiness. It's what lets you estimate, prioritize, and track without the board turning into a to-do list with no hierarchy. And it applies outside IT: marketing, operations, and customer service break work down the same way.

The three definitions

Level	Question it answers	Typical size	Who defines it
Epic	What big outcome do we want?	Several weeks or months; more than one sprint	Product or department owner
User story	What can a person newly do, and why?	Fits in a sprint, preferably in a few days	Product owner, with the team
Task	What needs to be done to deliver the story?	Hours or a day	Whoever will carry it out

Epic

An epic describes an outcome, not a list of activities. "Launch the ordering app" is an epic. So is "Reduce month-end close time." It's big on purpose: it serves to give direction and group stories. You don't "finish an epic in one sprint"; you track it through the progress of the stories inside it.

User story

The story describes what a specific person is now able to do, and the reason. The classic format helps you not forget any of the three parts:

As a [type of person], I want [action] so that [benefit].

The reason ("so that") is the part most often left out and the most valuable. It's what lets the team propose a simpler solution than the one requested. "I want an export button" is a solution. "I want to send the report to my client without redoing it in Excel" is a need, and may have a better answer.

Task

A task is the technical or operational work: build the screen, write the copy, configure the server, review the contract. It has an assignee and a simple state (to do, doing, done). If a task can't be completed by one person in a day, it's almost always a story in disguise.

How to break down an epic

Breaking down well is the core skill. A four-step roadmap works in most cases.

1. Write the epic's outcome in one sentence. If you need two, they're two epics.
2. List the people involved. Each type of person tends to generate its own stories: customer, agent, manager, finance.
3. Slice by value, not by layer. Avoid stories like "build the database" and "build the screen." Cut into thin slices that go through everything and already deliver something usable, even if simple.
4. Test each story. Is it independent of the others? Can it be estimated? Does it fit in a sprint? Can you verify that it's done?

Only afterward, and only for the stories that will go into the next sprint, drop down to the task level. Breaking everything into tasks months in advance produces a plan that will be redone: knowledge changes along the way.

Examples for software

Epic: let customers track their orders from their phone.

User story	Tasks
As a customer, I want to see my order status so that I don't have to call the store.	Build the order list screen; query the status via the API; handle an order with no response; test on a small phone.
As a customer, I want to get a notice when my order goes out for delivery so that I can plan my day.	Define the send trigger; write the message text; configure the sending; test with a real order.
As an agent, I want to see the same status the customer sees so that I can answer without checking inventory.	Show the status on the customer record; create a view permission; validate with an agent.

Examples for marketing

Epic: launch Loja Aurora's Black Friday campaign.

User story	Tasks
As a store customer, I want to see the offers on the home page so that I can buy without searching.	Choose featured products; create the banner; build the offers page; publish and check on mobile.
As a returning customer, I want to receive the offer by email before everyone else so that I get first pick.	Segment the list; write the email; get approval from leadership; schedule the send.
As a manager, I want to see sales by channel so that I can decide where to invest more budget.	Define the source channels; configure tracking; build the dashboard; test with one order from each channel.

Examples for operations

Epic: reduce month-end close time at the accounting firm.

User story	Tasks
As an accountant, I want to receive the client's complete documents by the 5th so that I don't have to chase them at the end of the month.	List the required documents; create the submission form; configure the client reminder; test with two clients.
As a coordinator, I want to see which clients haven't sent yet so that I can follow up before the deadline.	Build the view by client and status; define the follow-up routine; review at the Monday meeting.

Acceptance criteria: what says the story is done

A story without acceptance criteria turns into an argument at the end of the sprint. The criteria are the short list of conditions that, if met, make the story count as delivered. Write them before starting the work.

A good criterion is verifiable by anyone, without interpretation. Compare:

Vague criterion	Verifiable criterion
The screen should be fast.	The order list opens in up to 3 seconds with 200 orders.
The email should look good.	The email displays without breaking on mobile and has the buy button visible without scrolling.
The customer should be able to send the documents.	The customer uploads PDFs and images up to 10 MB and receives a confirmation with a reference number.

The numbers above are examples to illustrate the format; define yours based on what the user really needs. Three to five criteria per story are enough. More than that usually means the story is too big.

Common mistakes

• An epic that never closes. When the epic has no clear outcome, it becomes a drawer where anything gets thrown. Define when it will be done.
• A technical story with no user. "Refactor module X" isn't a story, it's a task or technical debt. If it has value for someone, write the benefit; if not, treat it as a task.
• A task longer than a day. Break it down. A big task hides delay until the eve of the deadline.
• Hierarchy for vanity. You don't need all three levels for everything. A small project can live on just stories and tasks, or even just tasks.

How this shows up in a tool

What matters is being able to group and see the progress of the whole. In Tasskee, the practice is to use task and subtask for the lower levels, and sprints for the cycles in which the team commits to a set of stories. Epics can be kept as workstreams or as parent tasks, depending on the team's preference. What doesn't work is leaving the big goal only in someone's head.

To start with a ready-made example, the backlog and sprint template brings the structure of a prioritized list and sprint planning, ready to adapt. After running a sprint, the burndown chart helps you see whether the work is moving: see how to read the burndown.

Rule of thumb

If you ask yourself "does this deliver value to someone on its own?" and the answer is no, it's a task. If yes and it fits in a sprint, it's a story. If yes, but it doesn't fit, it's an epic or a story too big to be broken down. With this thirty-second test, most of the argument about names disappears, and what's left is what matters: working on things in the right order.