Epics: Purpose, structure, and content

✅ Epic User Stories, often called “Epics”, are simply User Stories which are too large to fit into an individual development timebox (“Sprint”, in the Scrum methodology).

❌ Epic User Stories are not themes which group together individual User Stories, new product features such a modules, or buckets of time to collect recorded time against.

The purpose of an Epic 🎞

The purpose of an Epic is similar to a typical User Story - an informal description of a user’s requirement, written in natural language relevant to the business domain. However, an Epic is less constrained by development capacity or process, so may describe a requirement a little broader and looser than required in a typical User Story.

The structure and content of an Epic 🧬

Epic User Stories, much like any other User Story, typically begin with a card describing the user’s problem, such as the “Connextra” template:

As a user persona
I want capability
So that business benefit

They will also have acceptance criteria like a typical User Story, to inform the test cases that are run to verify that the conditions to fulfil the user story have been met, as in the “Gherkin” template:

Given pre-condition
When user action
Then outcome

User Story mapping 📌

A process known as User Story mapping is often used by software development teams to sketch out a user’s journey through the system, break that down into Epics, and then break the (must have) Epics within it down into User Stories (of any priority).

See an example below for a holiday story map. Note that this might differ based on the scenario at hand and the needs of the customer. For example, if the customer had experience operating a boat, they might rent their own, and then a captain is not a must have!

Example story map on Diagrams.net