Epics in agile project management

Alongside User Stories, other Product Backlog entries such as Themes or Epics also exist in agile project management. Yet what exactly are Epics, how are they structured and how can they be distinguished from User Stories? You may have already had these questions on your mind, too. That's why we've put together the most important information about Epics in this article.

Epics are used to manage the volume of work and to organize tasks. They can be a component of a Product Backlog and are an integral part of agile management. Epics are very extensive requirements that are still too large to be captured in a User Story at the time of evaluation. 
As with all Product Backlog entries, the requirements must first be described in a specific and measurable way so that they can contribute to achieving the objectives. Epics must also be aligned with the strategic project goals; only then can they be successfully implemented. Over the long-term, this promotes communication between users and developers.
Some Epics can also extend across several teams or even several projects. Epics also make it easier to prioritize tasks and thus improve workflows in the project. In addition, they promote transparency. Epics are broken down into User Stories, which represent wishes and briefly formulated requirements with regard to the final product, so that they can be better implemented during the course of the project. The User Stories, in turn, are particularly important for implementation and cost estimation.

Epics are closely linked to User Stories and cannot be considered separately from each other, but the individual Epics need to be formulated independently of each other. 
When creating and structuring Epics, it is advantageous if the team is involved in the process, as this makes it easier to understand the goals and associated tasks and thus facilitates development. There are various ways to achieve this:

Top-down

The previously identified Epics are broken down into User Stories, which are then prioritized for implementation in the subsequent development cycle. Only if the Epics are broken down into precisely defined User Stories will the feasibility of implementation be guaranteed.

Bottom-up

Epics can be derived from a number of thematically related User Stories by merging them.
If the Epics are defined before the User Stories are created (top-down), this creates a better overview of the work to be carried out. The reason for this is that User Stories are too detailed to see the bigger picture. Nevertheless, it sometimes happens that there is a specific requirement that then needs to be integrated into an Epic. It is therefore not an either/or, but rather a project- or case-specific consideration.
Applications for Epics include the agile framework Scrum and the Kanban method.
In Scrum, the Epics are prioritized in a Product Backlog. The more detailed the formulation of the requirements, the higher the prioritization is usually. This means that User Stories are higher up in the Product Backlog as they have already been formulated and Epics are lower down as they are still too large and too imprecisely described. In Scrum, it is also important that User Stories meet certain management criteria (e.g. the DEEP criteria). If they are managed according to the DEEP criteria, for example, they must meet the following criteria: detailed appropriately, estimated, emergent and prioritized. As soon as a User Story meets these criteria, it can be transferred from the Product Backlog to the Sprint Backlog and implemented in the development cycle, the sprint. The aforementioned connection between User Stories and Epic ensures that the team does not lose sight of the strategic goal over several Sprints and iterations, as the Epic pursue this goal.
Kanban, on the other hand, involves working digitally or analog with a Kanban board. This is made up of Kanban cards comprising the Epic, which the team divides into User Stories. Depending on the available capacity, these are pulled onto the work-in-progress stack according to the pull system, i.e. the stack containing all the cards that are currently being processed.

As described in the previous section, the two project management approaches handle the use of Epics differently. What they have in common, however, is that in both cases more transparency is created, the workflow is improved and only those User Stories are processed for the corresponding Epic that are really detailed enough and fit the strategic goals. When the team is involved in creating the Epic, everyone understands the goals to be achieved, which increases motivation and ensures that the product can be completed on time and, above all, successfully. Furthermore, misunderstandings are avoided as all information is known at all times. 
Another important point is that the effort of the Epic must be estimated. In Scrum, for example, this is important to ensure that the maximum Sprint duration is not exceeded. The burn-down chart is often used for this purpose. This involves estimating the effort required to complete the outstanding tasks for the Sprint with the help of Story Points. The team members use these points to indicate how time-consuming the work is likely to be. However, it is not yet possible to derive the processing time directly from this. That's where Velocity comes into play, a key figure that determines the speed of an implementation team. The average Velocity is expressed in points, i.e. how many functions a team can implement on average per Sprint. The team's estimated Story Points are then compared with the Velocity in order to obtain the most realistic possible time estimate for the implementation of a function in agile projects. The result is a bar chart in which the bars get smaller and smaller towards the right on the x-axis. If a straight line is drawn through the bar tips, this shows the ideal burn-down, in other words the number of story points that the development team completes per sprint day. The ideal line can then be compared with the actual times recorded daily in order to anticipate possible delays and also estimate how much time is needed for similar User Stories for later Sprints.
Kanban uses a cumulative flowchart that provides visual support and analyzes the stability of the workflow to make the process more predictable. In this way, bottlenecks that can occur if the team completes too many tasks at the same time can be avoided or absorbed and the schedule adhered to.

By bundling requirements, Epics are a great way to keep track of the strategic goals. They help to keep large and complex tasks manageable and divide them into easily manageable sections. Epics also improve transparency and communication within the team in day-to-day project work and help to track and control the workflow.