Let me go ahead and bump-up my reply to "another answer."
In a "gym application" as described there are at least two entirely separate groups of stakeholders: customers, and trainers. If you looked at a "story" told by either one of them, you would see only the story-teller. You would largely miss why a particular story was needed, because "the trainer" is not a direct part of "the user's" stories, and yet of course he absolutely is.
The concept of an "Epic" is somewhat ambiguously defined in the books, but I think that the essential notion ... and, need ... is clear. You need to have a level-of-detail which clearly shows how the various stakeholders and their stories interact. You also need to see how they might each affect shared data, databases and so on. "Stories alone" won't necessarily tell you these things, and yet they can't be properly understood (or, implemented) without this vital context.
Of course, other people use the same term, "Epic," to mean entirely different things.
In passing, I would also comment that I think there's one aspect of software development which "scrum, stories, and so on" a bit glosses-over: the actual process of turning all of this into a piece of working code. You can't, for example, implement "a customer's story" without being fully aware of ... what the customer himself does not directly know about nor is concerned about, namely the actions of the trainer as (s)he interacts with the same software system. "What is represented by 'a story'" is, in fact, only part of the bigger picture that must face a software-writer.
The story-streams are used to develop an implementation-task stream that might tackle and be concerned with more than one story, or indeed, only part of those story(ies). And, to accomplish this, it is absolutely critical that the designers are aware of all the stakeholders whose "stories" will affect or be affected by every single thing that they are doing. Your "Epic," as I use the term, is therefore extremely vital.
As a project manager, these concerns are perhaps not directly yours, but you do need to make sure that this aspect ... these "interlocking dependencies" that "any one story" might or might not tell or suggest ... are being considered in your plans and are made available to your teams. Work very closely with the actual implementors, as they are the subject-matter experts in actual software construction and deployment. Work to support the difficult task that they are doing.