Photo by Simon Fitall on Unsplash

What is an Epic in Agile

In Agile, an Epic, or Epic User Story is a very large User Story. Large in terms of the complexity and amount of time it would take to complete. Epics might be discovered during Agile Estimation (Planning Poker). A story with a poker point estimate that exceeds the Sprint Velocity is an epic. A story with 40 or a 100 point estimate is an epic, a 20 might also be considered an epic depending on how the team has baselined the point scale.

An Epic is a User Story that is too big to be completed in a sprint and must be decomposed into smaller stories before it can be committed to a sprint. Remember that the best practice is to break an epic down into smaller stories and that epics that appear lower in the Backlog do not have to be decomposed until they are a couple of sprints away. Resist the temptation to work on an Epic across multiple sprints, as this practice reduces the ability for the team to be agile and to deliver working, tested software every sprint.

An Epic is not a bucket of stories or a theme to group stories. For example, an epic called “Security”, with associated security stories is not really an epic, but more of a theme. Security is not really a feature, it’s not something that can be delivered or will ever be completed.

To create a proper epic, perhaps with a security theme, make it specific like “user authentication” or “Secure Business to business data transmission”. make sure it includes a list of acceptance criteria, what are the capabilities that will be in place to declare the epic is ready to be delivered to customers. With a list of acceptance criteria, the task of slicing it into smaller stories becomes much easier and now you have a set scope for this epic.

How are Epics Formed?

Generally, when the Product Owner writes a story, they aren’t intending to create an epic. It isn’t always obvious that a story is an epic until the team starts to dig into the details.

Let’s say the Product Owner wants to add a search capability to a website. This might start with a story like

As a user looking for specific content

I want to enter keywords into a search box and review results

So that I can find answers to my questions

This is a typical User Story for a search function and at first glance it looks like a small enough story to be completed in a sprint.

The acceptance criteria could be:

• When I enter a search term and execute the search, Then pages that contain my search term are returned as results and page that don’t contain my search term are not returned
• When I start typing in the search box, Then auto generated suggestions are displayed
• When I want to search content within a product group, Then I can choose a filter and search specific content
• When I enter a blank search, Then my search is ignored
• When special content is available for my search term, Then it can be boosted and appear first
• When multiple users search with the same term and select certain results, Then the search can learn from this behaviour and boost the relevancy of those results.

There is a lot of functionality described in the acceptance criteria for this story. I would expect a team to put a large poker estimate on this one which would classify it as an epic. And more acceptance criteria might surface as discussion continues, or during build or testing.

Without going to deeply into decomposing, or slicing this epic, you can see that a natural approach would be to create stories around the acceptance criteria. Most agile tools allow you to associate epics with user stories (which becomes a problem when epics are used as themes to group stories). Keep this epic with all of its acceptance criteria and create new stories that deliver small but valuable increments of this functionality. Maybe the first iteration of the search just returns relevant results.

Impact maps and User Story Maps work predominantly at the Epic level. This makes it easier to conceptualize for business users.

Summary

In Agile, an epic is a User Story that is too big to fit in a sprint. Some best practices:

• Epics are large User Stories and should describe functionality and include acceptance criteria
• An epic is a story that cannot be fully completed in a sprint
• Epics must be decomposed or sliced into smaller User Stories before they can be included in a sprint
• Epics may decomposed into more epics, keep decomposing until they are no longer epics
• Epics are not buckets of stories or themes, they are User Stories and should be written as such