Innovation comes from the producer, not the customer.
—W. Edwards Deming
The Portfolio Backlog is the highest-level backlog in SAFe. It provides a holding mechanism for the upcoming Business and Enabler Epics intended to create a comprehensive portfolio solution set, one that provides the competitive differentiation and/or operational efficiencies necessary to address the Strategic Themes and facilitate business success.
Epics that make it to the portfolio backlog have made their way through the Portfolio Kanban, where they have been reviewed, analyzed and approved for implementation. Epics are estimated in the analysis step. Estimating, in turn, supports the need for portfolio-level forecasting and roadmappping, which gives the enterprise a sense of the future sufficient enough to support effective planning and execution.
The Portfolio Backlog holds and prioritizes Epics that have been approved for implementation. These epics have made it through the Portfolio Kanban system with “go” approval, as is illustrated in Figure 1.
Driven by significant concerns such as business opportunities, mergers and acquisitions, technological change, etc., these epics represent the approved initiatives that are typically used to bind various Agile Release Trains together to do things like apply common infrastructure (ex: “migrate to JBoss app server”) or implement common business behaviors (ex: “implement single sign on across all products in the suite”). This provides the strategy input needed to create a harmonized and value-added solution to Agile Release Trains or Solution Train Customers.
Operating under the auspices of Lean Portfolio Management, the portfolio backlog serves as a final gateway between these ideas and implementation. It provides a ‘low cost holding area’ (not much maintenance is required here) and 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 trains.
Portfolio Backlog Input
Due to their scope and typically cross-cutting nature, epics usually require substantial investment and have considerable impact on both the development programs and business outcomes. Therefore, in order to reach the portfolio backlog, epics must first make their way through the portfolio kanban, where they are analyzed to establish feasibility, a Lean business case, and a Minimum Viable Product. Epics that reach this boundary are in a mature state, in that they have been identified, elaborated, estimated and analyzed as necessary to achieve a “go recommendation” from LPM.
Managing the Portfolio Backlog
However, as Figure 2 illustrates, each is not the only epic in the backlog, and additional reasoning must be applied before being scheduled for implementation. This includes logic considerations for sequencing, size estimation, and ranking the epics relative to each other, typically by one final, WSJF prioritization. In this case, business and enabler epics are typically compared only against each other, inside the capacity allocation 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.[Note: the Lean business case that precedes the portfolio backlog has a more robust prioritization process; this is just a final consideration, whereby the epic is compared to other epics that have also made it through the process. However, in addition to job size, an understanding of available program capacity must enter into consideration, because the job duration (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 tradeoffs 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
- Visions must define, and track to the evolving enterprise strategy
- Roadmaps capture 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 we’ve 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 fairly 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 we’ve illustrated in Figure 2, feature estimates, which are identified during the 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 to estimate how long a portfolio epic might take under various scenarios. This provides a reasonable model for longer term planning and forecasting, as Figure 3 illustrates below.
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 which 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 to the implementation stage of the portfolio kanban. The Epic Owner shepherds this process forward and works with Product and Solution Management and System and Solution Arch/Eng to split the epics into program or solution epics, and further into Capabilities and Features, which are then prioritized in the respective kanban systems. The epic remains in the implementation stage until the MVP is achieved, and until 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, chapter 23.
Last update: 17 June 2017