Our organization has over 2,000 developers, so the answer to this question is important to fluent and clear communication between the hundreds of Agile teams we have working together on our common product. For a very small organization, you can have a very simple structure that doesn't even need to be hierarchical (as others have answered). However, for large organizations, there is definitely a need for some organized, scaled, consistent hierarchy - and therein lies the problem in striving to make a hierarchy out of something that's not strictly hierarchical.
Incidentally, we refer to each of these disparate levels as "work items". Some organizations (including some of the respondents above) refer to disparate levels as Stories or User Stories (and we have in the past too), but we found this too ambiguous, so we now refer to them generically as Work Items.
The best we have "officially" done thus far is to follow Dean Leffingwell's SAFe structure of Investment Themes and Business Epics being at the top (and second from the top) of the hierarchy, then Features under that, and finally Stories under Features. According to Agile, Tasks are always under Stories, so we are careful not to reuse that term any higher up. We chose to follow SAFe to at least have SOME consistency across all our teams.
But this is still insufficient for our needs. We define a Feature as a clearly valuable deliverable to a consumer of our software product (i.e. we list these Features on our announcements of upcoming Releases). And we define a Story as a smaller amount of scope and work that can be delivered in a single Sprint by a single Agile dev team. We are also now STARTING to follow the SAFe definition of Investment Theme and Business Epic at the Portfolio level (and not below this level). And we are STARTING to NOT use our OLD definitions of "Theme" and "Epic".
We are now slowly evolving in this direction, but the wheels of progress grind slowly. We are still struggling with how to split work into bite-sized chunks so that we can define the work and get it done smoothly by multiple teams. To do this, we see a need for a "Sub-Feature" which is smaller than a Feature but bigger than a Story. Sub-Features can be used for chunks of work done on a Feature by EACH INDIVIDUAL team, or chunks of work done by a SINGLE team at different times (in different Sprints, or even different Releases).
We also need multiple hierarchical levels between Feature and Business Epic, but we haven't solved this one yet, other than to just call them "Themes" - which we know is not the correct term, as it's easily confused with SAFe Investment Themes. For some big projects (releases) we have as many as 5-8 different hierarchical levels, each one breaking the work down into smaller and smaller chunks. You can think of these Themes as being "Feature Groups", but that's not necessarily the correct term either.
I think it's important to try to use terms that offer clarity rather than ambiguity. So anyone referring to a Story means the smallest unit of work that can be done in a single Sprint (except for the Tasks under the Story), and Sub-Feature means the smallest unit of work on a Feature that can be done by a single team. Likewise, a Feature Group is one hierarchical level above Feature. Above that it gets a little fuzzy, so we usually just call them Themes, and we allow Themes as parents and children of other Themes.
We could use "Tags" to organize some of this, but tags don't give the organizational work breakdown structure that we need to divide the work between all of our teams.
The bottom line is that this is still a work-in-progress for us, and we're still struggling with it. But adhering to the SAFe definitions of Theme, Epic, Feature, and Story has us moving in the right direction.