Epic

The ordered list of what a team might build next is the product backlog. Write that list at a single level of detail and something breaks, whichever level you pick.

Write everything small and the list runs to 300 lines. Forty of them touch payments, scattered throughout, and reading from the top tells you nothing about whether payments are being worked on right now. When Grace asks in quarterly planning what is happening with payments, answering takes ten screens of scrolling.

Write everything large and the list shrinks to ten lines that nobody can start. Hand Theo a line that says "improve payments" and he has one question: which part? Card storage, refunds, receipts — none of that is in the line. It can't be sized either, so there is no way to decide whether it fits in the next cycle, and the line sits at the top of the list for a month looking like progress.

An epic is the layer inserted between those two failures. It is large enough to discuss in one line and small enough that splitting it produces work you can start this week. It accepts that different people read the backlog for different reasons, and writes the same work at two levels of detail at once.

An epic has five fields, and some of them exist only at this level.

1. Title. The single line visible in the list. Something as broad as "improve payments" is unrecognizable two months later. Narrow it until it names an outcome, like "pay without re-entering a stored card."
2. Background. Why this is needed. Recording who asked and where the request came from gives you evidence when the ordering gets revisited — one line noting that Sofia heard it in a March enterprise meeting does that job.
3. Completion condition. What has to be true for the epic to be finished. "A user with a stored card doesn't type the number again on the next payment" can be judged yes or no in one pass. This is the field most often left empty.
4. The split. Which pieces this epic breaks into. Each piece is usually written as a user story, one sentence from the user's point of view. An empty split field means the epic is not ready to be started.
5. Size. Roughly how many weeks. An epic never fits in a single cycle, so a precise number matters less here than the order of magnitude. The pieces get sized individually once the split exists.

Anything longer than these five fields belongs somewhere else. When screen flows and edge cases need writing down, they go in a product requirements document (PRD), and the epic keeps only a link to it. An epic is a line in a list, not a document to read.

The author is whoever owns the ordering of the list. At Pagedeck that is Mia. She doesn't finish one alone, though. The split gets filled in with Theo, and when screens are involved Noa writes what is wrong with the current ones into the background field. Anyone can file an item, and having them arrive from several directions is healthy — but two hands ordering the list is the same as having two lists.

Readers split into four groups, and each group reads different fields.

1. Engineering and design read the split and the completion condition. That is where the contents of the next cycle come from.
2. Sales and customer success read the title and the position. Those two fields are what let Sofia tell a customer that something is coming next quarter.
3. Executives read the top ten lines and the region that has slipped downward. What Grace is checking is less what the team is doing than what it has decided not to do.
4. Your future self is a reader too. When the same request arrives six months later and the background field is blank, the whole judgment has to be made again from scratch.

Because the purposes differ, one epic has to work for someone scanning from the top and for someone who arrived looking for this item alone. The way to do both is to make the title legible on its own and to keep the five fields in a fixed order for anyone who opens it.

"That's not a story, that's an epic. It won't fit in one sprint."

The sizing is wrong — split it and bring it back.

"We broke the payments epic into five pieces and we're only taking the first two this cycle."

Part of the epic ships now, not all of it.

"This epic has no completion condition, so I can't tell where its scope ends."

Nobody starts an item whose ending hasn't been defined.

At Pagedeck epics get handled mostly in backlog grooming, which runs every two weeks. Mia opens the top items in order, Theo reads the split and names the pieces that are missing, and any item that resists sizing eats the rest of the hour. That's why grooming only reaches the top twenty or thirty items. Epics further down are likely to move during prioritization, so refining them now means refining them again later.

The most common mistake is reading an epic as simply a big task. The name invites it. But an epic isn't a large item, it's a container that assumes it will be broken up. Nobody builds the epic itself — the pieces get built, and the epic only holds onto the fact that they came from the same purpose. Miss that and someone assigns a whole epic to one person, and progress stays invisible for weeks until it turns out at the deadline that half of it is done. Splitting it would have surfaced the same fact in the first week, when there was still time to cut scope.

The other one is assuming users get nothing until the entire epic is finished. Teams that believe this build all six pieces and release them together, which means two months with nothing to check against reality. The rule when splitting is that each piece should be shippable on its own. Card storage alone already has users, and what those users do with it can change the order of the remaining five, or reveal that two of them were never needed.