Epics -> User Stories -> Tasks with "themes" really just a form of collation that could possibly be applied at multiple levels. Features can be produced by any completed increment at any level that produces a coherent something, but are probably most associated with epics or user stories.
You can create your own hierarchy, but please don't. It works against core agile principles such as embracing change and just-in-time (JIT) planning.
Epics and themes are terms of art that originated with the XP movement and popularized by various books on user stories, especially those by Mike Cohn such as User Stories Applied (Cohn, M. 2004.)
Pragmatically speaking—you can look up definitions yourself if interested in formalisms—a user story is intended to be a cross-functional slice of functionality that is:
- commonly written in the Connextra format, although there are certainly other formats;
- meets INVEST criteria; and
- is intended to be used as a conversation placeholder (not a formal specification) for the team and its stakeholders.
The difference between user stories and epics is generally that user stories should generally be decomposed until they can be completed within a single iteration, e.g. a single Scrum Sprint or the typical cycle time of the Kanban Method. Epics are generally just larger stories that won't fit into a single iteration. Epics are generally used to articulate longer-term or less-detailed objectives that should eventually be decomposed into smaller user stories that can fit within a single iteration.
Themes are groups of related stories. One supposes you could extend the idea to features and epics, but most practitioners would not understand the term that way. For ease of professional communication, a theme is just a way to bucket-sort related stories.
Because most agile frameworks are intended to be incremental and/or iterative, the utility value in having deep hierarchies is unclear. Unlike big, upfront development (BUFD) frameworks, agile frameworks generally value just-in-time and just-enough planning, so having some deeply-nested, project-specific naming convention with arbitrary names such as:
Magnum Opus -> Series -> Book -> Chapter -> Scene
would largely fail to communicate anything of value outside of a project unless the product is a literary work. Such labels are more likely to create additional overhead and cognitive burden, carry unnecessary layers of relational information beyond what agile frameworks generally consider necessary, and often encourage BUFD practices. Creating unusual hierarchies is therefore typically discouraged without a clear business use case.
Advice on Coining Project-Specific Terms
Unless you have a clear business need, just don't do this. In most cases, it's simply not needed. In addition, such naming conventions won't serve a useful purpose in communicating status or categorization as a form of professional shorthand, especially outside of the project where the non-standard terms are used.
If you do have a legitimate reason for doing this in your particular problem domain, then I would strongly suggest creating a project glossary with both standardized definitions and guidance for how your organization, project, and team should use the terms. That way, whether or not such terms are used elsewhere you can use them internally, consistently, and (if you share the glossary) in a way that will facilitate rather than hamper communication with stakeholders.