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

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 optimal economic benefit is achieved.

SAFe defines two types of epics: business epics and enabler epics. Each type may occur at the Portfolio, Large Solution, and Program Levels. Although this chapter 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; for further discussion of this figure, see the Continuous Delivery Pipeline chapter).

The Lean Startup Cycle consists of the following: Epic, Build MVP, Evaluate MVP, and Stop work. The Epic tag is shown on the left with a stack containing four layers placed beside it. The third layer of the stack is shaded differently. To the left of the stack is a 2 cross 2 grid in which the first and fourth cells are shaded. To the right is a 1 cross 2 grid in which the first cell is shaded. A note below the Epic tag reads, ‘Approved Lean business case and hypothesis.’ Epic points to Build MVP to its right, which in turn points to a decision box labeled Evaluate MVP. An arrow labeled Pivot from the decision box points right to the stop symbol labeled Stop work. An arrow labeled Persevere points down from the decision box to a block labeled Implement additional Features. This, in turn, points to a stack of four layers in which the second layer is along shaded differently. Local features and other epic inputs point to this stack from the left. The stack loops back to the Implement additional Features block. The loop is labeled ‘Auto-complete Continue until WSJF determines otherwise.’

Figure 1. Epics in the Lean Startup cycle

In addition, the empowerment and decentralized decision-making associated with 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 here:

• Funnel – In this capture state, all big opportunities are welcome.

• Review – The review develops preliminary estimates of opportunity, effort, and cost of delay.

• Analysis – The analysis establishes viability, business outcome hypotheses, MVP, development and deployment impact, Lean business case, and ‘go/no-go’ decision approval.

• 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 proved true, more work will be done by implementing additional Features and Capabilities, or possibly new epics. If the hypothesis is proved false, however, the portfolio pivots to another approach or drops 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.

A table titled Epic Hypothesis Statement is shown. There are seven rows in the first section of the table, that infer the following data: ‘For, <customers>;’ ‘who, <do something>;’ ‘the, <solution>;’ ‘is a, <something – the “how”>;’ ‘that, <provides this value>;’ ‘Unlike, <competitor, current solution, or nonexistent solution>;’ and ‘our solution, <does something better – the “why”>.’ The second section of the table has three rows that infer the following data in the first column: ‘Business outcome hypothesis,’ ‘Leading indicators,’ and ‘NFRs.’ A note beside Leading indicators reads, ‘early innovation accounting measures.’

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.

The ‘Scaled Agile’ logo is present at the top-left of the sheet that is titled ‘Lean Business Case.’ There are three tabs placed one beside the other, below this, labeled Epic Name to enter the short name for the Epic, Funnel Entry Date to enter the Date the Epic entered the funnel, and Epic Owner to enter the name of the Epic Owner. The Epic Description tab is present below, with the note, ‘Consider using the Epic Hypothesis Statement in the Epic article as a starting point for a description of the epic.’ The two tabs below are labeled Business Outcome Hypothesis and Leading Indicators. The description of Business Outcome Hypothesis reads, ‘Describe how the success of the Epic will be measured: for example, 50 percent increase in shoppers under 25; Availability increases from 97 percentage to 99.7 percentage, etc.’ The description of Leading Indicators reads, ‘Establish innovation accounting metrics to provide leading indicators of the outcomes hypothesis: for example, a measurable change in purchaser demographics within 30 days of feature release.’ The three tabs below lists the In Scope, Out of Scope, and Nonfunctional Requirements. The other two tabs below lists the Feature or Capability of the Minimum Visible Product (MVP) Features and Additional Potential Features. Below, the Sponsors that list key business sponsors who will be supporting the initiative, and the Users and Markets Affected that describe the user community and any markets affected maybe entered.

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

The 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.
Implement new artifact in search results: Location hypotheses: a) Locations should provide additional filtering method when other disambiguation methods aren’t useful b) Provide detailed location of a person	... 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.
Implement single sign-on across all products in the suite	... Install PINGID protocol server and test with mock identity provider ... Implement SSO management capability in our simplest product ... Implement SSO in our most complex product ... Proliferate as quickly as backlog capacity allows
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.
Implement filtering search results by complex user-defined expression	... Implement negative filtering ... Implement complex filtering expressions with all logical operations
9. Use Case Scenarios – Use cases [1] can be used in Agile to capture complex user-to-solution or solution-to-solution interaction; split according to specific scenarios or user goals of the use case.
Transitive people search functionality	(Goal 1 ~) Find connection to a person (Goal 2 ~) Find connection to a company (Goal 3 ~) Distinguish strong and weak connections

Table 1. Methods for splitting epics

Solution and Program Epics

The preceding discussion describes the largest kind of epics, portfolio epics. These epics are typically crosscutting efforts that 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 mainly a local concern, these epics may have impacts 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.

Methods for managing epics at these levels are discussed in the Program and Solution Kanban chapter.

LEARN MORE

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

[2] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.