Home → Part 08
Epic, Story, Task: How to Break Work Down and the 8-Hour Rule
There is a card on the board: "Create return request." 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.
- One day is a good ceiling. Not a sacred number; the reason is visibility, not estimation: there is no such thing as "60% of a three-day task".
- Stories are cut vertically, and tasks as far as possible. Splitting into "API", "database", "screen" is the easiest and most fragile way.
- Work that will not split is usually work that is not understood. Usually a clarity problem rather than an effort one — though some work genuinely does not split.
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 | A day at most |
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: reduce 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 second list adds up to 27 hours, the first to 48. In this example it shrank, because "backend, 3 days" carried padding for not yet knowing exactly what would be built. It does not always go that way: splitting also surfaces sub-tasks nobody had noticed, and the total grows. Both happen and both are fine; the real gain is not time, it is visibility. Testing is not a separate card, it lives in every task's definition of done (below). On day two the daily no longer produces "still on the backend" but "table and endpoint are done, I am on the rule". Halfway through the sprint, the board tells you where you actually are.
The 8-hour rule: why not longer than a day
The measure I use is this: a task should preferably not exceed one day. Let me say up front that this is not a Scrum rule — it appears in no guide; it is a default I have seen work in the teams I have run. There is no magic in eight hours either: I pick a day because it is the practical version of "the card should change state between two dailies".
The limit is commonly mistaken for estimation discipline. There are four reasons it earns its keep, and only one 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.
There is a side effect too, which is my favourite part: being unable to split work into one-day pieces usually means the work is not understood yet. It looks like an effort problem; in the cases I have seen it has mostly turned out to be a clarity problem. So I read "this just does not split" not as an objection but as a signal worth one more look: does it really not split, or is it not yet clear how it will be done?
The answer is not always the same, though. Some work genuinely does not split, and accepting that beats cutting a card in half for the sake of it:
- Measuring an unknown. A time-boxed investigation can run past a day; halving it does not add information.
- First contact with an unfamiliar codebase. The learning cost is paid once; splitting does not remove it, only spreads it.
- Waiting on an external dependency. Third-party approval, infrastructure access. Splitting does not shorten the wait, and the wait already sets the visibility.
- Work that cannot be left half-done. A one-off data migration has steps, but you cannot stop in the middle of it.
In those cases I do not force the card; I write the reason on it: "two days, because we are waiting on team X". The point of the limit was never to shrink cards, but to make it visible why a long card is long.
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 the definition of done. A separate card only earns its place when it is real work of its own: regression automation, load testing, external penetration testing |
| "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 tasks a day at most? If not, does the card say why?
- 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? If so, is it real work of its own, or does it belong 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.
The thresholds here are the ones that have worked in my teams; in yours, half a day or two days may fit better. What decides it is not the number itself but whether that number tells you where you actually are.
And back to the start: that "Create return request" card, three days in progress, was the seven separate tasks in the list above. 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.