Agile epics: definition, examples, and templates

Summary: 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 or end-users. Epics are an important practice for agile and DevOps teams.

When adopting agile and DevOps, an epic serves to manage tasks. It's a defined body of work that is segmented into specific tasks (called “stories,” or “user stories”) based on the needs/requests of customers or end-users.

Epics are a helpful way to organize your work and to create a hierarchy. The idea is to break work down into shippable pieces so that large projects can actually get done and you can continue to ship value to your customers on a regular basis. Epics help teams break their work down, while continuing to work towards a bigger goal.

Maintaining agility when organizing large tasks, like epics, is no small task (pun intended).  Learning how epics relate to healthy agile and DevOps best practices is an essential skill no matter the size of your organization.

An epic is a large body of work that can be broken down into a number of smaller stories, or sometimes called “Issues” in Jira. Epics often encompass multiple teams, on multiple projects, and can even be tracked on multiple boards.

Epics are almost always delivered over a set of sprints. As a team learns more about an epic through development and customer feedback, user stories will be added and removed as necessary. That’s the key with agile epics: Scope is flexible, based on customer feedback and team cadence.  

Let’s say it’s 2050 and we work for a recreational space-travel organization. We do about a dozen launches a year, so each launch isn’t the single biggest thing we do in a year, but it’s still far from routine and will take many person-hours to complete. That sizing is just right for an epic.

An example epic, “March 2050 Space Tourism Launch” includes stories for routine work items as well as stories aimed to improve key aspects of the shuttle launch, from customers buying space travel tickets to the launch of the rocket itself. As such, multiple teams will contribute to this epic by working on a wide range of stories.

The software team supporting the purchasing of tickets for the March 2050 launch might structure their epic as so:

Concurrently, the propulsion teams might contribute to the same epic with these stories:

An epic should give the development team everything they need to be successful. From a practical perspective, it’s the top-tier of their work hierarchy. However, understanding how an epic relates to other agile structures provides important context for the daily dev work.

• A product roadmap is a plan of action for how a product or solution will evolve over time.
• A theme is an organization goal that drive the creation of epics and initiatives.
• The product roadmap is expressed and visualized as a set of initiatives plotted along a timeline.
• Breaking initiatives into epics helps keep the team’s daily work — expressed in smaller stories — connected to overall business goals.

A set of completed epics drives a specific initiative, which keeps the overall product developing and evolving with market and customer demands on top of organizational themes.

From our example above, a theme would be increasing space shuttle launches, the roadmap would track towards increasing launches from 3 per quarter to 4, the initiatives would be to drive down costs and increase ticket sales, and each epic would roll up into the initiatives.

When creating a new epic consider other planning and organization tools your team may already have in place. Creating epics around a team’s quarterly goals or OKRs is a great start. When creating an epic, consider the following:

• Reporting — Create epics for the projects that managers and executives will want to keep an eye on.
• Storytelling — Use epics, and the stories that roll up into them, as a mechanism to tell the story of how you arrived at the current state of a feature or product.
• Culture — Let organizational culture dictate the size and granularity of an epic.
• Time — Most development teams rely on estimation frameworks instead of time, but it’s a worthwhile gut check to make sure your epics will take a couple weeks to complete. Not too long and not too short.

See how Epics work in Jira.

Breaking down an epic into more practical stories helps in understanding a project and maintaining momentum, but it can be a daunting task for the uninitiated. There is no one-size-fits all solution for creating stories from an epic, but there are a lot of good options to consider:

• User role or persona — Create a unique story for each user persona. “Quicker login for new visitors,” “quicker login for return customers,” etc.
• Ordered steps — Break down the process and create a story for each step.
• Culture — Let team norms dictate if a story is a quick task or a week-long project.
• Time — Barring another agreed-upon convention, design stories that can be completed in one sprint or less.

There is no universal definition that draws a line between a big story and an epic. In general, any scope of work that the team estimates at “weeks” (or longer) to complete, rather than “hours” or “days” should be considered an epic and broken down into smaller stories.

Burndown charts can be used to visualize epics, and serve to keep teams motivated and the executive stakeholders informed. A good epic burndown chart is where the agility of the organization really shines.

An epic burndown chart shows the actual and estimated amount of work to be done in a sprint or epic. The horizontal x-axis in a burndown chart indicates time, and the vertical y-axis indicates stories or issues.

Use a burndown chart to track the total work remaining and to project the likelihood of achieving the sprint goal. By tracking the remaining work throughout the iteration, a team can manage its progress and respond accordingly.

By monitoring a burndown chart, it becomes clear how the team is progressing and where the blockers are. Having these data points clearly visible keeps everyone on the same page and facilitates an open conversation about the evolution of the product and completion forecasts. Not to mention that transparency builds trust!

Learn how to configure burndown charts in Jira

Once you have mastered the art of creating epics and stories, you might want to go one further and optimize using automation. Here are three of the most common automation rules used for sprints in Jira.

1. Automatically add three stories upon the creation of an epic. Go to rule.
2. Auto-close stories when the epic is marked as done. Go to rule.
3. Change the status of an epic when the status of one of its linked issues changes. Go to rule.

See these automation rules and hundreds more in the Jira Automation Template Library.

Go to the library

Epics are not the absolute foundation of an agile program, but they are the practical drivers for most agile and DevOps teams. Understanding where they fit into a healthy agile program creates context for your work, while breaking them down into stories creates momentum.