I spend a lot of time working with executive leadership who are trying to start, or restart their lean portfolio management approaches. A big part of this conversation tends to be “how do we use epics? How SHOULD we use epics?” and I find myself describing a set of usage patterns quite often. This post attempts to capture that description clearly. Join the discussion on LinkedIn!
What is an Epic?
Before discussing the different usage patterns, it helps to clearly define what we mean by epic in the first place. Years ago, I selected a definition that matches what eventually found its way into SAFe’s Portfolio Epic, and I continue to use that today: An Epic is a means of managing the investment associated with large-scale work at an overall technology portfolio level. Each Epic should be a recognizable large investment to the executive stakeholders that are ultimately responsible for the outcomes of the overall set of investments into technology, and each should represent clear and significant value to the line of business executives who will benefit from the results. The work an epic represents is implemented in terms of Features (and capabilities, if needed), and flows into Agile Release Trains in non-disruptive ways that respect healthy capacity and WIP management.
To address a common point of confusion across different implementations, there are two ways in which the term “epic” has been used, and different scaling approaches and tooling implementations have varied between them. The “old” usage is as a collection of user stories that advance a common larger goal and allows easier reasoning about prioritization of those goals, as in “a really long story with a larger story arc is an epic.” I’ve called this a “parent user story” for the last ten years, and in SAFe that usage is roughly analogous to a Feature. The newer usage of the term Epic is as I describe in the preceding paragraph, and represents a significant investment that extends over a significant period of time.
The three patterns of epics
In practice, I see SAFe-using companies applying epics in three common patterns. I’ll summarize these, and then unpack the behaviors and details of each one in the following sections.
- Epic as Project – Epics are treated in a similar manner as projects, with a start and end date, designated scope, and an expected budget or funding level. The work is done by designated, pre-determined ARTs, and may cause staffing-level changes.
Note: This was how SAFe defined epics in the earliest versions, I believe ending sometime around SAFe 3.0. My memory of specific timeframe is hazy. - Epic as Container – Epics represent a fixed amount of work, usually in terms of a list of features, and are done when all of that work is done. One of these epics typically flows to a set of existing, pre-determined ARTs, and generally is completed using existing capacity and teams. While the epic doesn’t technically carry funding, it represents an approval to spend existing funding on the designated features.
Note: This was how SAFe defined epics through SAFe 4.5. - Epic as Experiment – Epics represent a large, strategic hypothesis to be tested and followed through upon. Each one of these epics explicitly contains a preliminary “MVP” (Minimum Viable Product) that should demonstrate clear impact against leading business indicators before the organization invests to complete the full envisioned scope and operational scale. The epic doesn’t carry direct funding, but does represent a tranched approval to invest existing funding into the new strategic experiment.
Epic as Project
Organizations appropriately use this approach as part of their transition from a traditional project-based portfolio towards a more agile model. The initial steps for such transitions often include forming Scrum teams and/or SAFe ARTs within existing project-funded programs, then later funding additional projects to flow into those ARTs rather than tearing them down and rebuilding them. This approach is quite effective at first, and provides a container to practice execution agility and build a shared understanding of the impact of agility and how the organization needs to behave differently to gain the benefits. It also creates an easier way to navigate the differences between traditional development groups and agile teams/trains when the organization is still learning and operating in a very hybrid manner.
However, as the organization gets better and better at execution agility, the friction represented by the project-segmented mindset becomes a larger and larger source of delay and often starts to inhibit or even block the necessary changes to realign the organization to the flow of value. Trains set up to support a single program are rarely well-factored for the long term, and the company will find it is taking on a ever-increasing load of dependencies with every new effort, pulling more and more complexity into the portfolio that could be easily resolved through properly stream-aligned trains.
Note: I have a hunch, but not evidence, that this is one of the most common causes for a SAFe implementation to demonstrate intial success, but then become viewed as a failure and “the new waterfall” over the following years . Organizations that don’t revisit their ART structure and value streams on at least an annual basis are at risk of misalignment and introducing significant friction.
Epic as Container
Organizations will tend to evolve naturally into this model from Epic as Project as they start to realize the benefits of having long-running ARTs and realize how much easier it is to fund that capacity in advance instead of playing the annual Tetris budgeting game. This approach creates a very smooth process for identifying large batches of work, decomposing it, and distributing it across a large (and often dependency-riddled) development organization. In many ways, this model creates the optimal “feature factory” and gives the best development organization productivity metrics for cost per feature, productivity, and perhaps even quality.
However, this approach doesn’t provide an effective path for distributed innovation or small experiments. The improvements tend instead towards larger “initiative-like” efforts and larger batches that represent fairly significant bets. This will often prevent effective discussions about which efforts should be cancelled, and will hold the organization back from successfully empowering a distributed product management capability. It also makes it very unlikely that the company will be able to seize unexpected asymmetric upsides when something could become a significant differentiation, but no further investment is made because “stick to the plan” is the cultural guide rather than “pursue the value”.
Epic as Experiment
Epic as Experiment allows organizations to receive the benefits of both centralized alignment and local investment decisions. The LPM executives can approve the business model intent and overall investment direction as part of a cohesive corporate strategy, while the local product leaders that deeply understand their market segments, buyers, and users are able to collaborate closely with architects, experience experts, and developers to experiment rapidly and build the best possible solutions.
I don’t see any significant downsides to the experimental epic, although there are often cases where the result of the “experiment” is preordained, and there isn’t much difference between this and Epic as Container. An example might be an Enabler Epic to “Remove all use of SQL Server 20xx by Dec 1, 2020 to avoid needing an extended support agreement, thus saving us $500k/year”. There’s flexibility for how each existing application does so across the portfolio (update version, swap to different backing store, decommission app, transition to MSP, etc) but the end state is having removed all the uses of the old version.
In practice, I find that LPM teams that get good at using Epics as Experiments are also the ones that are adept at supporting and steering non-disruptive organization change, and tend to create consistently value-aligned organizations. These orgs are the ones that are later capable of managing more of their portfolio through vision and purpose, reducing the number and prevalence of epics in the portfolio because the individual ARTs are fully capable of making effective decisions aligned to overall strategy. These are the companies that I see exhibiting the highest level of business agility.
