Epics in agile project management
Definition and meaning of Epics in an agile environment
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.
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:
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.
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.
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.