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

Epic

An Epic is a container for a Solution development initiative large enough to require analysis, the definition of a Minimum Viable Product (MVP), and financial approval prior to implementation. Implementation occurs over multiple Program Increments (PIs) and follows the Lean startup ‘build-measure-learn’ cycle.

Epics are integral to Lean Portfolio Management (LPM) and Lean Budgeting models. They require an Epic Owner and Lean business case. Epics typically do not require a traditional scope completion end state. Instead, work continues until the optimum economic benefit is achieved.

There are two types of epics: business epics and enabler epics, each of which may occur at the Portfolio, Large Solution, and Program Levels. This article primarily describes the definition, approval, and implementation of portfolio epics. Solution and program epics follow a similar pattern.

Details

Epics are the containers that capture and manage the largest initiatives that occur within a portfolio. Epics and the Value Streams they affect are the primary concern of the Portfolio level. Business epics directly deliver business value, while enabler epics are used to advance the Architectural Runway to support upcoming business epics.

Fostering Innovation with the Lean Startup Cycle and Lean Budgeting

Based in part on the emergence of Agile methods, the Lean Startup [1] strategy recommends a highly iterative ‘build-measure-learn’ cycle for product innovation and strategic investments. Applying this model to epics provides the economic and strategic advantages of a Lean startup—managing investment and risk incrementally—while leveraging the flow and visibility constructs that SAFe provides (See Figure 1).

In addition, the empowerment and decentralized decision-making of Lean Budgets depend on certain checks and balances. Even in the context of an approved value stream budget, epics still require visibility and approval of an MVP estimate prior to implementation. Thereafter, further investment in the epic is controlled locally via ongoing Feature prioritization of the Program Backlog.

Overview of the Portfolio Kanban

Portfolio epics are made visible, developed, and managed through the Portfolio Kanban, where they proceed through various states of maturity until they’re approved or rejected. Understanding the Kanban system is fundamental to the understanding of portfolio epics. The states of the Portfolio Kanban are summarized below:

Portfolio Backlog – Approved epics move to the Portfolio Backlog until they are pulled by one or more Agile Release Trains (ARTs)

Implementing – Implementation begins when capacity from one or more ARTs becomes available

Done – Once its business outcome hypotheses have been evaluated, the epic is considered done. If the hypothesis is proven, more work will be done by implementing additional Features and Capabilities, or possibly new epics. If the hypothesis is proven false, however, the portfolio would pivot to another approach or drop the initiative altogether.

Defining Epics

Reasoning about a potential epic must be based on a definition and intent that stakeholders can agree to. Figure 2 provides an epic hypothesis statement template that can be used to capture, organize, and communicate key information about an epic.

Figure 2. Epic hypothesis statement

Analyzing and Approving Epics

Epics must be analyzed before being committed to implementation. Epic Owners take responsibility for this important task, while Enterprise Architects shepherd the enabler epics that support the technical considerations for business epics. The worthiest epics in the funnel pass to the analysis state when the queue has space.

The result of the analysis phase is a Lean business case. A Lean business case sample format is provided in Figure 3 below.

Figure 3. Lean business case for epics

The appropriate LPM authorities then review the Lean business case to make a go/no-go decision for the epic.

Implementing Epics

Once approved, portfolio epics stay in the portfolio backlog until implementation capacity becomes available from one or more ARTs. The Epic Owner or Enterprise Architect has the responsibility to work with the Product and Solution Management and System Architect/Engineering to define the MVP. Further, epics may be split into Program or Solution-Level epics, or directly into feature or capability backlog items.

Splitting Epics

Incremental implementation of epics means that they must be split into smaller backlog items that represent the incremental value. Table 1 suggests nine methods for splitting epics, along with examples for each:

1. Solution / Subsystem / Component – Epics often affect multiple solutions, subsystems, or large components. In such cases, splitting by these aspects can be an effective implementation technique.

Multiple user profiles

… Multiple profiles in the opt-out website… Multiple profiles in the admin system

2. Business Outcome Hypotheses – The epic business outcome hypotheses often provide hints as to how to incrementally achieve the anticipated business value.

… Provide state information in the search results (criteria [a] is partially satisfied, as states alone already provide some good filtering capability)
… Implement compound location: State and city (entire success criteria is satisfied)

3. Major Effort First – Sometimes an epic can be split into several parts, where most of the effort will go toward implementing the first one.

4. Simple/Complex – Capture that simplest version as its own epic, and then add additional program epics for all the variations and complexities.

5. Variations in Data – Data variations and data sources are other aspects of scope, complexity, and implementation management.

Internationalize all end-user facing screens

… in Spanish… in Japanese… prioritize the rest by then-current market share

6. Market Segment / Customer / Class of User – Segmenting the market or customer base is another way to split an epic. Do the one that has the higher business impact first.

Implement opt-in functionality

… For current partners… For all major marketers

7. Defer Solution Qualities (NFRs) – Sometimes the initial implementation isn’t all that hard, and the major part of the effort is in making it fast—or reliable or more precise or more scalable—so it may be feasible to achieve the solution qualities (NFRs) incrementally.

8. Risk Reduction | Opportunity Enablement – Given their scope, epics can be inherently risky; use risk analysis and do the riskiest parts first.

Solution and Program Epics

The above discussion describes the largest kind of epics, portfolio epics. These are typically cross-cutting and affect multiple ARTs and value streams. Some portfolio epics may require splitting them into solution and program epics to facilitate incremental implementation.

In addition, epic-level initiatives may arise at the large solution or program levels. While largely a local concern, these epics may have an impact on financial, human, and other resources that are large enough to warrant a Lean business case, discussion, and financial approval from LPM. That’s what makes an epic, an epic.