Program Epics Abstract
Epics are enterprise initiatives that are sufficiently substantial in scope and costs as to warrant analysis and understanding of potential ROI. Epics require a lightweight business case that elaborates business and technology impact and implementation strategies. Approved epics end up in the Portfolio Backlog, where they await implementation. Portfolio Epics affect multiple release trains; are typically cross-cutting and affect multiple organizations, budgets, release trains and occur over multiple Program Increments.
The subject of this article is Program Epics, which are epics that are constrained to a single train. Because of their scope and impact, they may be introduced through the kanban systems and portfolio backlog, or they may arise locally, but they always require analysis and impact assessment—and some discussion with Program Portfolio Management—before implementation.
Agile Release Trains sometimes face the need to reason about initiatives that represent far larger chunks of value than thinking at the level of Features normally provides. It can simplify the conversation to operate at this higher level of abstraction, and helps assure the pursuit of the right business goals in a cohesive manner. SAFe uses the Program Epic artifact for this purpose.
By definition, these initiatives are large enough to require some analysis and portfolio level discussion before implementation. After all, they are likely to consume a substantial part of the train’s resources, and those empowered to make decisions for the train are also accountable to communicate prospective decisions of such major impact. The nature of this discussion and the program epic life cycle depends on the source, as we describe in the sections below.
Program Epics Originate In the Portfolio
Every portfolio Epic is eventually implemented by ARTs. Typically, these epics are split into the portions that needs to be implemented by a single ART. These are the program epics in support of the parent portfolio epic. For example, a portfolio epic of “Advanced Loyalty Program”, might be split into two program epics:
- “Coupons and points collection support at the Point-Of-Sale” – for the train that takes care of the brick-and-mortar systems
- “Electronic gift cards and discounts” – for the train that supports the e-commerce systems in the enterprise
The approval of the parent portfolio epic happens at the portfolio level, as does the feasibility analysis and exploration of possible implementation paths. Since the resultant program epics may have technical and logical dependencies, Agile Release Trains may not have full decision-making authority in choosing how to split their program epic across multiple Program Increments. Thereafter, in order to ensure consistent implementation across the portfolio, some ongoing scoping and prioritization decisions may still involve portfolio approval. Epic success criteria will reflect both the ART context, and the success criteria of the parent epic.
Program Epics Originate in the Local Context
Not all program epics have parent portfolio epics. Some originate locally in the program context, based on understanding of the changing marketplace or the need to provide technological enablement of future business value. Due to their scope however, these program epics also require portfolio level discussion and approval.
In some cases, a program epic may spawn work in other trains as a result of context coupling in a larger Value Stream. So, in our example of the retail company, the brick-mortar train might initiate an epic: “Pre-order and pickup”. However, they can execute only the “pickup” portion – the “pre-order” function will require the ecommerce ART to develop the functionality on the consumer-facing website. These type of dependencies requires careful treatment and different dimensions of coordination and synchronization, as described in Coordination.
Managing Program Epics
SAFe requires that Program Epics are approved for implementation by the PPM. However, the way these epics are managed through the rest of their lifecycle is open to different implementations. In some cases, all program epics can be managed through the portfolio epic kanban system. In other cases, the number of trains in the enterprise and their context may prohibit managing all program epics in such a centralized way. In this case, an analogous kanban/epic analysis system can be used at the program, or Value Stream level. Regardless, all epics require careful analysis, which may involve prototyping spikes and other research as well as development and approval of the lightweight business case.
Program Epics directly influence program Vision and provide input to Program Backlog. But ARTs never implement an epic per se–all implementation is done by breaking the epics into features. Implementing features incrementally helps ensure that the system always runs while providing sufficient granularity for fast technical and business feedback. This approach may sometimes lead to de-scoping or even canceling some future anticipated elements of a program epic in favor of other initiatives that might generate more business value. The ART always flexes to the best value for the money, that’s it’s basic economics.
 Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
Last update 20 July, 2014
This information on this page is © 2010-2014 Leffingwell, LLC. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact permissions@ScaledAgile.com.