What is an Epic in agile?
In Agile product management, epics are used to organize tasks and create hierarchy in the development process. An epic is a large chunk of work that is segmented into smaller tasks, called user stories. An epic often spans across multiple sprints, teams, and even across multiple projects. Product people need to break down epics into stories before they can start creating functionality from them.
User stories within an epic share the same strategic goal and high-level requirements of what the customer wants. Similarly, when several epics share a common business objective, they are grouped together into an even broader body of work, called a theme. As sprints are completed, and understanding of the customer needs increases, the scope of an epic will change, and new user stories will be added or removed to the epic.
Understanding epics within a broader agile framework
Understanding where epics sit in the complete agile structure, allows product teams to make well-informed decisions and continue to work towards a bigger strategic goal.
- The roadmap communicates the product plan and aligns the whole organization around it. The roadmap shows how the product will evolve over time, and usually includes a timeline, feature releases, and goals.
- Themes are long-term strategic objectives with a broader scope. They provide context for decision-making and help navigate the product strategy within the organization. Agile themes sit on top of the work breakdown hierarchy and drive the creation of epics.
- Epics are collections of tasks or user stories. Epics break down development work into shippable components while keeping the daily work connected to the larger theme. Epics are more specific than themes and can be measured so that PMs can observe their contribution to the organization’s overall goal.
- User stories are the smallest piece of work in the agile framework. A user story is a brief explanation of a product feature written from the end user’s perspective that articulates how the user will experience value. Some organizations may classify larger user stories (stories that can’t be delivered within a single sprint) as epics. Alternatively, larger stories could be broken down into sub-tasks.
Agile epic example
Let’s say you’re a senior product manager at an online travel agency. In light of current events, bookings of the agency went down with 30%. After a long discussion with senior members from each department and outside stakeholders, the team decided to pivot to compete in the experiences market.
Here is an example of how the agile product team might plan the pivot.
Transition from a traditional accommodation agency to a complete online provider of experiences and activities.
- Launch an online marketplace for experience providers and end-users.
- Create an onboarding program for experience providers.
- Expand the current booking system to support experiences and activities.
- Build a mobile app to attract a younger audience of experienced buyers.
All of these items need to be broken down into multiple smaller stories to be delivered, but they are all related to the same theme.
“Launch a marketplace for experiences” might include stories from building the customer-facing website to tasks aimed at attracting experience providers and end-users to the new marketplace. The epic will be delivered over several sprints and will be executed by members from different teams.
Here’s what stories the product team might plan in order to launch the marketplace:
- Develop the signup process for experience providers. Assigned to the development team.
- Design a single experience view. Assigned to the product design team.
- Reduce loading time in the experience search. Assigned to the IT Operations team.
- Write a launch newsletter. Assigned to the marketing team.
Best practices for creating agile epics
A well-written epic will help you avoid conflicts and misunderstandings in the development process. Since the epic is the primary material that team members will refer to when creating user stories, each epic must be clearly explained.
Involve the whole team when writing the epic
As a product manager, it’s your responsibility to write the epic and maintain its specs. However, it’s important that you collaborate with the whole team. Engage the engineering and design teams while writing the requirements and ensure that everyone involved understands the goal of the epic.
Structure the specs of the epic
Bindiya Thakkar suggests that each epic follows a basic 4-section structure:
- Introduction — the introduction needs to include the “why” and “what” of what you’re building.
- Product requirement — an overarching explanation of what the team is going to design, build, and release.
- Technical requirement
- Design requirement
Select a metric for the epic
What metric are you trying to improve with each epic? Make sure that your epic has a metric you plan to track for measuring the success of the new features. An improvement in metrics will also keep the team motivated, and stakeholders well informed on your progress
Ensure the epic doesn’t take too long or too short to complete
An epic takes longer to deliver than a user story, but make sure that it doesn’t take too long either. As a rule of thumb, two weeks is considered a good amount of time for epics.
Identify blockers in the work process
Once you finalize the epic, it’s your job to track the total work done towards stories related to the epic. Keeping an eye on the relevant stories will also help you identify any progress blockers that keep your team from completing the epic.