According to the inventors of agile, an EPIC story is a large undefined user story that must be subdivided.
An EPIC must be broken down into smaller user stories. As far as I recall, user stories should follow the “INVEST” pattern where “I” stands for “independent” and “V” for “valuable”. In my opinion, an EPIC can make sense and be visible, perhaps in a different color so as to reflect its state as an embryonic proto-story, but not part of the application structure in the guise of a module or layer.
That leads to other questions:
All those subdivided and tiny user stories, would not deploy alone, they are related.
Indeed, this is where the idea of EPIC can be useful as an aggregator of user stories. That is to say as an encompassing module. But you have to be careful as it can be very confusing to manage such a thing on any project management tool, or even on paper. It makes it very difficult for any client to prioritize as there are too many dependencies. Using tags will probably help here I think.
Are my designer’s prototypes a big story, an EPIC?
If so, then that can be either a problem of documentation, or that the designer is working on prototypes before user stories are specified, or that they’ve been broken down by the back end engineers with all of what that entails, or some combination of all three. If the user stories are independent they should each have a very clear prototype. You shouldn’t have to dig deep to see which button refers to the user story that you are addressing at any specific moment.
But aren’t EPICS a way to group large functional blocks of the project, for example an API, the front part, mobile?
No. But you can call these “modules” or something similar to that, but these modules don’t have any specific value. The word EPIC is used by Mike Cohn in his book, so it is the official:-). I searched Google and found this wonderful article by Mike Cohn talking about all this: Agile User Stories, Epics and Themes. It’s a copy of this 2001 article: Agile User Stories, Epics and Themes