Start for FREE

By Pavel Kukhnavets

Agile Epics

What are Agile epics? Definition, benefits, and examples

Stay focused
on the tasks that
help your business
grow

Sign up to Hygger:

Writing epics is the most basic and crucial task at hand when you are trying your skills in Agile project management.

what are epics in Agile?

The ability to write good epics will positively affect your team collaboration and building the right things. Therefore, product managers should pay enough attention to creating Agile epics, slice them down, and prioritize the backlog to have a smoother development process and easy shipment.

What defines an epic? What are examples of epics? How do you start an epic? In this post, we offer some interesting facts about what is the meaning of an epic in Agile, what is the difference between epics and features, and how to write epics right.

What is an Epic in Agile?

An epic is a big story. Most likely, when you think of epics, you immediately recall literature. And this is quite logical.

In terms of software development, the bigger the user story, the more likely you’re dealing with an epic. This is the most vivid difference between epics and user stories in Agile.

There is no need to try to thoroughly understand should this be an epic or a story. If this provides business value and needs to be on your backlog, then this is a story. However, it may also be an epic, because it’s big. So, in the Agile environment you can use the following definition:

An epic is a user story that can not be completed in one sprint

This epic definition does not rely on the use of story points estimation and it looks independent of the particular team’s velocity.

What are the roots?

Mike Cohn was the first who introduced the concept of an epic as a large user story in 2004. The book where he described it is called “User Stories Applied For Agile Software Development”.

An epic and the Agile development process

As we’ve just defined, according to the Agile development hierarchy system, an epic is settled between a theme and a user story. And it’s important to note that a theme is the high-level strategy of the team for its product.

In order to realize the strategy turning it into an actionable project plan, team members must take some essential steps. Firstly, the Agile team breaks the theme into smaller epics. They can be considered as smaller strategic plans. Secondly, the team must split every single epic further into stories. Each user story is a small unit of development work that will let users complete a task in your product.

Agile epics

Epics first, then stories

When project managers (especially PMs without experience) start planning an Agile project, all their user stories are likely to be in epic form.

During prioritization, the most important epics will be broken down, down into smaller stories. The Product Owner will prioritize these stories and the ones with the highest priority will move to the next sprint.

Epics do not clutter the backlog and this is like their best advantage. When you keep most of your user stories in epic form, you simplify the way the PO manages the product backlog. Epics also let you keep your development team from wasting their time hashing out a number of stories that might never be prioritized at all.

What are the benefits we can expect?

With the help of Agile epics, we can keep track of large ideas in our backlog that are not clearly defined without the need to overfill the backlog with numerous items. It allows keeping in mind an unclear idea with one backlog item until the team determines the need to deliver the outcome that the epic gives. At this stage, during the backlog grooming meeting, the Agile team can break the epic down into smaller user stories.

Epics benefit Agile teams as they allow establishing a hierarchy for the backlog items where the epic means the original idea (often related to the outcome). The user stories involved in the epic represent different aspects of the solution you need to deliver.

It also allows us to see the concept of themes that are used for grouping stories related to the same topic. The concept of themes is often used to group stories that were identified separately and can filter sorts to define what user stories to group into a certain sprint or delivery.

What are the possible pitfalls we should expect?

Epics in Agile are also connected with some pitfalls we should care about in advance. Your Agile team can overcomplicate the use of epics by considering them as more than just large user stories. This becomes apparent when the team members build complex mechanisms to differentiate epics and stories and implement extensive tools to monitor epics separately from other backlog items.

These actions lead to the wasted effort that will result in more finely grained backlog items. The team can also strive to estimate epics even though these items are usually quite unclear in nature and prone to more uncertainty, which decreases the likelihood of reliable estimates.

Agile features vs Agile epics

An epic vs feature is a topic that can often be confusing. You can consider epics as product major versions, projects, or complex initiatives. If you represent a product, where several (or many) teams are working on it for a year or more, it makes sense to structure the backlog on epics, features, and user stories.

If your product is less global and it involves only one team of  10–12 people, it makes more sense to simplify the work and have only two levels of details for the backlog: features and stories. This depends on the product, your preferences, and needs.

Agile epic example

Let’s imagine there is a company whose goal is to organize excursions on a sea submarine. The company runs dozens of excursion launches per year, and every single launch requires many person-hours to complete. This sizing is right for an epic.

An epic, “June 2022 submarine excursion launch” will include user stories for routine work items and the stories aimed to improve core aspects of the submarine launch, from clients buying tickets to the launch of the marine itself. It means that at least several teams will contribute to the epic by working on a wide range of user stories.

Here’s how the team supporting the purchasing of tickets for the June excursion launch can structure their epic:

  • Story 1. Updating date range to include June 2022 launch dates.
  • Story 2.  Reducing load time for requested excursion listings.
  • Story 3. Promoting sale on confirm page for summer bookings.

What are epics within a complete Agile program?

An efficient epic should lead Agile teams to success. This is actually the top tier of their work hierarchy from a practical point of view. And understanding how epics relate to other structures in Agile provides essential context for the daily developers’ work.

A product roadmap visualizes how a product will evolve over time and a theme represents a company’s goal that drives the creation of epics and initiatives.

Product teams express the roadmap as a set of initiatives plotted along a timeline. By breaking initiatives into epics teams keep their daily work, visualized in smaller stories and connected to the business goals.

Completed epics stimulate specific initiatives that keep the overall product developing.

Epics vs features

The Basic Structure of How to Write Epics

How to write an epic?

A well-prepared epic is a basement to refer to in case of any doubts during development processes. It will help you to smooth out misunderstandings and conflicts in the team.

Of course, not everything is applicable in every situation as exceptions are also an essential part of the PM’s job. However, the following 4-steps strategy can be considered as a basic guide to writing a good epic.

1. Introduction

The first part of any epic is the introduction where you should include the ‘what’ and ‘why’ explanations.

For example, you are writing an epic for developing a new feature. Describe why you decided to develop it, what user expectations and needs you want to solve and what you strive to achieve with this new feature. If you have any early wireframes or docs for the feature, also include them in the intro section.

Let’s say, you are building a chat service and want to add a feature of uploading images from the users’ devices and sharing them with their contacts.

In the Intro section, you should mention that the feature will allow sending pictures to the users’ contacts through your chat system. Add that you expect this functionality will increase the number of messages sent per user by N% on average, and this will lead to approximately N% additional time spent using your product in the course of a quarter.

Introduction typically contains (based on our example):

  • the summary of what the feature is
  • the info about why you’re creating the feature
  • the metrics you want to improve
  • the links to specific docs
  • early wireframes
  • marketing plans
  • legal requirements (if needed)

2. Product requirements

This part of an epic should contain an explanation for your team with the aim to let them understand what they are going to create, design, test, or release.

For example, when you are working on building a feature that should work on desktop, mobile, and tablets or has to be available in four languages, you should mention it in the requirement section of the epic.

The product requirement part of the epic typically contains (based on our example) – A user can:

  • choose a picture from the own device
  • initiate a picture message from the message window
  • preview the image before sending
  • cancel sending the image before it is complete
  • send any resolution picture from the own device
  • notify about the successful uploading
  • see the uploaded picture in a preview mode
  • open the full image

3. Design requirements

There are always things that designers think are important to have a better UX that wouldn’t cross your mind.  So, it’s better to closely collaborate with the UX designer while preparing the design requirement section of the epic.

Your designer may think the preview should be of a certain size for a good experience then this requirement should be written in the Agile epic.

This section may also include (based on our example):

  • Pictures should be stored in our servers to let users see them at any time (even when they switch their devices).
  • The established standard of the pictures’ size (in pixels).
  • The established standard of the preview’s size (in pixels).
  • The loading indicator is shown while the user is waiting for the upload.
  • The success indicator is shown when uploads are done.

4. Engineering requirements

The fourth part of the epic should be written predominantly for engineers or tech leads. Their inputs are really helpful while estimating and building the epic correctly.

Engineers might want to improve the integration with some other system for maintaining the quality of images. So, make sure you mention these requirements as well.

Based on our example, the engineering requirement may look like these:

  • Need a database capable of scaling to X number of images at a maximum of 10MB per picture.
  • In order to connect with the pictures in the database, you have to pull user IDs from the user profile.
  • Add an auto-delete system to delete pictures after a year.

Some Tips on How to Write Winning Epics

How to write an epic Agile people will be jealous about? You can try your best to make the process of epics preparing more affecting the work in a positive light. Pay attention to the following tips:

  • First, make a draft of your project’s vision and try to imagine what is the most necessary there as well as what can be included later. Do not hurry while writing epics.
  • When you have a certain idea that you’ve already written, create an epic in accordance with its theme. Try to be consecutive in your decisions.
  • Test all your ideas. Each feature should be available for testing its effectiveness and vividness.
  • Consider the expertise of experienced specialists when writing an epic. it is not a good idea to only rely on your personal vision.

When should we break down epics?

The best moment to split an epic user story chunks is when the Product Owner understands that the epic is nearing the backlog top. This movement of epics toward the top of the backlog is actually one more significant difference between epics and stories in Agile. So remember that once an epic reaches the top of the product backlog, it’s time to start splitting it.

Some stories within the epic will have a higher priority than others and some of them will be much lower than other priorities on the entire list.

The goal of the PO is to chip away at epics to recognize the most important user stories inside. These stories should be detailed, well-discussed, and be ready for a sprint.

How do you measure epics?

In order to visualize epics, you can use handy Burndown charts. They serve to keep teams motivated and all stakeholders informed.

Epic Burndown charts will demonstrate the estimated amount of work to be done in an epic or sprint. The x-axis (horizontal) indicates time, and the y-axis (vertical) indicates stories.

Using this tool helps to track the total work remaining and to predict the likelihood of achieving the sprint goal.

Conclusion

Now you see that the epic is a significant part of the process of project planning. Epics help to understand the real purposes and needs of users. The well-written epic is an advanced helper in further project development and even product launching.

Hopefully, this article with some essential tips will be helpful in your work. In case you have something to add or if you want to share your experience, please, feel free to let us know in the comments.