What is an Epic?

Distinction between Task, User Story, Epic, Theme and Feature

There is a whole range of terms that come up in the context of epics. Often the exact demarcation is unclear: Is a feature bigger or smaller than an epic? What is a theme and what is a task? Below you will find “one” possible delineation:

• A task is an activity to implement a user story. The progress of the implementation is often visualised on a taskboard.
• In the literal sense, a user story describes a story of a user. In agile project management and in agile product and software development, a user story is therefore a tool for describing the desired functionalities of a system from the user’s point of view.
• An epic is a large, comprehensive user story. Sometimes it is argued that text length would be a differentiator, but this should not be the case through the use of text templates. Size refers either to the effort required to implement the desired functionality or the ability to break the epic into meaningful, smaller user stories. In fact, there is no fixed measure of when to speak of one or the other.
• A theme is a grouping of user stories based on a common theme. It is a label² or attribute and facilitates communication about content that has a common theme. Themes are not normally managed as backlog items.
• The BABOK Guide defines a feature as “a distinguishing characteristic of a solution that implements a coherent set of requirements and that provides value to a set of stakeholders.” Two insights can be derived from this definition: A feature describes what a product has or does. And it is larger than an Epic and can be broken down into (large) user stories if necessary.

Certainly, there are companies that use other definitions. For example, there is an alternative interpretation of theme, according to which it represents a corporate goal (or a vision) that is announced through various initiatives, which are divided into smaller units through epics and, if necessary, visualised by a roadmap.³ A feature could address a business value or also name a functionality of a product that has not yet been described in detail. And if an epic describes what a user wants to achieve with a product, then the feature could be the description of the function that makes this possible. Then a feature would be smaller than an epic. However, an epic could also represent a grouping of use cases, in which case a theme would be roughly equivalent to a use case and a user story would be roughly equivalent to a use case scenario or a use case slice; in this case, an epic would be much larger than a user story.⁴

In principle, different delineations and interpretations are fine, as long as those involved in a development, project or cooperation share a common understanding of the terms and can use them as a tool for their work.

The Phrasing of Epics

If an epic is nothing more than a big user story, then 1:1 is recommended to use sentence templates. The best known is probably:

• As a (role) I want (goal) so that (benefit).

An example could be as follows: “As a hotelier, I want to find the optimal price for my hotel rooms in order to compete with other hotels and maximise my revenue.”

Of course, alternative sentence templates are also suitable:

• In order to (receive benefit) as a (role), I can (goal/desire).
• As (user role), I can (what) so that (why).
• As (who) (when) (where), I (want) because (why).

All sentence templates have in common that they are intentionally kept short and not too descriptive. Although many companies do it differently, an epic should be a reminder of an exchange with users or customers and a documentation of key aspects of the exchange. On the one hand, it is about recording information, but on the other hand, it is less important to write down this information in a specific way. In other words, the type of documentation is secondary.

The Splitting of Epics

Epics, themes and user stories go back to Extreme Programming (XP) and not to the Scrum Guide as is often assumed. Even though all three elements are used in Scrum projects worldwide today, they are not mentioned once in the Scrum Guide.

As a means of expression, epics facilitate communication between users and product or software developers and convey a big picture. Themes help to structure the work and user stories provide the input for estimating the effort, e.g. in the form of story points.

Before a sprint can begin, the selected user stories must be small enough to be realised within a sprint. The corresponding term is: user story splitting. The term epic splitting, however, is practically not used. Here is an example of splitting⁵:

• E1: “As a hotelier, I want to find the optimal price for my hotel rooms in order to compete with other hotels and maximise my revenue.”
• US1: “As a hotelier, I want to find the optimal price for my hotel rooms based on last year’s prices in order to actively use experience and maximise revenue.”
• US2: “As a hotelier, I would like to set the optimal price for my hotel rooms based on the prices of comparable hotels in order to be competitive.”
• US3: “As a hotelier, I want to set the optimal price for my hotel rooms based on projected occupancy to be situationally responsive to supply and demand.”

One epic becomes three user stories. But what happens if the user stories are still too big? Then they are further refined:

• US2-1: “As a hotelier, I want to define a set of comparable hotels to find out the optimal price for my hotel rooms based on a price comparison.”
• US2-2: “As a hotelier, I want to be able to add hotels to the set of comparable properties to be able to react flexibly to the pricing of new competitors.”
• US3-1: “As a hotelier, I would like to be able to adjust the optimal price for my hotel rooms to the minimum occupancy rate, the desired occupancy rate and a maximum occupancy rate in order to be able to react optimally to supply and demand.

Tips for Using Epics

There are a number of tips for using epics:

• They should be formulated independently of each other.
• A common thematic reference should be visualised, for example, in the form of a tree diagram or a user story map.
• Acceptance criteria should be defined. If more than one acceptance criterion is found, it is a large user story that should be refined.
• The splitting should be done together in the team.
• Management in the backlog should follow Roman Pichler’s DEEP principle: detailed appropriately, estimated, emergent and prioritised.
• Since many backlogs quickly contain several thousand entries, it is worth using specialised tools for this purpose.
• And last but not least: not all information has to be formulated as epics or user stories. For a user interface design, for example, a sketch or wireframe might be more useful.

Opinions vary as to whether an epic should be “deleted” after it has been refined. On the one hand, this reduces the amount of data that is managed in a system. On the other hand, it also means that an epic has been “completely” broken down into user stories. However, this completeness cannot really be guaranteed. Furthermore, traceability would no longer be guaranteed. And since all common tools for managing backlogs offer views of elements that can be filtered by properties, many users do not find the existence of “implemented” epics annoying either.

Impulse to discuss:

If an epic is one big user story, does a user story that can be broken down into more user stories become an epic?

Notes (mostly in German):

[1] Ursprünge von Epik und episch
[2] User Stories, Epics and Themes
[3] Grundlegendes zu Epics
[4] Die Alternative zu Epics
[5] Aufsplitten von Epics

In Jira there is a task type “Subtask”. Theoretically, it is conceivable that a task is divided into smaller activities, but in fact the use of the subtask is more likely due to the fact that Jira allows the creation of a task as a backlog item. Subsequently, a further distinction is needed for implementation.

In the course of designing websites, the term theme is often used. A theme influences the look and feel of a website through colours, layout and style elements.

It is of course not an alternative to extend the sprint duration just to ensure the implementation of an epic within a sprint.

Here you will find additional information from our blog:

t2informatik develops and modernises software as a service provider. Click here to learn more.