An Epic guide to epics.

The coming year offers a wealth of potential for progress and new opportunities. I have transitioned to coaching agility full-time for a manufacturing organization, previously working with technology and software. The new role and environment are a good fit for me. It also puts me in touch with many talented people who are excited to learn about agility and improve processes. I was in a training session this week, and the topic of epics and scaling came up. I have written about user stories and how to manage a backlog, but I have not devoted much thought to epics and agile. Today, we are going to cover the basics of epics.

When we discuss epics in scrum, Mary Iqbal at Scrum.org says this,

"Epics and features are complementary optional practices Product Owners can use to organize the team's product backlog. I think of epics and features as a folder structure."

An epic acts as a folder for user stories and helps organize the backlog. This approach is nice, but these folders become overstuffed when dealing with hundreds of development teams working on giant projects. That is why people who practice SAFe give Epics special consideration. Instead of generic buckets of information holding similarly themed stories, Epics are necessary to make sense of large projects.

Here is an example from the software business –

Epic – Activity Pub Integration with the website

Thesis – If we can syndicate content from our website using activity pub protocols, especially for sales, we can increase revenue by 5% to 7.5%.

Business Value – 5

Relative Effort – 3

Notice a few things? An epic should have a title so it is easy to recognize. Next, an epic should have a hypothesis or thesis that explains why we should do the work. Are we updating the site for technical debt, or are we attempting to improve revenue? Finally, using a Fibonacci sequence, we rate the business value of the work and the relative effort based on feedback from the development teams. The business value and effort allow you to make priority judgments. SAFe uses a weighted job first technique to determine priorities and candidly discuss what matters.

My following example comes from the automotive business –

Epic – 2025 emissions regulatory compliance Europe

Thesis – To maintain market share in Europe, we must reduce CO2 emissions from our light trucks by 25% by the end of the calendar year 2026. Otherwise, we will violate EU regulations.

Business Value – 13

Relative Effort – 8

Notice the business value is higher because European sales are significant, and the effort is important because the engineering team has never reduced CO2 emissions by that amount in one model year. Now, business people who do not understand anything about technology or manufacturing can prioritize work based on how it will help the business. At a typical corporation with limited people, time, and money, prioritization of epics becomes necessary.

People with a more strategic view of the business author epics. It is then up to Product Owners who understand technology, customers, and manufacturing to break down epics into user stories. The user stories can then be estimated and completed by development teams. Eventually, the team will have a working system to test the hypothesis in the epic. If the thesis is valid, then you can mark the epic complete. If the thesis is invalid, the team, the strategic people, and the product owner get together and decide to keep working. Sometimes, we are wrong in business and will admit it and move on.

So, an epic does act like a folder to organize work at large organizations, but it is also a decision-making tool that bridges the work of the front-line employees with leaders with a more strategic vision. An epic allows you to prioritize work and provides a way to test assumptions to deliver value instead of constructing needless features. Epics are a strange concept, especially if you are new to agile, but understanding the difference between epics and stories will make life easier in your agile practice.

Until next time.