Epics
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. Learning how epics relate to a healthy agile program is an essential skill no matter the size of your organization.
When adopting agile, 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 a healthy agile program is an essential skill no matter the size of your organization.
What is an Agile Epic?
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.
Agile Epic Example
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:
Epic: March 2050 Launch
Story: Update date range to include March 2050 Launch dates.
Story: Reduce load time for requested flight listings to < 0.45 seconds
Story: Promote Saturn Summer Sale on confirm page for First Class bookings.
Concurrently, the propulsion teams might contribute to the same epic with these stories:
Epic: March 2050 Launch
Story: Keep fuel tanks PSI > 250 PPM on launch
Story: Reduce overall fuel consumption by 1%.
Story: Hire new propulsion engineer to replace Gary. #garygate2050
Understanding Epics within a Complete Agile Program
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.
Creating an Agile Epic
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.
Break down an Agile Epic
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 print 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.
Measuring Agile Epics
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 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 Software
Understanding Agile Epics
Epics are not the absolute foundation of an agile program, but they are the practical drivers for most agile teams. Understanding where they fit into a healthy agile program creates context for your work, breaking them down into stories creates momentum.
Max Rehkopf
As a self-proclaimed “chaos muppet” I look to agile practices and lean principles to bring order to my everyday. It’s a joy of mine to share these lessons with others through the many articles, talks, and videos I make for Atlassian
