If your project management teams aren’t meeting deadlines or if they feel overwhelmed, there might be a workflow problem. Adding epics in agile development can help your teams prioritize tasks and direct the teams to focus on what matters.

What is an agile epic?

In literature, you might think of an epic as a larger-than-life story, one that spans years or even generations. An agile epic is similar in that it is a large block of work that can easily be divided into smaller pieces called user stories (think chapters in a book), which in turn are organized into sprints, which are to be completed within a specific timeframe. 

Going back to the book analogy, a sprint is like planning to read two chapters before falling asleep. 

Rather than a task, think of an epic as a high-level goal or requirement. An epic might not have all the details a team needs; those are for user stories. In addition, epics aren’t written in stone, as they can change as the project dictates.

Let’s say, for example, that your New Year resolution is to get in shape:

• Theme – Get in shape
  • Epic – Run a marathon by the end of the year
    • Story – Join a gym
    • Story – Buy running shoes
      • Sprint – Complete by following Monday

Perhaps you are ready to run a marathon by the middle of the year, or maybe you injure yourself and have to get in shape by swimming or riding a bicycle. 

Obviously, that’s a simplified example of an epic. DevOps epics would have far more user stories and sprints and a lot more variables. 

What are the benefits of epics?

An old joke asks, “How do you eat an elephant?” The answer is, “One bite at a time.”

Epics tackle one bite at a time, but also take a holistic approach. 

Smaller pieces are easier to manage

As most who’ve accomplished complex goals will tell you, tackling a project in small pieces is much easier than tackling it in large pieces. Beyond that, it is much easier to reverse engineer a small chunk of the entire project than potentially start from scratch when a problem occurs.

Keeps the team’s eye on the goals

Imagine that your job is writing a tiny piece of code every day without knowing the ultimate goal. Odds are you’d feel frustrated with your job, and you probably wouldn’t do it as well. 

An epic serves as a constant reminder of the end game. The goal is far more likely to be accomplished in the time you need it done and with the quality you need if everyone knows the endgame. 

Epics help plan sprints and the project as a whole

As the product owner divides up the stories, they assign story points, which are estimates of how much time and effort is needed to complete the sprint backlog (to-do list). Product owners adjust story points as they learn more about the project and what the team is capable of. 

How to create an epic

The process for creating an epic varies from organization to organization. With small to medium-sized organizations, the product owner might be an executive, such as the CIO or CTO, and user stories are assigned to teams. Larger organizations’ epics might originate from a vice president, director, or even senior employee.

Name the epic

The epic’s name should clearly and concisely convey the goal. It would unambiguously communicate the goals but without a roadmap to accomplish them. For example, an epic might be titled “Add instant messaging to the website.” 

Write the epic’s narrative

An epic’s narrative digs a little further into the epic. The narrative should include the owner’s name, the objective, and the reason for the epic. For example, the epic narrative might read, “As the [executive or product owner], I want to add instant messaging to the website so customers can directly communicate with us without calling or emailing.”

You might also include a short data-driven explanation of the reason, such as “A [percentage] increase in customer service response time leads to a [percentage] decrease in customer retention.”

Note the epic’s scenario

Describe how you envision people will use the new features.

Determine the epic’s scope

Before handing it off to a team, you should establish the scope or boundaries. For example, this might be where you denote the fields you want in the messaging app along with where you want the data to go. 

Describe what completing the epic looks like

Create a high-level list of the epic’s acceptance criteria. For example, in the messaging scenario, sales, marketing, or the department that’s ultimately communicating with customers in the app, will have to approve the messaging app, and development will have to show that the app is working.

Divide the epic into user stories

Once you’ve completed creating the epic, it’s time to break it down into user stories. 

How to break an epic into user stories

Breaking down an epic into user stories varies from project to project and company to company. While on one level, it makes sense to cut an epic up into equal-sized pieces with consecutive sprints, in most cases, that’s inefficient and might not even work, and it doesn’t allow for adjusting sprints as necessary.

One sprint at a time

You don’t have to worry about splitting the entire epic up all at once. In fact, that’s not recommended as there are too many variables that may come up. Instead, split off the enough for your first sprint, second sprint, etc. That gives you time to adjust as issues come up.

Breakdown by workflow

When you break an epic into user stories using a workflow breakdown, you break it up in order of the workflow. For example, the messaging app could include: analyze needs > write software > manage data collection > test.

Breakdown by role

Breaking down by role is as it sounds. Each person on the project is given their part of the project. 

Breakdown by sprint

When you break an epic down by sprint, you’re promising to deliver small, completed pieces of the project rather than the finished version. 

Make sure you get a whole slice of cake – horizontal vs. vertical

When you slice a layered cake, you slice it vertically, not horizontally, because if you slice it horizontally, you will only taste a single layer at a time. Workflows, like cakes, are layered. If you divide your workflow horizontally, you are likely to miss part of the picture. 

In the messaging app, for example, you might write the software, then the data capture layer, etc. Sure, that might work, but if you run into problems, you might not be able to address problems and issues as they appear. Also, you won’t have a complete picture of the project. 

Epics provide both the detailed and birds-eye views of a project, ensuring that nothing slips through the cracks.