In this article, we continue to take a look at each of Jira’s tools that can help users organize and plan their work. Recently, we covered project components and now we’re focusing on Epics. For a high-level overview of both topics, and more, you can start with our article on using Epics, components, and labels in Jira.
Introduction
Jira is an immensely popular tool from Atlassian that is used by organizations to track and plan their work, establish reporting and standardization, and so much more. Daily, my team and I work with organizations to help them understand and implement Jira (along with the rest of the Atlassian product family) and help them on the road to more efficient teams and happier stakeholders.
NEW RESEARCH: LEARN HOW DECISION-MAKERS ARE PRIORITIZING DIGITAL INITIATIVES IN 2024.
One thing I’ve learned is that, while there is certainly more than one right way to do (mostly) anything in Jira, it’s SO important to understand what options are available and to take a cohesive approach to how you use those options. Your team doesn’t need to be “agile” or a software development team to get the most out of Jira. However, without knowing what customizations and configurations are possible (and their possible pitfalls), maintaining and scaling your teams’ productivity can be very difficult.
So, in this article, we are taking a close look at Epics in Jira.
- What is an Epic anyway?
- What purpose do they serve in Jira?
- Best practices and considerations for using Epics in Jira and how to avoid common pitfalls.
What is an Epic?
Readers with a background in Agile project management or software development will be familiar with the term Epic because Jira was initially built to support Agile practices. However, as with many concepts, Epics are implemented differently by different teams and organizations. Atlassian provides us with the following definition:
An agile epic is a body of work that can be broken down into specific tasks (called user stories) based on the needs/requests of customers […] Epics help teams break their work down while continuing to work towards a bigger goal.
To put it quite simply, an Epic is a single goal or deliverable that is broken down into a group of related tasks that can be worked on independently, albeit sometimes a portion of these tasks must be started after others are completed. Many teams will disagree on details, like how large something should be to constitute an Epic, but this principle remains the same.
Another way to conceptualize Epics is as folders in a project hierarchy. Standard issues (like Stories, Tasks, or Bugs) are in that folder, so if you’re looking for a specific requirement, you have a better idea of where to look and what to prioritize than simply a lengthy backlog with no organization or order.
With this in mind, Atlassian designed Epics (and other traditionally Agile tools like Kanban boards) in Jira to be process-agnostic and useful for any team using the product. This flexible design allows even non-Agile (*gasp*) teams to use Epics as a powerful planning and tracking tool in their Jira arsenal.
How do Epics in Jira Work?
In Jira, Epics are a special issue type (similar to Task or Story) that can be created by users, with associated fields, screens, and a workflow. However, Epics have special custom fields with a unique issue linking feature that creates a hierarchy between issues in which the Epic is the ‘parent’ issue of multiple ‘child’ issues.
With this configuration, teams can break down any goal or project into smaller, achievable, assignable pieces of work that can often be worked on in parallel. Also, Epics have their own data points (i.e. Start Date, Target Date) that can be used to track teams’ work and communicate higher-level details to external stakeholders that may not be interested in the status of every task in a deliverable.
To create an Epic, users just need to select ‘Epic’ from the Issue Type select field on the create screen (assuming the selected project is configured to include the Epic issue type).
Issues can be created directly within an Epic from the Epic’s issue view screen or existing issues can be added to an Epic using the ‘Epic link’ field.
Jira’s Epic Features
Planning with the Epic Panel on the Project Backlog
Arguably the most powerful feature of Epics in Jira is the ability to integrate them directly into your planning process with the Epic panel in your project’s backlog. After expanding the epic panel (as seen below), users can filter by Epic, create issues directly within Epics, update details like Epic color, and even mark Epics as done and remove them from view. From the ‘Backlog’ view of a Scrum or Kanban board, you can also drag any issue and ‘drop’ that issue in an Epic (within the Epic panel) to update that issue’s Epic link.
Track Your Team’s Progress with Roadmaps
In recent years, Atlassian added Roadmaps to Jira Software Cloud as a way to expand upon the planning capabilities for teams using the product. Roadmaps are a tool to help visualize progress in your organization at a higher level, across multiple teams.
There are two different Roadmap products, Basic and Advanced. Both of these use the built-in Epic issue hierarchy to visually plot out your team’s work to help ensure projects are delivered on time.
Visualizing Epics on the Kanban Board
Teams relying on Epics for planning and tracking have the option to visualize Epics on their Kanban (or Active Sprint) boards a couple of ways. These board configurations allow anyone to quickly understand how each task relates to the overall team goal or objective through their association with an Epic.
Epic Swim Lanes
Each board (Kanban or Scrum) has the option to create swim lanes (or separate rows) for issues on the board. This separation allows for a clear separation of work and the ability to quickly see where each task fits into the overall plan.
Epic Link on Cards
Alternatively, you can update the board settings to add the ‘Epic link’ field to the face of each card. This will display the Epic’s name printed in the Epic’s customizable color.
Pro tip: assign the same Epic color to related Epics for quicker recognition. Check out this Atlassian Community post for more on Epic colors.
Epic Considerations and Best Practices
Organizations wanting to standardize need to agree on concepts and practices.
We work with many clients using Jira who sometimes struggle to define standardized metrics across teams. This is normally due to a difference in point-of-view or opinion on details like:
- “What constitutes an Epic?”
- “How long of a time frame should an Epic take?”
- “Who is responsible for updating and maintaining Epics?”, and others.
Once an organization discusses these questions and defines standards, maintaining visibility and generating meaningful reports becomes a breeze.
As a separate issue type, Epics can have unique workflows and requirements. Use them.
In Jira, each issue type in a project can have its own workflow, set of screens, and list of required fields. Administrators should use these configurations to establish separate requirements and processes for Epics, as there are usually fewer data points needed and rarely require more complex workflows than To Do → In Progress → Done.
As a rule, don’t create Epics without a defined scope (or Epics that never close).
It can be tempting to add whatever comes to mind to the backlog as an Epic, to create a simple organization mechanism. But, just like all other issue types in Jira, Epics are intended to eventually close. As an example, while it may be helpful today to create an Epic for your backlog items related to ‘Maintenance’, this is not a scalable solution. Features like the Epic Panel (in the backlog) start to lose usability (and value) when users have to sort through a continually growing list of Epics that hasn’t been maintained.
There is an exception, where we’ve seen projects run successfully with Epics that don’t end, but these Epics are functioning as Themes and not traditional Epics. In our experience, this is only maintainable when the projects themselves have a limited scope and timeline. This type of project is temporary and will typically be archived or deleted in short order.
Users should proceed with caution and should never use the Epic issues as both an ‘Agile’ Epic (time-boxed work) and Themes (overarching long-term efforts without defined end dates or outcomes) in the same project, as this can cause confusion and create a frustrating user experience.
Conclusion
Epics are just one of many ways to organize your team’s work in Jira Software and, as you can see, offer a variety of features and benefits for teams using the product. These features were designed to help implement Agile methodologies, but are powerful for any team looking to improve their abilities for planning work, predicting timelines, and adapting to changes as they arise.
Are you looking for help? Do you want to start taking advantage of Epics and other features for your team? Reach out to one of our Atlassian Experts. We’ve got an excited team that’s eager to help and share lessons we’ve learned helping teams be more productive in a way that’s visible, trackable, and scalable.
