What is an epic?
An epic is a large body of work that can be broken down into smaller user stories or tasks, representing a significant feature, initiative, or deliverable. Epics are too large to complete in a single sprint and typically span multiple weeks or months. They serve as a container that groups related stories together under a common goal - such as "User authentication system" or "Mobile app redesign."
The relationship between epics and stories is hierarchical. An epic might be "Implement team collaboration features," which breaks down into stories like "As a user, I want to assign cards to team members," "As a user, I want to comment on cards," and "As a user, I want to receive notifications when assigned." Each story is independently deliverable, but together they complete the epic.
Why epics matter
Epics bridge the gap between high-level roadmap planning and day-to-day task execution. Product owners and stakeholders think in terms of features and initiatives. Developers think in terms of individual tasks. Epics connect the two levels: they give stakeholders a way to track progress on a major feature without needing to understand every individual story, while giving developers a clear sense of how their daily work contributes to a larger goal.
Epics also help with prioritization at the roadmap level. Instead of comparing dozens of individual stories against each other, the product owner can compare a handful of epics and decide which feature initiatives are most important this quarter. The individual stories within each epic can then be prioritized independently during sprint planning.
Breaking epics into stories
A common mistake is treating an epic as a monolithic task and trying to plan all its stories upfront. In practice, only the first few stories need to be fully defined. As the team completes early stories, they learn more about the domain and can define subsequent stories with better information. This progressive decomposition is a core agile practice - plan just enough to start, refine as you go.
Each story within an epic should be independently valuable: it delivers a piece of functionality that a user can see, use, or benefit from. Avoid technical stories that only make sense as part of a sequence (like "set up the database schema" followed by "build the API" followed by "build the UI"). Instead, slice vertically: "As a user, I can log in with email and password" delivers a thin but complete feature from database to UI.
How Flux handles epics
Flux does not have a dedicated epic entity with parent-child hierarchy, but labels provide a flexible and effective way to group related cards. Create a label for each epic (for example, "Auth System" or "Mobile Redesign") and apply it to every card that belongs to that initiative. Filtering the board by label shows all cards in the epic, making progress visible at a glance. For larger initiatives, a dedicated board per epic works well - the multi-board view lets you see progress across all epic boards simultaneously. This approach is lighter-weight than rigid epic hierarchies and adapts naturally as scope changes.
Related terms
See also: User Story, Backlog, Sprint Planning.