Many tools require the user to have an “Epic” story defined before any user stories can be created. In this example, Epics become an organizational technique to manage a story map or backlog, so user stories are grouped logically. This seems to imply that an epic is required for every user story, and that’s a tool requirement and not an Agile requirement.

A user story can stand on its own. There is no mandatory approach that requires an epic first and then deconstruction into specific levels. The basic rule of thumb is user stories should be detailed enough for the team to start development with minimal discussion and a clear expectation of the outcome.

Epics came into play to differentiate between user stories that were high level and those that were smaller, able to fit into a sprint, and contained specific acceptance criteria.

Our approach is to start with the capability, deconstruct capabilities into features/functions, then into specific user stories, and finally, detailed acceptance criteria for each user story. This helps us organize the backlog as user stories are more aligned with specific application capabilities, not a strange epic story that was just big but didn’t relate to anything.