But the development of human society does not go straight forward; and the epic process will therefore be a recurring process, the series a recurring series – though not in exact repetition.

– Lascelles Abercrombie

Business Epic Abstract

There are two types of Epics in SAFe, Business Epics and Architectural Epics. Business epics are large, typically cross-cutting, customer-facing initiatives that encapsulate the new development necessary to realize the benefits of some investment theme, as well as connections between these themes. Business epics may emerge proactively from the company’s strategy, or they may occur as reactive events, driven by mergers and acquisitions, strategic partnerships, and other unanticipated market events. Like architectural epics, they are indeed “epic” in nature, and share cross-cutting dimensions of:

Time – implementation can take multiple PSI/Releases, even years
Scope – affecting multiple applications, solutions, and business platforms (Release Trains)
Organizations – affecting multiple departments, business units, partners, and others in the end-to-end value chain

Business epics are contained and managed in the portfolio backlog, which is an output of the business epic kanban system. As prioritizing business epics is the key economic driver for the enterprise, the kanban or portfolio backlog system is used to provide the necessary analysis, including estimating the job size and cost of delay, and prioritizing value in accordance with lean Weighted Shortest Job First (WSJF) prioritization.

Details

No matter their source, Business Epics are initially captured in the Business Epic Kanban System and move through this system under work in process (WIP) limits. This helps assure that those doing the work have the time necessary to conduct responsible analysis. Equally importantly, The kanban system helps manage expectations for reasonable scoping and timeframes for implementation of new business ideas. The final decision for actual implementation of each epic is subject to the authority of the Program Portfolio Management Team. So that decision makers can select from the best of a number of possible business opportunities, there will typically be multiple, analyzed epics in the backlog at any time.

Business Epic Flow Through the Kanban System

For a full view of the portfolio kanban system, refer to the article. Figure 1 illustrates a summary view of the queues in the business epic kanban system and the Work In process Limits associated with each. A brief discussion follows.

Figure 1. Business Epic Kanban System queues and WIP limits

Funnel

The identification of business epics takes place at the funnel stage, where ideas are captured. This backlog represents a “low cost holding pattern” where ideas can be captured and discussed at little or no cost or impact. All ideas are welcome here, so there are no work-in-progress (WIP) limits imposed at this stage. Epics can be stated in any format here, typically just a short keyword or phrase such as ”single sign on across all products in the suite”.

Backlog

Epics that reach the Backlog queue warrant a further time investment. One format for stating the purpose and value of the epic at this stage is the Epic Value Statement Format. In the backlog queue, WIP is limited to match resources and an Epic Owner is assigned to shepherd the epic forward through the system. In this stage, epics are also roughly sized for effort and potential value.

Analysis

Epics are primary economic drivers of the program Portfolio Vision, so they must be carefully analyzed before being committed to implementation. In Analysis, effort and economic impact are better defined, WSJF Prioritization is applied and a lightweight business case is developed. Analysis efforts can include:

Workshops with business stakeholders and product management to understand and describe business benefits of the epic
Workshops with System Architects and Agile Team leads to understand implementation effort and impact on current systems
Defining the success criteria for the epic.

The result of the analysis phase is a lightweight business case that will highlight stakeholder sponsors, impact on sales and distribution, development effort, WSJF rating and more. The business case is then used by the appropriate authorities to make a go/no-go decision for the epic. A template for a lightweight business case can be downloaded here. See [Ref 1, Ch 21] for a fuller discussion of the epic business case format.

Success Criteria

The epic value statement format and lightweight business case format both include success criteria, which can be used to validate that implementation is complete and successful. By their very nature, epics are large and tend to be abstract, so defining success criteria is a capstone to establishing a shared understanding among stakeholders of what the epic really implies for the business.

Incremental Implementation

Once approved, the Epic may stay in a holding pattern in the portfolio backlog until such time as there is space available in one or more Release Trains for implementation. Thereafter, the Epic Owner has the responsibility to work with the Product Managers and System Architects to split the epics and work the sub-epics and new Features into the individual Program Backlogs.

Splitting Epics

Implementing incrementally means that business epics must be split into smaller sub-epics (see below) and eventually business (and implied Architectural) Features, which are used to drive the actual implementation. Table 1 provides nine suggested methods for splitting epics, along with examples for each:

1. Product / Subsystem / Component Epics often affect multiple products, 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 Epics success criteria often provides hints as to how to incrementally achieve the anticipated business value.
Implement new artifact in search results: LocationsSuccess 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 (‘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 towards 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 sub-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 System 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 system 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 (Ref [1]) can be used in agile to capture complex user-to-system or system-to-system 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 storing and weak connections

Table 1. Methods for splitting epics

Sub-epics

The Big Picture provides three main levels of abstraction for expressing system behaviors: epics, features, and stories. However, these are arbitrary distinctions, labels to describe how to think about the system at various levels of abstraction. But there is no perfect, one-size-fits-all, hierarchy. For example, work implied by epics must be allocated to the appropriate release trains, where they will eventually be decomposed into features. In such cases a business epic such as “move CRM to the cloud” will spawn a number of smaller epics, one for each affected train. To manage this, some have found it convenient to call these derived epics sub-epics, which creates an additional level in the hierarchy but also provides an additional container for all the program specific features and helps everyone understand where they came from.

Learn More

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

Last Update: 1 April, 2013