To deliver one huge requirement to a client or to develop a significant business aspect of a product, agile teams need to organize and structure their work, from very high level to minute details.
Epics and user stories are tools for such structuring of work.
Table of contents:
- Introduction
- Agile Epic Definition
- What is Epic Level in Agile
- Why Use Epics
- Scope of Work in Epics
- How to Write an Epic
- How to Divide the Epics
- Example of an Epic in an Agile
- Conclusion
An epic in the agile world is nothing but a big chunk of work that cannot be completed in a sprint and therefore gets divided into smaller, more manageable pieces which have the potential to be shipped within a sprint.
So from an epic, many interdependent and related user stories can be formed. Epics can be divided among multiple teams and sometimes tracked on various boards as well.
Agile Epic Definition
An agile epic is a considerable amount of work that can be fragmented into smaller pieces of work called user stories and has an optimum value.
This epic breaks down into more minor issues/stories based on customer’s priorities, business needs, and organizational goals.
We can also say that epics describe the client’s requirement at a very high level.
Epics get completed throughout many sprints. Generally, teams complete 2-3 epics in a quarter or a release.
What is Epic Level in agile
The level of epic in the agile world falls after Themes but before User Stories.
Themes: Collection of interrelated epics that share a common goal.
Epics: Huge Work that can be divided into smaller stories.
Stories: Small requirements from an end-user perspective.
Why use Epics
- Epics bind smaller pieces of work together into one big idea. While working on stories, epics make all the stakeholders aware of their near future objectives. Hence, epics help the agile teams to visualize their goals and keep them aligned towards them.
- Epics are a way to structure a product’s roadmap and help in product backlog constitution.
- Epics provide a way to create a hierarchy of work.
- Epics help teams in strategic decision-making. Since the end goal is known, teams become proactive.
- Epics also make tracking large ideas easy with the help of agile tools such as Jira.
Imagine the difference between product backlog with epics – acting as one big idea and user stories rolling up to it and another without epics with stories that are intermingled and scattered with different ideas.
Scope of Work in Epic
Since epics are enormous, they cannot be completed in one sprint and get worked on throughout many sprints. Therefore, the scope of an epic is subject to change. The scope of an epic is flexible based on the ever-changing market and customer feedback after reviews of previously developed stories.
How to Write an Epic
The product owners/product managers write epics after client discussions and market research. The product owners can take the help of other team members while defining the epics for a product.
Below are a few things teams can look upon while creating an epic.
The epic should mention what needs development and why it is required.
Construct an Epic with a Label, Description, and the Acceptance Criteria.
Label: There should be a short but descriptive label depicting what the epic is all about.
Description: Write a brief description that depicts the idea of why, who, and what about the business.
Acceptance Criteria: Acceptance criteria are the standards or pre-defined requirements to measure if the epic is complete or not. Within the acceptance criteria, one can mention the technical and design needs. For example, in a messaging system, “The input messages should follow an XYZ-standard that is compatible with the central system.”
Apart from this, do create epics for the projects that need reporting.
Epics should not be too long or too short. A couple of weeks is optimal for epics to complete; therefore, keep this check-in in mind while creating epics.
Also, the granularity of each epic depends on the organization’s practices.
How to Divide the Epics
It is essential to divide your epics into user stories so that they fit into different iterations. While there are many ways to distribute an epic, one of them is storytelling.
Storytelling is one of the ways to envision tremendous work and priorities through a sequence of events that happen during the product development lifecycle.
In the storytelling approach, the epics are on top, followed by user stories, tasks and sub-tasks.
There are different ways to divide the work from the epics in storytelling like:
Workflow-based breakdown: Here, the work gets divided based on the work that needs to be done. If “Creating a Skit” is an Epic, then workflow-based breakdown can be as follows->
- Writing the skit
- Shopping for costumes
- Preparing the stage, etc.
Role-Based BREAKdown: Here, the work is divided based on roles. For example, If “Creating a Skit” is an epic, then role-based division can be as follows->
- Tasks for Dialog Writer
- Tasks for Actor
- Tasks for Director, etc.
TIME-Based BREAKdown: This means dividing work that could get done over a specific period. In scrum-based projects, it could be dividing epics into stories that can complete within a sprint.
It is always advisable to divide the work vertically than horizontally. That is to divide based on functional boundaries than technical.
For example, complete one small functionality of work that is ready to be delivered to customers rather than dividing based on analysis-> development -> testing, etc.
Example of an Epic in Agile
Lets say an agile team wants to create a Central Airways Messaging Platform for ABC airways which can send and receive messages from Website –A (books tickets), a Kiosk at the airport (books tickets and has other processes), Government sites for personal verification.
Then the epic would look somewhat like :
Name: EPIC -01AIR
Label: Creating a Central Messaging Platform for ABC Airways
Description: The system should send and receive messages Back and Forth from a different Website -A, a Kiosk at the airport, Government sites for verification.
Acceptance Criteria:
- Messages should be compatible with the Central Messaging Platform
- All messages should be saved in a database as well.
One can create different required stories under this epic, one such example is:
User Story: Central Messaging Platform to receive booking messages from Website-A so that it can use the information.
Conclusion
Epic might not be everything in an agile project, but they are the building blocks of the products initiatives, and most of the agile teams look on to epics for moving forward.
I have always used epics to envision a product better and to manage our product's backlog efficiently. I hope this article will help you too to understand the concept of epics. Good Luck!!!
