Innovation comes from the producer, not the customer.

—W. Edwards Deming

 

Portfolio Backlog

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 ‘roadmapping,’ which gives the enterprise a sense of the future sufficient to support effective planning and execution.

Details

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 illustrated in Figure 1.

Figure 1. The Portfolio Backlog holds Epics ready for implementation

Driven by significant concerns such as business opportunities, mergers and acquisitions, and technological change, 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 (LPM), 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 crosscutting 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 (MVP). 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.

Figure 2. Estimates of business and enabler Epics in the Portfolio Backlog

This includes logic considerations for sequencing, size estimation, 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 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.

Forecasting

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
  • 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 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 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.

Figure 3. Portfolio forecasting with epic size estimates, capacity allocation, and program velocities

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 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/Engineering 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

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

Last update: 19 October, 2017