Innovation comes from the producer, not the customer.
—W. Edwards Deming
Portfolio epics are made visible, developed, and managed through the Portfolio Kanban, where they proceed through various process states until they are approved or rejected by Lean Portfolio Management (LPM). Approved portfolio epics move to the Portfolio Backlog where they await implementation by an Agile Release Train (ART) or Solution Train.
The portfolio backlog holds epics that have been approved and prioritized for implementation. Due to their scope and typically crosscutting nature, portfolio epics usually require substantial investment and have a considerable impact on both the development programs and business outcomes. Therefore, portfolio epics are analyzed in the portfolio Kanban to establish feasibility, a Lean business case, and a Minimum Viable Product (MVP).
Operating under the auspices of Lean Portfolio Management (LPM) the portfolio backlog brings visibility to upcoming business and enabler epics that have been approved but await implementation capacity. Epics in the portfolio backlog are reviewed periodically and scheduled for implementation based on the availability of capacity in the affected ARTs.
Managing the Portfolio Backlog
However, as Figure 1 illustrates, the portfolio backlog may contain several epics, and additional reasoning must be applied before being scheduled for implementation. This reasoning includes considerations for sequencing work, sizing, and ranking the epics relative to each other, typically by one final, Weighted Shortest Job First (WSJF) prioritization.
In this case, business and enabler epics are typically compared only against each other, inside the capacity allocation and investment horizon Guardrails for each type. Those that rise to the top are then ready for implementation and are pulled from the portfolio backlog when trains have available capacity. However, in addition to job size, an understanding of available program capacity must enter into consideration, because the job duration (the denominator in WSJF) is heavily dependent on the capacity available for implementation.
SAFe enhances enterprise adaptability, providing faster response to changing market opportunities. And Agile delivery seems to work best when we fix the date and ‘float’ the scope. This supports frequent incremental delivery and avoids the inevitable quality trade-offs when all aspects—scope, time, and resources—are fixed. Yet, in the enterprise, Agile or not, some sense of the future is required:
- The enterprise, its partners, and customers need to plan for upcoming releases
- The Vision must define and track to the evolving enterprise strategy
- The Roadmap captures strategic intent in forecasted deliverables
Therefore, the ability to do effective, Agile forecasting is a key economic driver and a key ability of the Lean-Agile enterprise.
Forecasting Requires Estimating
As described in other parts of SAFe, Agile Teams use story points and relative estimating to quickly arrive at estimates for size and duration for user stories. At the program level, Product Managers and System Architects—working with Product Owners and teams wherever appropriate—can use historical data to quickly estimate the size of Features in story points as well. And whenever the economics justify further investment in estimating, teams can break larger features into stories to get a more granular view.
Further, as illustrated in Figure 1, feature estimates, which are identified during the portfolio Kanban analysis state, can then be rolled up into epic estimates in the portfolio backlog, so that the economics of a potential epic are understood before implementation begins.
Finally, and most importantly, given knowledge of program velocities, portfolio managers, and other planners can use capacity allocation for ARTs to estimate how long a portfolio epic might take under various scenarios. This provides a reasonable model for long-term planning and forecasting, as Figure 2 illustrates.
While Agile or not, there is no crystal ball for high-fidelity estimation of large-scale software programs, SAFe provides mechanisms for estimating and planning that have shown themselves to be more reliable than those historically applied with waterfall development methods.
Moving to Implementation
As resources become available within the affected programs, prioritized epics are moved from the ‘portfolio backlog’ state to the ‘implementation’ state of the portfolio Kanban. The Epic Owner shepherds this process forward and works with Product and Solution Management and System and Solution Arch/Engineering to split the epics into program or solution epics, and further into features and Capabilities which are then prioritized in the respective Kanban systems. The epic remains in the implementation stage until the MVP is achieved and when other potential features for the epic cannot compete on value with features from other sources, at which point it is considered to be done.
Learn More Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
Last update: 21 September 2018