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, 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.
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  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 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:
- Funnel – The capture state where all big opportunities are welcome
- Review – Preliminary estimates of opportunity, effort, and cost of delay
- Analysis – Establish viability, business outcome hypotheses, MVP, development and deployment impact, Lean business case, 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 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.
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.
There are four major fields in the Epic Hypothesis statement:
- The value statement – This is the structured ‘for-who-the …’ portion that describes the epic in general terms
- Business outcomes hypothesis – states the economic or other benefit outcomes the business can anticipate if the hypothesis is proven to be correct
- Leading indicators – describe the early measures that will help predict the business outcomes (For more on this topic, see the Innovation Accounting advanced topic article.)
- NFRS – identifies any Nonfunctional requirements associated with the 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 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.
The appropriate LPM authorities then review the Lean business case to make a go/no-go decision for the epic.
You can download the epic Lean business case template here.Download Lean Business Case
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.
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  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 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.
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.  Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
Last update: 16 April, 2018