Epics and Stories
Stadium 8 organises your application into epics, and each epic into stories. Understanding this structure helps you describe what you want clearly, and helps Claude build it correctly.
What Is an Epic?
Section titled “What Is an Epic?”An epic is a major feature area: a coherent module of the application. Think of it as a section users would recognise as a distinct thing.
Examples: user authentication, product catalogue, order management, admin panel, dashboard.
A good epic is something you could ship independently. If two epics are so tangled you can’t imagine one without the other, they’re probably one epic. If one epic has grown so large it would take weeks to build end-to-end, it’s probably two.
What Is a Story?
Section titled “What Is a Story?”A story is one thing a user can do, or one thing the system does that a user would notice. It lives inside an epic.
Scope of a Story
Section titled “Scope of a Story”Think of a story as a small, self-contained piece of the epic. Not the whole epic, but not so small that it’s trivial either. A well-scoped story delivers something a user would notice is now possible or different. If completing a story leaves the app in a state where nothing visible has changed, it’s probably a technical task masquerading as a story. If completing it would take days and touch every part of the feature, it’s probably an epic.
Stories are always described from the user’s perspective, not from a technical or system perspective.
Good stories:
- “A user can log in with their email and password.”
- “The product list shows a ‘no results’ message when no items match the filter.”
- “An admin can deactivate a user account from the user management table.”
Not stories:
| Example | Why it doesn’t work |
|---|---|
| ”Set up the authentication middleware” | Technical task. Not user-visible. |
| ”Build the product management system” | Too large. This is an epic. |
| ”Improve the dashboard” | Too vague. What specifically should change? |
Claude proposes the story breakdown for each epic before any implementation begins. You review it, ask for revisions, and approve it. This is your main opportunity to add edge cases, adjust scope, or split something that’s grown too large.
For guidance on writing clear, effective stories, see Writing Requirements That Work.