Epic, Story, Task
What each level of the Jira hierarchy is for. Why skipping the Story layer turns every Epic into a pile of plumbing nobody can roadmap from.
Customers can pay with SEPA direct debit
Customers can pay with SEPA direct debit
Five Tasks under an Epic signal plumbing to everyone reading the board. The Epic's reason for existing evaporates between the description and the implementation list, and nobody outside the original author can tell what 'done' looks like for the Epic as a whole.
Each child of the Epic answers what a customer will be able to do that they couldn't before. Product can sequence them, design can spot friction, and the operational backfill is correctly tagged as a Task because no human benefits from it directly.
Auth refactor
See Figma. Lead: Mark.
Came out of last week's planning. Mark has the details.
Users stay signed in across tab reloads
Reloading or opening a new tab keeps the session, unless the session has actually expired.
Support has flagged dropped sessions as the top complaint this month. Users open the app in a second tab and lose their work.
A one-line description and a Figma link puts the why entirely in the original author's head. New joiners cannot tell what is being shipped, and there is no shared definition of when the Epic is done.
The Epic states the outcome, the reason it matters, and what is explicitly out. Six months from now, when nobody on the team remembers the original support complaint, the Epic still answers 'why did we touch the auth layer?' for itself.
Upgrade Next.js from 15 to 16
Upgrade Next.js from 15 to 16
Streaming preview in EDIT-218 only works on Next 16. This Task moves with that Story.
The subtasks are honest and the work is real, but the Task is an island. Nobody reading the board can answer 'why now?' without asking the author. If the Story it was meant to unblock slips, this Task sits in a corner with no signal.
Plumbing is correctly shaped as a Task, and the link to EDIT-218 anchors it to the user value it unblocks. When that Story moves on the board, this Task moves with it. When the team sequences the sprint, they can see which user-facing work sits behind the upgrade.
Users stay signed in across tab reloads
Users stay signed in across tab reloads
Building an entire authentication feature for an unrelated payment Epic is not a Subtask, it is its own Story under a different Epic. Subtasks should be implementation steps inside one work item, not separate features smuggled in.
Each Subtask is engineering detail inside the parent Story, scoped narrowly enough that it doesn't need its own acceptance criteria. The parent Story's Connextra and AC speak for the whole bundle.
Admin tooling
Admins can self-serve team membership
Subtasks hung directly off an Epic skip the Story layer entirely. There is no shippable, demoable unit between 'Epic' and 'engineering detail', so progress can only be reported as a percentage of subtasks, not as features delivered.
Each Story names an admin action, which gives QA a thing to verify and product a thing to demo. The schema migration stays a Task because no admin sees it. Subtasks would live inside each Story, not directly under the Epic.
Search v2
Readers find articles by topic and date range
All-Task children describe the implementation, not the user-visible change. Without a Story layer, the Epic's name 'Search v2' has to carry the meaning, and 'v2' tells you nothing about what readers actually gain.
Reading just the children, you can answer 'readers will be able to filter by topic, narrow by date, and see match snippets.' The infrastructure swap stays as a Task because readers don't see it. The Story layer is what makes the Epic readable to people who weren't in the planning meeting.