Understanding Agile Requirements: User Stories, Epics, and Their Hierarchy

The author begins by posing three common doubts about agile requirements: the appropriate number of layers, whether an Epic is a User Story, and whether User Stories are part of Scrum.

Investigation shows that the Scrum Guide mentions a product backlog but never defines a User Story; anyone involved in a discussion can write a story, and stories may be elevated to epics, which are later broken down into smaller, iteration‑sized stories.

Historical research reveals that the concept of a user story dates back to 1998 when Alistair Cockburn described it as a "promise for a conversation," followed by its adoption in XP by Kent Beck (1999) and the 3C rule by Ron Jeffries (2001); Mike Cohn later introduced the INVEST principle (2004), originally coined by Bill Wake.

The relationship between Epic and Story is clarified: an Epic is essentially a large story, not identical to a regular story, and must be decomposed into smaller stories to fit within a single sprint.

Using the agile "onion" diagram, the author maps requirement layers to concrete artifacts: Tasks correspond to daily work, User Stories to iterations, and larger releases to Epics or Initiatives. Atlassian defines Initiatives as collections of Epics sharing a goal, while Themes span across Initiatives and Epics. The IEEE definition of a Feature as a distinguishing characteristic of software is also discussed.

In conclusion, the article summarizes that Scrum does not prescribe User Stories, Epics and Stories are not fully equivalent, User Stories are the smallest unit of agile demand, larger items can be classified as Features or Epics depending on organizational needs, and the exact hierarchy (Theme‑Initiative‑Epic‑Story or Epic‑Feature‑Story) should align with the tools and processes a team uses.