(Photo by Chris Murray on Unsplash)

My Favorite definition of an Epic is on the Atlassian’s Agile Coach website:

An Agile Epic is a body of work that can be broken down into specific tasks (called “stories,” or “user stories”) based on the needs/requests of customers or end users.

As a trainer and coach that has seen many teams misinterpret what Epics are for, I can tell you that’s not nearly enough information.

In this article I’m going to first review this definition to really understand what we should use Epics for. Then I’m going to talk about how I’ve seen high performing teams use Epics.

An Agile Epic….

The idea of an Epic has it’s origins the Agile methods, especially Scrum. It’s used with stories and has the same narrative root. I see lots of teams use Epics without really adopting Scrum… which can be fine. It really depends on if you’re honoring the rest of the definition.

…is a body of work…

This means that an Epic is undertaken. An Epic is begun, worked on and completed. It is NOT a container of concepts that can be used to group stories. Rather it is a description for something that will be done. This part of the definition is the most critical part.

…that can be broken down…

Note that it can be broken down. Not only do we expect Epics to be broken down, but we recognize they are not usually broken down when they are created. The team that actually has to do the work to complete the Epic will break the Epic down (or decompose the Epic) with the stakeholders.

…into specific tasks (called “stories,” or “user stories”)…

The work items required to complete the work are collected under the description of the broader Epic. Note that the agile methodology appears again here with the use of the word “stories” for the work items.

…based on the needs/requests of customers or end users.

Earlier I said that the the part which states “is a body of work” was the most critical part. This phrase is my favorite part. It’s not just any body of work, it’s a body of work that has specific relevance and visibility to customers or end users. I frequently see teams use Epics as collections of work relating to parts of the system, essentially using Epics where we intend Jira’s Components feature to be used. An Epic called “database refactor” has no relevance to customers or end users. However an Epic called “support more data export formats and analytics tool integrations” would be very relevant to customers or end users (and would likely be why you would like the team to refactor the database to begin with).

How the best teams use Epics

Knowing what is, and is not, an Epic is half the battle. How do high performing teams use Epics? How can we use Epics to build much better products?

Use outcomes with specific targets

Highly effective teams focus on outcomes and provide measurable objectives. For example, an average team might create an Epic called “Improve account creation experience” which is outcome based… so it’s not bad. It’s even better if we say something like, “new users should be able to create new account in less than 10 seconds”. By providing the external objective measure for our outcome, the team(s) working on decomposing this Epic can be much more selective and aggressive about how their stories will achieve it.

Avoid a complete and specific solution whenever you can (you always can)

I see Epics that say things like “Implement OAuth integration per the architectural specification”. One could (and should) argue that this is not based on the needs/requests of customers or end users. It’s okay to provide guidance and set expectations for the standard ways a team is expected to solve a problem, but you should still avoid putting every bit of the design information into your Epic. For one thing, the people building the solution are always in the best position to make the final design decisions. Secondly, high performing teams question everything to ensure they get the best solutions. Epics that have a complete, or even a mostly complete, solution designed diminish the team’s participation in discovering innovative ways to achieve outcomes. These are muscles you want your teams to use every time they work.

When Teams are expected to determine the design of the solution, they are far more likely to innovate

Teams that just implement provided designs will only rarely bring you game changing ideas. Don’t get me wrong, having coding standards and preferred architectural approaches is important, especially on really large systems. But these should be living specs that only survive as long as they continue to serve the needs of your customers and end users. If teams repeatedly feel like they can’t implement a better solution because they’ve been directed to do it this way, they don’t deliver many innovative solutions. Teams that are expected to come up with the design are far more likely to challenge outdated assumptions and deliver the most effective solutions. Will teams pick terrible designs, initially? They absolutely will. But if you want them growing your organization’s capabilities, your teams are going to show you where your systems need to go. So it’s worth every early miscue and bad idea because it’s learning from those that really creates highly effective teams.