Home » Epic

Epic

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, The Lean Startup [1]

Definition: An Epic is a significant solution development initiative.

Summary

Epics are significant initiatives designed to drive change and foster innovation. They are not the same as projects; their oversight, execution, and success measures differ greatly. Given their importance, epics require stakeholders to define clearly the expected outcomes and business benefits. They are managed using a portfolio Kanban system to improve their visibility and tracking. Due to their broad scope and potential impact, epics require defining a minimum viable product (MVP) and must be approved by Portfolio Leadership.

What is an epic?

An epic is a substantial business venture with significant scope and impact. Due to the potential size of the investment, stakeholders must align on the intent and definition of the epic. There are two primary types of epics: Business epics deliver value directly to the customer. Enabler epics enhance the architectural runway to support future business or technical needs. Epics also differ from traditional projects in that they are not merely financial allocations. Instead, they’re managed through a portfolio’s Kanban system. This enables visibility and tracking of their development until they are approved or rejected.

Epics operate quite differently to projects, as Figure 1 highlights.

two column table with epics and projects, explaining how epics are not the same as projects
Figure 1. Epics are not projects

SAFe discourages using the project funding model. Instead, the funding to implement epics is allocated directly to the value streams within a portfolio that implements that epic. Moreover, Agile Release Trains (ARTs) develop and deliver epics following the Lean Startup Cycle discussed later in this article (Figure 6).

How are epics defined?

Since epics are some of the most significant business investments, stakeholders must agree on their intent and definition. Figure 2 provides an epic hypothesis statement template for capturing, organizing, and communicating critical information about an epic.

epic hypothesis statement document template
Figure 2. Epic hypothesis statement

The portfolio Kanban system helps Portfolio Leadership and Epic Owners visualize, develop, and manage epics.

Read more about the portfolio backlog visualized as a Kanban:

Epics need to be analyzed before being approved for implementation. Epic Owners take responsibility for the critical collaborations on business epics, while Enterprise Architects typically guide enabler epics. The analysis of an epic leads to a Lean business case (Figure 3).

graphic showing the template of a two page lean business case document
Figure 3. Lean business case

Portfolio Leadership reviews the Lean business case to make a go/no-go decision for the epic. Once approved, epics move to the ‘ready’ state of the portfolio Kanban. When capacity and budget become available from the ARTs, the epic is pulled into implementation.

Read more about Epic Owners:

How is the Lean Startup cycle used to manage epic implementation?

SAFe’s Lean startup strategy recommends an iterative build-measure-learn cycle for product innovation and strategic investments. This approach provides the economic and strategic advantages of a Lean startup. It manages the epic’s investment and risk incrementally while leveraging the flow and visibility benefits of SAFe (Figure 4).

Analyzing an epic includes defining its Minimum Viable Product (MVP). In SAFe, an MVP is an early and minimal version of a new product or solution to prove or disprove the epic’s hypothesis. Unlike storyboards, prototypes, mockups, wireframes, and other research tools, the MVP is a product that customers can use to generate validated learning.

The Epic Owner determines the MVP’s budget with other stakeholders. The amount should be enough to prove or disprove the MVP’s hypothesis. After approval, the value stream cannot spend more than the defined cost to build and evaluate the MVP. If the value stream learns that costs will exceed the estimate discussed during epic implementation, this must be raised with Portfolio Leadership beforehand.

Gathering the data necessary to prove or disprove the epic hypothesis is highly iterative. The process continues until a data-driven result is obtained or the teams consume the entire MVP budget. Typically, a proven hypothesis results in continued investment in an MVP by the value streams. Otherwise, any further investment requires creating a new epic.

diagram of the safe lean startup cycle.
Figure 4. Epics in the Lean Startup cycle
  1. If the hypothesis is true, the epic enters the persevere state. The Epic Owner works with Product and Solution Management and System Architects to split it into features or capabilities. Epic Owners then help prioritize these items in their respective backlogs, with ongoing responsibilities for development and follow-up. ARTs manage further investment in the epic through ongoing WSJF feature prioritization of the ART Backlog. Local features identified by the ART and those from the epic compete during routine WSJF reprioritization.
  2. If the hypothesis is false, Epic Owners can decide to pivot by creating a new epic for LPM review. Or, they can drop the initiative and switch to other work in the backlog.

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

How is the cost and duration of an epic forecast?

If the epic hypothesis is proven correct, the forecasted cost of the full implementation will be required. The forecasted implementation cost considers ROI analysis, helping to determine if the business case is sound. This allows Portfolio Leadership and the Value Management Office (VMO) to prepare for potential adjustments to value stream budgets.

Estimating epics in the early stages can be challenging, as there is little data at that point. As illustrated in Figure 4, ‘T-shirt sizing’ is a simple way to estimate epics:

  • A cost range is established for each t-shirt size using historical data
  • The gaps in the cost ranges reflect the uncertainty of estimates and avoid excessive discussion around edge cases
  • Each portfolio must determine the relevant cost range for the t-shirt sizes

The Epic Owner can incrementally refine the total implementation cost as they learn more.

icons of t shirts sized from small to extra extra large on the left. Epic and enabler to the right. then the cost range is listed showing the highest cost lined up with the extra extra large t shirt
Figure 4. Estimating epics using T-shirt sizes and an example cost range in one organization

Epic investments often include supplier contributions and costs, whether internal or external. Ideally, organizations engage external suppliers via Agile contracts, which support estimating the costs of a supplier’s contribution to a specific epic.

Moving to lean budgets and more decentralized decision-making depends on guardrails for checks and balances. Value stream KPIs and other metrics inform Portfolio Leadership of the epic’s progress toward its business outcomes hypothesis.

Forecasting the duration of an epic that requires both ARTs and external suppliers can be challenging. However, the data is critical to allow the portfolio to function properly. Three data points help forecast an epic’s duration:

  1. Estimated Size in Story Points: An epic’s estimated size in story points for each affected ART can be calculated using T-shirt sizes (as above), replacing the cost range with a story point range.
  2. The historical velocity of the impacted ARTs
  3. The percent (%) capacity allocation that ARTs can dedicate to working on the epic: This allocation typically results from negotiations between Product and Solution Management, Epic Owners, and Portfolio Leadership.

In Figure 5, a portfolio has a substantial enabler epic that affects three ARTs. ART 1 has estimated the epic’s size as 2,000 – 2,500 points. Product Management determines that ART 1 can allocate 40% of its total capacity to implement its part of the epic. With a historical velocity of 1,000 story points per PI, ART 1 forecasts between five to seven PIs for the epic.

forecast duration table showing epic point size, art velocity, capacity, points and number of PIs
Figure 5. Example worksheet for forecasting an epic’s duration

After repeating these calculations for each ART, the Epic Owner can see that some ARTs will likely be ready to release on demand earlier than others. However, the forecast duration to deliver the entire epic across all ARTs will likely be between six and eight PIs. If this does not align with business needs, negotiations (such as adjusting capacity allocations or increasing the budget for suppliers) will follow. The Epic Owner updates the forecasted completion once work begins on the epic.

Read more about lean budgeting and agile contracts:

ART and Solution Train epics

Some ART and Solution Train initiatives are too big to complete in one PI. Because of their significant business impact or initiatives that exceed the threshold, some epics may originate from local ARTs or Solution Trains, and warrant LPM attention. Also, to facilitate incremental implementation, some portfolio epics may need to be split into ART and Solution Train epics. While mainly a local concern, they may affect financial, human, and other resources. That might be large enough to warrant a Lean business case, discussion, and financial approval from LPM.

Like portfolio epics, each ART and Solution Train epic usually has an Epic Owner. This person helps to define, explore, and make these epics happen. If there are enough epics, it can be helpful to create a local ART or Solution Train Kanban that follows the same stages as the portfolio Kanban to keep track of them. Product and Solution Management, along with Business Owners (and Portfolio Leadership if needed), review these epics to decide if they should be approved or rejected. Once an epic is approved, it’s broken down into smaller features or capabilities for further development in the ART or Solution Train backlog.


References

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

Last Update: 11 March 2025