What if we found ourselves building something that nobody wanted? In that case what did it matter if we did it on time and on budget?

—Eric Ries


An Epic is a container for a significant Solution development initiative that captures the more substantial investments that occur within a portfolio. Due to their considerable scope and impact, epics require the definition of a Minimum Viable Product (MVP) and approval by Lean Portfolio Management (LPM) before implementation.

Portfolio epics are typically cross-cutting, typically spanning multiple value streams and Program Increments (PIs). SAFe recommends applying the Lean Startup build-measure-learn cycle for epics to accelerate the learning and development process, and to reduce risk.


This article primarily describes the definition, approval, and implementation of portfolio epics. Program and Large solution epics, which follow a similar pattern, are described briefly at the end of this article.

There are two types of epics—business and enabler epics—each of which may occur at different levels of the Framework. Business epics directly deliver business value, while enabler epics are used to advance the Architectural Runway to support upcoming business or technical needs.

It’s important to note that epics are not merely a synonym for projects; they operate quite differently, as Figure 1 highlights. SAFe generally discourages using the project funding model (refer to the Lean Portfolio Management article). Instead, the funding to implement epics is allocated directly to the value streams within a portfolio. Moreover, Agile Release Trains (ARTs) develop and deliver epics following the Lean Startup cycle (Figure 7).

Figure 1. Epics are not projects

Defining Epics

Since epics are some of the most significant enterprise investments, stakeholders need to agree on their intent and definition. Figure 2 provides an epic hypothesis statement template that can be used to capture, organize, and communicate critical information about an epic.

Figure 2. Epic hypothesis statement

Download Epic Hypothesis Statement

Creating and Managing Epics

Portfolio epics are made visible, developed, and managed through the Portfolio Kanban system where they proceed through various states of maturity until they’re approved or rejected. Before being committed to implementation, epics require analysis. Epic Owners take responsibility for the critical collaborations required for this task, while Enterprise Architects shepherd the enabler epics that support the technical considerations for business epics. The result of the epic analysis is a Lean business case (Figure 3).

Figure 3. Lean business case

Download Lean Business Case

The LPM reviews the Lean business case to make a go/no-go decision for the epic. Once approved, portfolio epics stay in the portfolio backlog until implementation capacity becomes available from one or more ARTs. The Epic Owner is responsible for working with Product and Solution Management and System Architect/Engineering to split the epic into Features or Capabilities. Epic Owners help prioritize these items in their respective backlogs and have some ongoing responsibilities for stewardship and follow-up.

Prioritizing Epics

Epics are prioritized in the reviewing, analyzing, and implementation states of the portfolio Kanban using Weighted Shortest Job First (WSJF) and any other relevant factors. For example:

  • Reviewing – Epics in the reviewing state with the highest WSJF are pulled into the next state, analyzing, as soon as space is available.
  • Analyzing – Epics in the analyzing state that have the highest WSJF are pulled into the next state, portfolio backlog, as soon as space is available.
  • Portfolio backlog – Epics in the portfolio backlog state are also reviewed and prioritized using WSJF. When sufficient capacity from one or more ARTs is available, the items with the highest WSJF advance to the implementing state.

The Portfolio Sync event is often used to identify new epics and prioritize the portfolio backlog using WSJF.

Estimating and Forecasting Epics

Since epics often have lots of uncertainty, the best practice for Agile estimation is to break them down into smaller pieces of functionality, such as business and enabler features. These items are then estimated in story points and totaled to forecast the epic’s size (Figure 4).

Figure 4. Forecasting epics

Forecasting an epic’s duration requires an understanding of three data points:

1. An epic’s estimated size in story points
2. The historical velocity of the affected ARTs
3. The percent (%) capacity allocation that an ART can give to a specific epic

Figure 5 shows how to perform multiple ‘what if’ scenarios to forecast the schedule.

Figure 5. Forecasting Epics

The forecasted timeline depends on how much capacity each ART can dedicate to working on it (Figure 6). Product and Solution Management and Epic Owners collaboratively decide each ARTs capacity allocation for an epic. In this example, ART 1 has identified 2,000 story points of features for Epic 1, and it has a historical velocity of 1,000 story points per PI. Product Management can allocate 40% of ART 1’s capacity toward implementing its part of the epic. The spreadsheet in Figure 6 is then used to forecast how many PIs it will take to deliver. Below is a description of the calculations for ART 1 and Epic 1:

  • Determine ART 1’s capacity for epic 1: Multiply (40% negotiated capacity allocation for ART) * (1,000 story points of velocity per PI) = 400 story points available for each PI.
  • Calculate the Forecasted # of PIs: Divide 2000 story points by 400 story points = 5 forecasted PIs

After repeating these calculations for each ART, the Epic Owner can see that the forecasted duration to deliver the entire epic will be six PIs. Due to their scope, completion to original intent is not always the desired case. So, likely, some identified features and capabilities may eventually be discarded.

Figure 6. Applying capacity allocation to forecasting

Implementing Epics

The Lean Startup strategy recommends a highly iterative build-measure-learn cycle for product innovation and strategic investments. This strategy for implementing epics provides the economic and strategic advantages of a Lean startup by managing investment and risk incrementally while leveraging the flow and visibility benefits that SAFe offers (Figure 7).

Conducting the experiments that gather the data necessary to prove or disprove the Epic Hypothesis is a highly iterative process that continues until a data-driven result is obtained or the team consumes the experimentation budget. In general, the result of a proven hypothesis is an MVP suitable for continued investment by the value stream. Continued investment in an Epic that has a dis-proven hypothesis requires the creation of a new epic and approval from the LPM Function.

Figure 7. Epics in the Lean Startup Cycle

After it’s approved for implementation, the Epic Owner works with the Agile Teams to begin the development activities needed to realize the epic’s business outcomes hypothesis:

  • If the hypothesis is proven true, it will drive more work by implementing additional features and capabilities. ARTs manage any further investment in the Epic via ongoing WSJF feature prioritization of the Program Backlog. Local features identified by the ART, and those from the epic, compete during WSJF prioritization.
  • However, if the hypothesis is proven false, the LPM can decide to pivot by creating a new epic or dropping the initiative altogether.

After evaluating an epic’s hypothesis, it’s no longer considered to be a portfolio concern. However, the Epic Owner may have some ongoing responsibilities for stewardship and follow-up.

The empowerment and decentralized decision-making of Lean budgets depend on Guardrails for specific checks and balances. Value stream KPIs and other metrics also support guardrails to keep the LPM informed of the epic’s progress toward meeting its business outcomes hypothesis.

Program and Solution Epics

Epics may also originate from local ARTs or Solution Trains. In some cases, it may require only a single ART or Solution Train to implement. Since these epics may have a significant business impact, they also warrant a Lean business case, discussion, and approval from Product or Solution Management. However, any item that exceeds the ‘portfolio epic threshold’ requires review and approval through the Portfolio Kanban system. The Program and Solution Kanban article describe methods for managing the flow of these epics.

Learn More

[1] Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Random House, Inc.

Last update: 15 September 2019