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 before implementation. Implementation occurs over multiple Program Increments (PIs) and follows the Lean startup ‘build-measure-learn’ cycle.

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

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 most significant 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

The Lean Startup [1] strategy, based in part on Agile methods, 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 delivers (See Figure 1).

Figure 1. Epics in the Lean Startup Cycle

(Note: for further discussion of this figure, see Continuous Delivery Pipeline.)

In addition, the empowerment and decentralized decision-making of Lean Budgets depend on specific checks and balances. Even in the context of an approved value stream budget, epics still require visibility and approval of an MVP estimate before implementation. After that, 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 true, more work will be done by implementing additional Features and Capabilities, or possibly new epics. However, if it’s proven false, 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. Figure 2 provides an epic hypothesis statement template that can be used to capture, organize, and communicate critical information about an epic.

Figure 2. Epic hypothesis statement

 

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 quantitative or qualitative benefits that 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 require analysis before being committed to implementation. Epic Owners take responsibility for this critical task, while Enterprise Architects shepherd the enabler epics that support the technical considerations for business epics. The worthiest initiatives 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.

You can download the epic Lean business case template here.

Download Lean Business Case

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 divided into smaller backlog items that represent the additional value. Table 1 suggests nine methods for decomposition, 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 the simplest part of the epic as one item, and then add program or solution 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 a connection to a person
(Goal 2 ~) Find a connection to a company
(Goal 3 ~) Distinguish strong and weak connections

Table 1. Methods for splitting epics

Program and Solution Epics

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

In addition, epic-level initiatives may arise at the program or large solution levels. Since these epics may have an impact on financial, human, and other resources, these initiatives are significant enough to warrant a Lean business case, discussion, and financial approval from Product or Solution Management. Further, epics that exceed the ‘portfolio epic threshold’ Guardrail require review and approval through the Portfolio Kanban system, regardless of whether the initiative arises at the Program, Solution or Portfolio levels. Methods for managing these epics are described in the Program and Solution Kanban article.

 


Learn More

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

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

Last update: 19 September 2018