The definition of an epic largely depends on the organization. Every team has a slightly different understanding of how an epic should look like and what its role is in the delivery process. The bottom line is that an epic expresses a business goal which is larger and more complex than a user story, hence can be broken down into user stories.
In Scrum, when a user story is too big for a single sprint, considered as an epic. Other approaches may choose a different way to distinguish an epic from a story. But it is common across all agile practices that a story should never be “too big to handle”: having small, manageable units leads to business agility.
Looking at it from the other direction, epics are great for organizing stories into larger business initiatives. Let’s say if the forgot password solution is the ideal size for a story, a complete authentication module could be an epic. Teams may follow the practice of always creating epics as a container for a group of user stories, and then assigning stories to the epic. Even though epics may group a large number of stories, epics are not meant to represent a project, a release, a specific system or an entire large program of work – except in the Scaled Agile Framework (SAFe). Nevertheless, even in SAFe the epic is a kind of container for backlog items.
Whichever definition we find more useful, it is important to share our understanding with our teams and stakeholders. Otherwise, we may face confusion around epics, themes, features, initiatives, programs, releases, etc. These all can be containers/groups of user stories.
Due to the lack of a common definition of epic, agile collaboration tools handle epics differently, if at all. This leads to the consequence that the chosen tool may determine an organization’s definition of epic.