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?
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).
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.
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).
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.
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).
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.
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.
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).
Building and evaluating the MVP is also a highly iterative process, and ARTs can continue experimenting until they reach the forecasted cost of the MVP. After that point, any continued investment will require approval from the LPM function.
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 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