Epics vs user stories: how to split work that ships

The relationship is one of scale. An epic is a large body of work — too big to finish in a single sprint, spanning weeks. A user story is a small, sprint-sized slice of that work. "Let users manage their subscription" is an epic; "let a user cancel their subscription" is one story inside it.

The hard part isn't the definition — it's splitting an epic into stories that each still mean something.

The wrong way: split by technical layer

The tempting, broken way to break down an epic is along architectural lines: a "backend story," a "frontend story," a "database story." Each is sprint-sized, so it looks like a valid split. But none of them delivers anything a user can see — you can't ship "the backend half of cancellation." Layer-splitting produces fragments that only have value once all of them land, which kills the whole point of incremental delivery and hides progress from stakeholders.

The right way: split by thin end-to-end slices

Split so each story goes all the way through — UI to data — and delivers a smaller but complete piece of user value. For the subscription epic:

• Story: a user can view their current plan and renewal date.
• Story: a user can cancel, effective at period end.
• Story: a user can switch to a different plan.
• Story: a user gets an email confirming a plan change.

Each is independently shippable and independently valuable. You could release "view current plan" alone and a user would benefit.

Common split patterns

When a story is still too big, split it by: workflow steps (each step a story), business rules (the simple rule first, edge cases later), happy path vs error handling, or data variations (one input type first). The goal every time is a thinner complete slice, never a disconnected piece. If a proposed story can't be demoed to a user on its own, it's probably a layer, not a slice — keep splitting differently.