The Role of Epics in Being Agile
People often get caught up in the terminology dealing with backlogs and describing the work to be done by agile teams. Mostly (fair warning) I tend to subscribe to the simpler perspective of Mike Cohn when it comes to Epics vs. Features vs. User Stories. I quite like how he describes these things in a way that makes them feel less prescriptive and much simpler. Here’s an excerpt or two from the linked article above:
As defined by the XP teams that invented user stories, an epic is a large user story. There’s no magic threshold at which we call a particular story an epic. For our purposes in agile and Scrum, epic just means big user story.… One more term worth defining is feature. This term was not used by the original user stories team, which has led to feature being applied to different things in different organizations and teams. Most common is that a feature is a user story that is big enough to be released or perhaps big enough that users will notice and be happier.
So, from the “XP teams that invented user stories”, epics are just big user stories. And yet, that, you will find, is not the only definition floating around out there, especially if you are working in a large organization that has started adopting scaled agile principles or using a tool that defines a strict hierarchy of backlog items with epic, then feature, then user story. And if you are adopting SAFe or Lean Portfolio Management or use terms like Enterprise Epic and Portfolio Epic, then it’s bound to start sounding a lot more complicated. So what are these different kinds of Epics and why does it matter?
Lean Portfolio Management
I’m going to largely ignore the Scaled Agile Framework’s plethora of Epics that exist. They have a lot of material describing Lean Portfolio Management, a Portfolio Backlog, Epic Owners, and the various processes that elevate (and complicate) the definition of Epic as described by Mike Cohn above into a high-level strategic concept that requires committees, approval processes, Portfolio Kanban boards, Value Stream Management, and different definitions for Enterprise Epics, Portfolio Epics, Solution Epics, Enabler Epics, etc.
But, suffice to say, some people do really need this level of complexity to manage their very large, strategic and complex work. And in this world, an epic takes on a much more strategic role in the organization. Lean Portfolio Management (LPM) does more than just fund longstanding product teams; they are also meant to serve as a high-level prioritization function, deciding which Teams of Teams will be assigned which large bodies of work… i.e., which teams will work on which approved epics. And frankly, I like that concept a lot. Strategy and vision is meant to start at the top, but don’t forget to have the conversation with the teams that deliver to incorporate feedback. And if you can accomplish setting strategic direction with just OKRs and not approval processes for epics, great! But if you need the complexities described by SAFe and can establish a cross-functional team that serves as your LPM team or a Value Management Office (VMO), that works too.
For what it’s worth, having an LPM or VMO deal with “strategic epics” effectively serves the purpose of having a definition of ready for epics. Are these epics important enough to work on this quarter? Do we know which team is best suited to deliver against these epics? Is this epic well-defined enough to know that it is in fact strategic and will have the desired outcomes we need for our customers?
Delivering Epics
No matter whether you treat an epic like a big user story or if you elevate them to a strategic level in your organization’s prioritization and approval processes, you will inevitably end up with a team or a team-of-teams working to deliver against those epics. The process of delivering an epic, I think, should always be the same.
An epic is a larger body of work and therefore needs to be broken down into smaller experiments as user stories to create the right feedback loops that ensure the work is truly valuable and on the right track as you go. And whether you treat an epic like a feature that has a meaningful cluster of value for customers or not, you should assign some sort of sizing or expectation-setting concept to the epic. Will it be done this quarter? When will we start seeing the value for this body of work being delivered? One strategy to stay focused on short term goals is to never let an epic last longer than 3 months. Staying focused on outcomes is crucial.
In fact, creating a roadmap that shows the sequencing of epics can also be helpful in setting expectations. Though, be careful. Anytime we create roadmaps that look like Gantt charts with timeline-based bodies of work, it tends to make people revert back to waterfall thinking. So be sure to use a “Now, Next, Later” format, or even better… an outcome oriented sequencing that itemizes the strategic goals in customer-grounded outcomes you are working towards and show which epics align under which parts of your roadmap so that expectations can be properly set.
Remember, an epic simply outlines the high-level desired outcome. If the Product lead for your team thinks you’ve achieved enough of the desired effects, an epic can be marked finished even if all of the identified stories were not delivered!
Why Use Epics?
I’ll conclude with perhaps stating some of the obvious of why we even use epics in the first place. Epics are larger pieces of related work that achieve some sort of higher level value (i.e., create the single-sign on capability, allow payments via Venmo, allow customer to change their address online, etc.) which allows us to explain clearly the work we are about to do in meaningful chunks. Part of being agile is keeping the end in mind as we meander through the detailed day to day. Epics are one way we do this. Our backlog can have many future epics identified and prioritized and, just-in-time, we break them down only when we’re nearing the time that we’re getting ready to deliver them.
Also, critically, epics help keep us focused. By making a deliberate choice to work on only so many epics at once, we are deciding that what not to do as well.
As always, this concept of epics is just another tool in your agile toolbelt. You and your team should decide how you’re going to use them to your advantage. Hopefully some of these ideas help you better define your own approach to using them to their full potential.
If you enjoyed this, please clap 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 practices and frameworks of the agile universe into easy to understand and simple common sense. I offer fractional agile coaching services to help teams improve affordably. See more at FractionalAgileCoach.com
How well is your team “being agile”? Our self-assessment tool focuses on 24 topics of modern ways of working including the Agile Manifesto and Modern Agile basics, XP, Design Thinking, Lean, DevOps, and Systems Thinking. It comes with deep links into the Practical Agilist Guidebook to aid continuous improvement in teams of any kind. Learn more at MakeTeamsAwesome.com
The Practical Agilist Guidebook is a reference guide that gives easy to understand advice as if you had an agile coach showing you why the topic is important, what you can start doing about it, scrum master tips, AI prompts to dig deeper, and tons of third party references describing similar perspectives. Learn more at PracticalAgilistGuidebook.com
Follow me here on Medium, subscribe, or find me on LinkedIn, or Twitter.
