Epic

Epic describes the requirements for new software. As with the user story, an everyday language is used: a language that non-developers can also understand. The background to this is the approach of letting the customer create the Epic and User Story, which does not have to be technology-oriented.

General information

Epic is used in agile software development - for example with Scrum. It serves as an aid in the development of product backlogs and should support the overview display of new product requirements. An important part of an Epic is story decomposition, which is about better presentation. Here, overview descriptions are broken down into detailed descriptions, so that the implementation of the project is made easier.

Differentiation between epics, user stories and themes The distinction between user story and epics is not clearly defined. A user story describes in everyday language what the user or customer wants. As a rule, this user story consists of only a few words or a sentence. The transition from user stories to epics is therefore smooth and cannot be defined precisely. One speaks of a "big story" when one means epics, i.e. a story that is big enough to be dismantled. Ultimately, epics are used when the user story can no longer be summarized with a few words or a sentence. This complexity is too complex for a user story and leads to the transition to epics.

Themes, on the other hand, are groups of user stories that are assigned to a specific topic. If a comparison is applied, one could compare themes with films, for example especially with James Bond films, which facilitate a classification under the generic term "films". The theme "James Bond" leads here to a delimitation or clarification of the film and its generic term.

Example of an epic If a question (also called requirement) reveals that too many aspects are open or unclear or require a subdivision, it is divided into user stories. The same applies if the requirement does not fit into a sprint. In this case, the requirement results in the Epic.

Since agile software development always involves estimation, splitting it into stories is important because otherwise the development team will have problems estimating the effort. These problems are then also transferred to the product owner and management. If problems are disassembled and thus made smaller, more manageable, estimates become easier and planning can function better in the longer term. Here is an example:

• Epic: Create three GUI's for Overview, detail and login.
• User Story 1: Create an Overview GUI
• User Story 2: Create a detail GUI
• User Story 3: Create a login GUI.

The subdivision of user stories and epics has the following advantages:

• You can break a problem down into several smaller problems and make better estimates.
• The task breakdown is made easier or can at best be completely omitted.
• The business is provided with a value with every user story.
• Each story only needs to solve one problem. However, the task is not considered completed until all stories are free of errors. No "Done"[3] is performed before.

Formulations of epics and user stories

For both epics and user stories, the following scheme has proven to be helpful and efficient:

• Who (i.e. actor, customer, role) – what do I want (content, need, goal) so that why (i.e. the benefit, desire, profit, advantage) works.

This description pattern, which is based on Wh-questions, is effective, understandable and supports the formulation of different users or customers in everyday language. The requirements themselves depend on the type of project and can therefore be both product and service requirements. Primarily it is about the good comprehensibility, the decomposition into user stories should underline and strengthen this comprehensibility. The requirements are broken down and refined step by step, the user stories form the basis for the discussion of the participants.

The following methods and aids are available for practical application:

• Working with survey cards or story cards
• Conducting customer or user interviews
• Conducting focus group meetings
• The organization of user meetings and workshops
• The use of questionnaires
• The inclusion of document analyses
• Modelling, such as prototyping
• Not every tool has to be used, what makes the most sense depends on the type and size of the project and the methods and tools preferred by those involved.

Significance for development

In agile software development, user stories and epics are firstly important components for successful work and secondly usually closely connected with each other. Epics help to create structures that facilitate project planning and lead to faster and better results.