What good are Epics anyway?

Why we need them to stay focused on the right work

I wrote about Epics about a year ago, as a sort of general overview of all the ways epics are used. But interestingly, I didn’t get into much detail about how to actually write them and some of the finer points of what a team accomplishes when they use them well.

So, as what tends to happen, a conversation at work recently lead me to rediscover some of the teachings I’ve coached teams with in the past. This stuff is general purpose, and helpful to any kind of team.

What does a well-written Epic look like?

Now, my style as a coach is rarely to dictate specific language. And you won’t be surprised that I don’t think you need to follow a specific template here either. Some teams like to provide a similar “As a… I’d like to… so that…” syntax for Epics, but as long as you are clear enough, these syntax specific approaches are just a distraction.

Anyone who reads the Epic should know why it is important. Who will benefit from the work? What value is being created? What strategic, big picture element is this work connected to? How will you and the team know when this Epic is done enough? What else does the team need to know to help guide the way they implement this work? For example, are there any specific points of acceptance or guidance to avoid, confirm, or follow?

Why are Epics an important part of the agile process?

As a coach, I think this is one topic that most people don’t necessarily learn when they first start learning how to be agile. Yes, Epics are just big user stories as Mike Cohn says. (See my earlier article for the full quote and reference.)

Everything in an agile environment tends to gain importance as it increases in height or distance “above” the team. Teams of teams. Departments. Divisions. Senior management. Executives and the Board of Directors. The same is true of the work and the way we describe the work. As the granularity increases above the User Story level, it therefore becomes more strategic and important.

So, an Epic has a gravity of importance about it. And with anything important, it should also be very clear. And perhaps less obvious, it should not be conflated with multiple topics or unnecessary complexity. When any leader gives direction, for example, and they provide too much information without clarity about what is most important or where the focus should be, what they get is chaos and misunderstanding. The same is true with Epics.

Why have a singular purpose when writing Epics?

In order to fully explain why this aspect of writing Epics is important, we need to discuss a few other ways that Epics are useful. As bigger cogs in the machine, carrying some level of importance, Epics make it easier to talk about where our focus lies. Epics, by definition, summarize the work we are doing. Because of that, they are great proxies for the focus and strategic elements that the team is working on, or will be working on in the near future. And when you keep the language in an Epic to a “business outcome focus” and describe those outcomes using the words of your end users, it serves that purpose very well.

Singular purpose Epics using the language of business outcomes are perfect for describing an outcome-oriented Product Roadmap. And in doing so, they will be easily read and understood by anyone that cares to know how the team is focused right now and what they’ll be doing next. Combine that with the very agile-minded Now-Next-Later roadmap format and you can’t help but tell the whole truth of what the future of the delivery plan looks like, admitting only within a reasonable comfort zone what will be delivered when. We are fairly confident about the Epics to be done in the immediate future, but going out more than a few months and we need to more cautious about our commitments. As a team gets better at this, they will use metrics collected at the Epic level to set expectations about how many Epics can be done every three months, for example. (Please look into Janna Barstow’s Now Next Later roadmap format for more detail)

And well, unless we create some level of consistency about how we define Epics, we will never be able to collect metrics at that level. With messy Epics, we are left with very unpredictable futures. And no one likes that.

The lifecycle of an Epic

So, you may ask, how does a team get better at creating that predictability using Epics? Well, first I cover the points above. Clarity of the work in end user language, describing the why’s and the what’s of the desired business outcomes (which, just to restate the obvious, which leaves room for the delivery team to define the how’s and find the most innovative way to achieve those business outcomes so we can move on to the next most important strategic work in our roadmap! For more on this, see my post on the ‘purposeful tension’.)

Next, we need to recognize that Epics have a lifecycle, just like user stories. Teams learn about prioritizing backlogs, refinement, and Sprint Planning events in order to build Sprint Backlogs of the most important work, given all the conversations and priorities the team has discussed. The same thought process is true of Epics.

It’s OK to put an Epic with very little detail in the backlog. All it means is that it will take some time (i.e. multiple team conversations) to help flesh out the details and create the clarity needed to describe that Epic better. And through the work a Product Owner does with the team, an Epic will gain the right level of importance in relation to everything else the team needs to do and find its place in the Product Roadmap.

This is very analogous to the process a User Story goes through. Do we know what value is being created? Is it urgent and important enough? Are there dependencies? Do we know what it means? Does the team have a shared understanding about the viability and resources needed to deliver it? And because it represents a larger piece of work, it also includes the itemization and break down of the User Stories themselves that live underneath the Epic. There’s something very important and often left unsaid about the User Stories that live under an Epic…

The delicate balance of an Epic and its User Story children

If an Epic defines high-level goals and desired outcomes, it’s entirely dependent upon having the right detail beneath it in order to define the value that it comprises. And Epic needs User Stories to complete the story it has to tell.

However, and this is another one of those things that most people do not necessarily learn when they are first introduced to agile: the list of User Stories defined by an Epic is not meant to be an exact definition that must be completed in order for the Epic to be considered done. We very carefully write our Epic using business outcome language that is open to interpretation by the Product Owner so they can decide at the earliest convenience when the Epic is complete, answering the implied question, “Have we done enough of the User Stories of this Epic yet to satisfy the desired outcomes?”

To say it more specifically, sometimes a team will write 100 User Stories of work that aligns with and helps to describe what needs to be done for the Epic. The work is inspired by the Epic, helps achieve the overarching outcomes as it is written and is wholly related to the strategic goals defined by the Epic. And yet, as is with all things in the agile universe, some things are truly more important than others.

An Epic will typically define somewhere between one and three months worth of work. The best Epics are big but not too big and clearly deliver meaningful value to the end users.

In an ideal world, one big Epic like that is enough to keep the team occupied and very specifically focused. This helps create additional curbs of the road so everyone on the team knows they should be focused on strategic work. There will be exceptions, but a random request of the team will be more easily deferred because the Product Roadmap makes it crystal clear what the team is doing, why they are doing it, and what they are doing next. Anything else is a distraction and not as important by definition. (This is also why the on-team Product Owner role is so very hard to do well)

During the middle of execution of an Epic, as User Stories are being completed, the Product Owner should keep a finger on the pulse of the team and how well they are completing the picture defined by the Epic. If at any point the question of “Have we done enough of the Epic to satisfy the desired outcome?” is true, it is in the best interest of the team to stop work on that Epic and shift to whatever is next most important. They may, of course, decide to wait until the end of the Sprint, however as a coach helping a team optimize their ability to deliver, I think it’s important to push the team to think creatively and aggressively work toward their goals.

If there are ten big Epics a team wants to accomplish over the next six months, for example, and they’ve decided as a team that these are the most important and strategic elements they need to deliver, then they should do just enough to satisfy the business outcomes of each of those in order to increase the chances of delivering all of them.

Analogies can help reinforce the understanding of Epics

For some team members and even leaders outside of the team, it can be very difficult to embrace this agile way of working where things are often subject to change. And yet, I do think there are some very approachable analogies that will convince the average person that they already know these things intuitively.

My favorite is one I’ve only made up recently. If the problem is “I have to clean the whole house by myself before guests arrive in a day or two”, we already know intuitively how to complete Epics though judging desired outcomes vs. completing every single User Story that has been written. And the shorter your timeframe, the more exaggerated of a point I can make. With a day or two before guests arrive, we might start very thoroughly cleaning the kitchen. We might even do some things we don’t do everyday to keep the kitchen clean. But we know intuitively that we don’t have time to do that very deep cleaning we might do once a year. Because, we know we need to leave time to clean the living room and the bathrooms. Similarly, we might not move furniture and do a more thorough job on the living room because we have less than a day left now and we still have two bathrooms to clean. The full list of User Stories is easy to write to define everything that we might do. But intuitively, we know how much is really necessary to accomplish the job enough.

And if you’re a teenager, and the job is to clean your room, you probably do a very different set of User Stories if you only have an hour vs. an entire Saturday to do a better job that your parents are going to scrutinize.

Value delivery in a software driven world

Everything I’ve said about delivering the most important business outcomes of the Epics in our backlog is admitting that the work we do lives in the context of a software driven world. The work is never done. Products are never finished. Whether your phase two is funded or not, there is always the possibility that more work will need to be done later, and that some subset of the work will be acceptable enough in the short term.

And, like everything in the agile universe, some stuff is more important than others. It is truly an artform not a science to get really good at this. We all need to decide whether we need to just wipe the crumbs off the counter, clean behind the coffee maker, or thoroughly polish every inch of our marble kitchen counters.

The answer is always “It depends.” But the answer should also be inspired by looking at your Product Roadmap and the biggest picture you can imagine about what a successful delivery looks like to you and your customers.

If you enjoyed this, please like and share. It means a lot to know my work on this blog is read and used by agilists out there in the world.

Hi, I’m Brian Link, an Enterprise Agile Coach who loves his job helping people. I call myself and my company the “Practical Agilist” because I pride myself on helping others distill down the complexity of the agile universe into easy to understand and simple common sense.

The Practical Agilist Guidebook is a reference guide that gives easy to understand advice as if you had an Agile Coach teaching you the behaviors behind the Agile Mindset, why the topics are important, and what you can start doing about it. It also includes Scrum Master and leadership tips, AI prompts to help you explore topics and dig deeper, and tons of recommended books, videos, and articles.

Paperback and Kindle Available on Amazon.