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 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.
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.
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:
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.
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.
Bindiya Thakkar suggests that each epic follows a basic 4-section structure:
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
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.
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.
