What is an epic?
An epic in agile methodology is a substantial body of work that can be broken into multiple smaller and requirement-specific segments called user stories. These user stories represent specific action items required for completing an epic. An epic could be a new feature, a feature enhancement, a product, or a customer requirement. Large and complex epics can span multiple teams, projects, and sprints.
Let's consider a scenario where a birthday celebration event with 100 guests needs to be planned and executed. The event planner assigns specific tasks to respective teams; the planning team handles venue booking, the creative team manages venue decoration, and so on. These actionable items are known as user stories in agile methodology. A user story within an epic can be further broken down into smaller action items called tasks.
An epic is created based on the needs of customers and end-users. Epics are designed to be flexible, enabling seamless adjustments and adaptations to align with customer feedback and suggestions. If the client requires a change to the agreed-upon menu for the birthday event, the event planner will promptly inform the hospitality team in charge of the food to make the necessary changes before the event.
Unlike sprints, epics in agile do not have a set timeframe for completion. Ideally, the process of completing and delivering an epic will take between one to three months, depending upon the complexity and rounds of improvements.
Just like how completing many smaller tasks contributes to an overall successful event, leaving guests satisfied, the triumph of an epic is determined by completing all the user stories within it, ultimately delivering value to the customers. In other words, epics act as a bridge to transform initiatives into quantifiable values.
Why do you need epics?
Epics are used in agile software development to classify your user stories and lend a structure to your backlog. For example, if you're working on two-week sprints and you take on an integration between your product and a third-party application, it will likely take more than a single sprint to complete. This is where you can use epics. Your epic could be called <Product Name> Integration and the user stories required to achieve it could be spread across multiple sprints.
It's often not clear what our path is when we set off, so epics are a useful way to capture ideas and flesh them out as we go. In this way, an epic can be useful as a placeholder.
An epic can also help you capture abstract ideas with a single item in your backlog until your team decides to break it down into user stories. You could have an epic titled "Online Payment" in your backlog and you could flesh it out (Credit card, debit card, store credits..) when your team takes it up during their sprint planning meeting. Epics help identify milestones in your feature roadmap, or even features themselves, making your work more organized and easier to track.
How big should an epic be?
Based on the practices of a team, they decide how high-level or granular an epic should be. It also depends on their need for an extensive hierarchy in their work: some teams mandate that all their user stories need to be classified under one epic or another while other teams work with a more relaxed approach. Some teams complete their epics in a month and some run theirs over the course of several months.
Epic burndown chart
In the realm of agile, where multiple sprints run simultaneously and several iterations unfold within an epic, we often find ourselves asking, "How are we progressing towards the end goal? Is the epic moving at the right pace? Are we on track to meet the deadlines?"
It is like being in a confusing maze if you don't know where your epic is heading or whether it is on the right track. This eventually leads to delayed deliverables and unhappy end-users. An epic burndown chart is an excellent visual representation that can help you visualize your epic’s progress, manage and prioritize the workload efficiently, and ensure those planned deadlines are met.
The epic burndown chart depicts the amount of work remaining in an epic—consisting of unfinished or newly added user stories, tasks, and bugs—versus the time it will take to complete the epic. This chart helps project managers analyze and predict whether an epic can be completed by the planned deadline. Not only does this enable you to prioritize work items and estimate the total number of sprints required to complete the epic, but it also helps you understand your team's productivity level. If your team is overburdened, the work items within the epic can be prioritized such that the team works only on essential tasks to complete the epic. Likewise, if your team is underutilized, the work items within the epic can be prioritized in a way that allows your team to take on additional non-essential tasks to enhance the epic further.
How to read an epic burndown chart
An epic burndown chart consists of different components that the project manager and the team must clearly understand.
X-axis: This is the horizontal axis that represents the time allotted to complete actionable items within an epic.
Y-axis: This is the vertical axis representing the remaining efforts required to complete the work items within an epic.
Against each axis, two important lines help the reader interpret the chart:
1. Ideal work remaining line: This line represents the perfect workload distribution amongst the team members, estimated with no setbacks or add-ons in the epic's progression. This is a downward sloping line starting from the very top of the y-axis and ending at the far right of the x-axis.
2. Actual work remaining line: The actual work line represents the real work remaining to complete the epic. This line will differ from the ideal work remaining line due to unexpected requirements, slow tasks, and bugs.
Project managers use these lines to track expectations against reality. If the actual work remaining line sits above the ideal work remaining line, it reads that the team is running behind in meeting the epic deadline. This information helps project managers make the right decisions to modify estimations and expectations.
While the burndown chart helps project managers and teams align with the epic's goals and timelines, it also provides a high-level view of the epic's status to the stakeholders so they can make critical business decisions.
Breaking down an epic
Whether you're breaking down an epic, a user story, or any work item in your backlog into tasks, it's important to remember to split them across functional boundaries and not technical ones. For example, if the work item is enabling online payment for an ecommerce store, you can split it into "Debit card payment" and "Credit card payment" instead of "Design," "Development," and 'Testing."
Horizontal breakdowns often cause bottlenecks since every item will be dependent on other items and not be able to contribute any value by itself. It also creates technical silos within the team and works against a shared understanding of what the team is working on.
Agile epic examples
An epic is more than just an umbrella of user stories; it serves as a cornerstone for effective planning and execution to meet the bigger goals. Epics in agile provide a strategic perspective to projects, allowing teams to prioritize and sequence work based on the value it brings to the end-users and stakeholders.
Let's explore a few examples of epics in various contexts to understand how epics help structure and organize work, facilitate collaboration, and ensure that the development process remains aligned with the project's overarching goals.
1. Constructing a house
Let's consider the construction of a single-story house as a project, in which one of the epics will be the building of a garden inside the house. The contractor is in charge of the epic and will break it down into smaller actionable items called user stories. The user stories can include:
- Constructing the floors of the garden
- Building walls around the garden
- Selecting decor and plants for the garden
Each user story will include numerous tasks. These tasks will have a fixed timeframe within which the task needs to be completed (e.g., selecting the correct tiles, fixing the tiles, painting the walls, or electrical works in the garden).
2. New feature on a landing page
Another example of an epic is the addition of gamification features to a landing page. The project manager will break the epic into smaller user stories and assign a team to build the feature. The user stories can include:
- Implement a Scratch and Win feature to let a page visitor win exciting gifts and coupons.
- Create at least three variations of UI for this feature.
- Create and share the front-end HTMLs of the feature.
These user stories can then be broken down into smaller tasks and added to sprints. Once all the user stories are completed, the feature can be tested to ensure the functionality is working smoothly and then prepared for delivery to the end users.
Using epics in Zoho Sprints
We understand the purpose and usage of epics in your scrum process and we've taken care to reflect this in our product design. Instead of cluttering your backlog with all your epics and user stories, we created a separate view for epics where you can see all your epics along with their user stories spread across multiple sprints.
Zoho Sprints also includes epic reports so your team can track your epic progress and get a bird's eye view of how your product is coming along.
Epics are a tool to classify and structure your work. Using hierarchy in your work is a delicate line to toe: the right amount can lend clarity, while an excess of it becomes counterintuitive. Zoho Sprints supports a relaxed work structure, which can work for all teams. Whether your team works on long-term projects with a strict hierarchy, or on short ones with smaller software cycles, we've got you covered.
