Sure it’s a big job; but I don’t know anyone who can do it better than I can.
—John F. Kennedy
Portfolio Epics are enterprise initiatives that are sufficiently substantial in scope so as to warrant analysis and understanding of potential ROI before implementation. Business epics are customer or internally facing development initiatives. Architecture epics are technology initiatives necessary to evolve portfolio solutions to support current and future business needs. Epics are indeed “epic” in nature, as they typically cut across all or some of three business dimensions:
- Time – implementation can take multiple PIs, and Releases
- Scope – affecting multiple release trains, applications, solutions, and business platforms
- Organizations – affecting multiple departments, business units, partners, and others in the end-to-end business value chain
These initiatives are typically used to enhance business value of the full solution set, or harmonize technology for ease of maintenance, or enhancing performance or other nonfunctional requirements. As such, the definition, analysis, selection and implementation of epics are key economic drivers for the portfolio.
Business Epics and Architectural Epics are captured, analyzed and refined in the Business Epic Kanban and Architectural Epic Kanban systems, respectively. Those that are approved are managed in the Portfolio Backlog, which serves as a low cost holding place prior to implementation. As prioritizing epics is a key economic driver for the enterprise, the kanban systems are used to provide the necessary analysis, limit Work In Process, and estimate the job size and cost of delay, and prioritize work accordance with Weighted Shortest Job First (WSJF). An Epic Owner takes responsibility for shepherding an epic through the kanban systems, and when applicable, into implementation.
Epic Value Statement Template
Figure 1 provides an Epic Value Statement template can be used to capture, organize and communicate key information about an epic. This expression is developed in the kanban Review state and intended to provide just enough information to have a meaningful discussion about the proposed initiative.
Epic Lightweight Business Case
During the epic analysis stage in (either the Business Epic Kanban system or the Architectural Epic Kanban System) a Lightweight Business Case is created that captures the results of the analysis, including a refined description, success criteria, estimates of implementation time and cost, and program impact. An example format is provided in Figure 2 below.
You can download a word template for the lightweight business case here:
Approved Epics 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 into Program Epics and new Features into the individual Program Backlogs.
Implementing incrementally means that business epics must be split into Program Epics 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 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 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 ) 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
Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Boston, MA: Addison-Wesley, 2011.
Last update 25 July, 2014
Leffingwell et al. © 2011-2014 Scaled Agile, Inc.
Information on this page 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, visit the Permissions FAQ and Form.