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 solution development initiative large enough to require analysis, definition of a Minimum Viable Product (MVP), and financial approval prior to implementation. Implementation occurs over multiple Program Increments (PIs), and follows the Lean build-measure-learn startup cycle.
Epics are integral to Lean Portfolio Management 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. (See Continuous Delivery Pipeline).
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.
Epics are the containers that capture and manage the largest initiatives that occur within a Portfolio. They, and the value streams they affect, are the primary concern of the Portfolio level. Business epics directly deliver business value; 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  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). (Note: for further discussion of this figure, see Continuous Delivery Pipeline).
In addition, the empowerment and decentralized decision-making of Lean Budgeting depends on certain checks and balances. Even in the context of an approved value stream budget, epics still require visibility and approval of a 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 rejected or approved. Understanding the Kanban system is fundamental to understanding of portfolio epics. The states of the Portfolio Kanban are summarized below.
Funnel – The capture state
Review – Preliminary estimates of opportunity, effort, and cost of delay
Analysis – Establish viability, outcomes, MVP, development and deployment impact, Lean business case, Go No-go decision
Portfolio Backlog – Epics with “go” approval move to the Portfolio Backlog until implementation capacity is available
Implementation – Implementation begins when capacity becomes available
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.
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 in the funnel pass to analysis when the queue has space. There, effort and economic impact are better defined; Weighted Shortest Job First (WSJF) prioritization is refined; and cost estimates are established.
The result of the analysis phase is a “lean business case.” A lean business case sample format is provided in Figure 3 below.
The appropriate authorities then employ the Lean business case to make a go/no-go decision for the epic.
You can download the Epic lean business case template here.
Once approved, portfolio epics stay in the portfolio backlog until implementation capacity becomes available. The Epic Owner or Enterprise Architect has the responsibility to work with the Product Managers and Architects/Systems Engineering to define the MVP. Further, they split the epics into large solution and program-level epics, or directly into capability or feature backlog items during implementation.
Implementing this way means that an epic must be split into smaller pieces that represent incremental value. This is the art and skill of building large systems incrementally . 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. Success Criteria – The epic success criteria often provide hints as to how to incrementally achieve the anticipated business value.|
|Implement new artifact in search results: Locations Success criteria:
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 another source 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 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 (Nonfunctional Requirements) 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  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 above discussion describes the largest kind of epics, portfolio epics. These are typically cross-cutting, and affect multiple value streams. Many generate solution epics and, correspondingly, program epics. In addition, many such epic-level initiatives arise at the solution or program levels. While largely a local concern, their impact on financial, human, and other resources is large enough to warrant a lean business case, discussion, and financial approval from Lean Portfolio Management (LPM). That’s what makes an epic an epic.
Methods for managing epics at these levels are discussed in the Program and Solution Kanban article.
Learn More Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Random House, Inc. Kindle Edition, 2011.  Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.  Yakyma, Alex. Implementation Strategies for Business Epics
Last Update: 12 July, 2017