Home → Part 08
Epic, Story, Task: How to Break Work Down and the 8-Hour Rule
There is a card on the board: "Payment integration." It has been in the "in progress" column for three days. The answer is always the same: "almost done." This post is about that card.
- Epic is why, story is what, task is how. They are not three sizes of the same thing; they answer different questions.
- A task must not exceed one day. The reason is visibility, not estimation: there is no such thing as "60% of a two-day task".
- Stories are cut vertically, and so are tasks. Splitting into "API", "database", "screen" is the easiest and most fragile way.
- If you cannot split it, you have not understood it. That is a clarity problem, not an effort problem.
Let us put those three words in their place
In most teams, epic, story and task are used as if they were the same thing in different sizes: big is an epic, medium is a story, small is a task. That is not what they are. Each answers a different question, and mixing them makes the backlog meaningless.
| Level | Question | Audience | Duration |
|---|---|---|---|
| Epic | Why are we doing this? | Business, leadership | Several sprints |
| Story | What comes out, and for whom? | PO, team, QA | Fits in one sprint |
| Task | How will we build it? | The team only | Less than a day |
The critical distinction: a story can ship on its own, a task cannot. When a story is done, a user out there can do something they could not do before. When a task is done, only the team knows something. That single sentence settles most arguments.
A real example: the returns process
Let us get concrete. In an online store, returns go through the call centre. The customer calls, an agent creates the return by hand. 400 calls a day, four minutes each. The business goal is obvious: reduce that load.
Let customers start a return themselves.
Target: cut return calls by 60%. Estimated 2–3 sprints. This line carries the why, and six months later it is the answer to "why did we build this?". An epic is not delivered; it is closed.
Now let us split it into stories. Note that we are not saying "first the screen, then the service". Each piece is cut so it is useful on its own:
- S1 — As a customer I want to open a return request for a delivered order, so that I do not have to call the call centre.
- S2 — As a customer I want to see the status of my return, so that I do not have to call to ask.
- S3 — As an agent I want to see incoming returns in one list and approve them, so that I do not have to open a separate screen for each.
- S4 — As a customer I want my return shipping code on screen, so that I do not have to wait at the courier office.
All four can ship independently. Even shipping only S1 has value: the customer opens the request and an agent processes it manually behind the scenes. Call volume starts dropping in the very first sprint. That is what a "vertical slice" means.
Now down to tasks
Take S1: "Let the customer open a return request." Most teams open these three cards:
- Backend development 3 days
- Frontend development 2 days
- Testing 1 day
Three cards, six days. And none of them tells you anything mid-sprint.
- Return request table + migration 3h
- POST /returns endpoint, happy path 5h
- Eligibility rule: 14-day check 4h
- Error response for ineligible orders 3h
- Return form screen (static) 5h
- Wire the form + show errors 4h
- Notification email to the agent 3h
The total is the same. The only thing that changed is visibility. On day two the daily no longer produces "still on the backend" but "endpoint and rule are done, I am on the error response". Halfway through the sprint, the board tells you where you actually are.
The 8-hour rule: why not longer than a day
The rule is simple: no task longer than one day. It is commonly mistaken for estimation discipline. There are four real reasons and none of them is about estimates.
- Progress becomes unmeasurable. There is no "60%" of a three-day task; that percentage is a feeling. A one-day task has two states: done or not. No feelings.
- Being stuck is noticed late. On a three-day task people say "I will handle it" until the end of day two. On a one-day task, not being done the next morning is a signal everyone sees.
- Estimation error grows. On a one-day estimate you are wrong by hours. On a five-day estimate, by days. Same uncertainty, different bill.
- Work cannot be handed over. When someone falls ill, handing over a half-finished three-day task is nearly impossible. In one-day pieces it works.
And there is a side effect, which is my favourite part: if you cannot split work into one-day pieces, you have not understood it yet. Being unable to split looks like an effort problem but it is not; it is a clarity problem. So "this just does not split" is not an objection, it is a diagnosis — and the treatment is obvious: understand it first.
How to split: six ways to cut
1. By flow: happy path first
Make the everything-works scenario one task and the error cases another. In the example above, "POST /returns happy path" and "error response for ineligible orders" were split this way. Once the happy path is done you have something to show, and the error paths can be finished one by one.
2. By data: one type first
Five payment types? Make the first task credit card only. The rest are separate tasks. Usually the first type establishes the structure and the others take two hours each. Teams that do this backwards say "let us think about all of them at once" and spend two weeks designing an abstraction.
3. By rule: the simple case, then the exceptions
"Returnable within 14 days" is one task. "7 days for promotional items, no returns on hygiene products" is another. Rule exceptions almost always take longer than expected; putting them on the same card inflates it.
4. By operation: reads before writes
Listing and viewing are usually quick and deliver value immediately. Create, update and delete go separately. Making a whole CRUD screen one task is a classic way to produce a three-day card.
5. Separate the UI from the service — carefully
You can do this, but there is a condition: finish the screen with static data so it can be shown, then wire it. That way both tasks can be genuinely "done". Without that condition, "backend first, frontend later" leaves nothing to show until the last day of the sprint.
6. Separate the unknown into an investigation
"We do not know how the courier API works" is not a development task. It becomes a separate investigation, time-boxed up front (say four hours), and its output is a decision, not code. In teams that skip this, a "5-hour" task takes two days and nobody understands why; the cause is not difficulty in the code but a question with no answer.
"Database", "service", "screen" is the easiest and most common split. The problem: none of them works alone. Nothing can be shown until all three are done, and the surprise that appears during integration — and it will — lands on the last day of the sprint. If you must split by layer, at least take a thin vertical slice end to end: one field, one endpoint, one record.
Three common traps
| Card | Problem | What to do |
|---|---|---|
| "Analysis" task | No definition of done, always expands | Make it a time-boxed investigation whose output is a decision |
| "Testing" task at the end | QA drowns at sprint end, no time left to fix | Bake testing into every task's definition of done; do not open a card |
| "Refactor" task | Unbounded, takes three days, nobody knows what happened | Name the class and the goal: "split OrderService into two services" |
When has a story grown too big?
A practical measure: if a story's tasks do not fit in one sprint, it is no longer a story but a small epic. It needs splitting. The split point is usually obvious: wherever the word "and" appears. "The customer can open a return request and track its status" is telling you there are two stories.
The reverse holds too: if a task can ship on its own and does a user's job, there is no point keeping it a task — make it a story. The levels are not sacred; the point is to ask the right question in the right place.
Checklist
- Is this a story? If it shipped alone, would it help anyone?
- Are all tasks under 8 hours?
- Does the card title say what will be done, or is it "X development"?
- If something is unknown, is there a separate, time-boxed investigation?
- Is there a separate "testing" card? (Remove it; put it in the definition of done.)
- Is there a task that can reach QA by the end of day one?
- Does the story text contain "and"? (If so, it probably splits in two.)
Conclusion
Breaking work down is not a Jira habit, it is a way of thinking. The point of smaller cards is not a busier board but being able to see where you actually are every morning.
And back to the start: that "Payment integration" card, three days in progress, was really seven separate tasks. Three were done, one was blocked, three had not started — and nobody could see it. Because there was only one card.
How stories are written and how far acceptance criteria should go is in Grooming; how tasks are pulled during the sprint is in Sprint Planning.