Why do We Need Scrum Epics in Software Development?

In Scrum, project work is broken down into smaller parts. We know them as user stories. However, the project items can take other forms, for example, epics, that must be turned into user stories.

Breaking the project work into user stories provides high-level details around the desired functionality for a specific user. They are written by product owners and are completed in repeated cycles, known as Sprints.

In an ideal Scrum world, quality user stories meet the criteria according to the INVEST acronym, defined by Bill Wake:

• Independent from other user stories
• Negotiable that means flexible and able to be adjusted
• Valuable is about meeting needs
• Estimable in terms of time/complexity
• Small to be completed within a Sprint
• Testable means they can be verified by meeting criteria

Product owners should evaluate against these criteria when writing user stories. If all criteria are met, they are confirmed as user stories. If they do not meet the estimable criteria, they are considered epics.

The roots of epics come from the book “User Stories Applied For Agile Software Development” presented by Mike Cohn in 2004.

What is an epic in the Agile Scrum methodology?

An epic can be recognized as a big set of work with one common objective. This can be a feature, a business requirement or a customer request.

Concerning a product backlog, it’s a placeholder for a required feature with lines of description.

Epics tell compactly about final output of user needs.

Let’s say any epic is a book where user stories are its’ chapters.

Epics in the very beginning may not contain all the details that teams need, user stories define these details. Usually, a team needs one Sprint to complete an epic.

How are epics used in Agile?

User stories and epics are Agile artifacts that classify the amount of work. As it was mentioned, there is a common practice in many companies that means each of the bigger customer requests, feature, or requirement is considered an epic.

In some companies, for complex projects, where multiple focus areas need to be covered by many Scrum teams.

Epics are created by PM teams for different focus areas and all requirements in form of user stories are mapped to that focus area of epic. It simplifies tracking of the specific work area of a project.

It seems easy: if you have more than 5 user stories, then create an epic and add all these user stories to that epic.

How do we track epics?

Using epics is good for tracking complex feature progress. Epic may hold multiple user stories that are focused on a specific scope. As epic is just a placeholder, then user stories from an epic can be spanned across multiple projects.

The reasons your backlog items might be epics

Of course, stories seem small and clear but large and ambiguous of them are actually epics.

Many people think that epics are just large stories, but they should be defined as backlog items that can’t be agreed to by the team. It means that planning is based on the agreement but not the size.

Team members can not agree on a backlog item for a variety of reasons. There are core reasons a backlog item may be an epic:

• Complex. It’s when an item is too complex to be understood and to be agreed.
• Unknown. it is when nobody in a team knows enough about the item.
• Risky. It’s about too many unknowns. It’s too risky to agree to this item without further investigation or a mitigation strategy.
• Big. It’s too big to do in one Sprint, even if this item is well understood.

Benefits

Epics help to track large ideas in a product backlog without the need to overpopulate it with multiple items. They allow establishing a hierarchy for the backlog items where the epic represents the original idea often closely related to a particular outcome.

The concept of themes is also used for grouping user stories with the same topic. Themes are frequently used to group user stories that were identified separately together. They can be used as a decision filter of sorts to decide what user stories to group into a particular sprint or delivery.

In a backlog hierarchy, themes are typically not used as a level.

The opportunity to choose among stories, tasks, and epics give flexibility to an Agile team. However, do not think that you must use epics and tasks. Sometimes if stories are decomposed into smaller stories, each stands on its own and there is no need for hierarchy.

This view of the epics above demonstrates the priority and estimates and owner of each of the user stories. You may use Burndown charts to visualize epics. They keep the Stakeholders informed and make the development team motivated.

The Hygger Burndown chart shows how much progress the team makes as well as where work was added or removed by the product owner.

You may also track the development stage of your idea with the help of the Push option. Using it, you’ll be able to send a task from your backlog board to Sprint/Kanban board for its implementation with a help of a task link. The pushed task is linked to the original one from a backlog board, that shows you its development status.

The pushed items will be automatically synchronized. Once a pushed task is completed and moved to the Done column, its parent task will be automatically moved to Done column on a Backlog board. You can push several tasks to different boards at the same time.

Let’s say, you have created an Epic and split it into several tasks. Some of them can be pushed to a Sprint board, some to a Kanban board. You’ll see the cross-links in a parent and copied tasks after the push. It’ll help you to track the status of the epic and subtasks.

As you can see, Scrum epics are really helpful. Having epics, you can divide them into multiple stories like handling dashboard, search, and reports.

It will bring the size of the story manageable to implement within the quarter of the Sprint.