Agile Epics

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

The ability to write good epics will positively affect your team collaboration and overall results. 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 the meaning of an epic in Agile; the difference between epics and features, as well as ideas on 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 one who introduced the concept of an epic as a large user story in 2004. The book where he describes 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.

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.

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. 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 for 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 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 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 your 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 sales on the confirmation page for summer bookings.

What Are Epics within a Complete Agile Program?

An efficient epic should lead Agile teams to success. 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 connected to business goals and visualized in smaller stories.

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 for 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 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 to let them understand what they are going to create, design, test, or release.

For example, when you are to deliver 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.

Based on our example, the product requirement part of the epic can contain the following features for the user: 

• choose a picture from a personal 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 a personal device;
• get a notification about 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, and then this requirement should be written in the Agile epic.

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

• Pictures should be stored on our servers to let users see them at any time (even when they switch off 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 complete.

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 for 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 make the process of preparing epics more efficient by following some tips:

• First, make a draft of your project’s vision and try to imagine what are the most necessary elements 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 for 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 the team 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 want to share your experience, please, feel free to let us know in the comments.