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 area for upcoming business and enabler Epics intended to create and evolve a comprehensive set of Solutions.

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 one or more Agile Release Trains (ARTs) or Solution Trains.

Details

The portfolio backlog holds epics that have been approved and prioritized for implementation. Due to their scope and typically cross-cutting nature, portfolio epics usually require substantial investment and have a considerable impact on both solutions 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 governance of 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 periodically reviewed and scheduled for implementation based on the available capacity of 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 scheduling an epic for actual implementation. For example, many enterprises will generate more good ideas than it can fund, resulting in a portfolio prioritization challenge. LPM and participants from different Value Streams collaboratively determine which epics should be chosen for implementation based on the results of a participatory budgeting event, which is described in the Lean Budgets article. These choices also determine how the value stream budgets will be adjusted over time to support the implementation of the most important business and enabler epics.

Figure 1. Exploded view of portfolio backlog

Moving to Implementation

The implementation of epics also includes considerations for sequencing work, sizing, and ranking the epics relative to each other, typically by one final, Weighted Shortest Job First (WSJF) prioritization. Moreover, adjustments may also be made to match the agreed-upon capacity allocation and solution investment horizons as specified by the Guardrails in Lean budgets.

An understanding of available ART capacity must enter into consideration, because the job duration used by WSJF is heavily dependent on the capacity available for implementation.

As capacity becomes available within the affected ARTs, prioritized epics are pulled from the ‘portfolio backlog’ state to the ‘implementation’ state of the portfolio Kanban. The Epic Owner shepherds this process and works with Product and Solution Management and System and Solution Architecture/Engineering to decompose the epics into Features or Capabilities, which are then managed in the program and solution kanbans of the affected ARTs (Figure 2).

Figure 2. Epics are pulled into the relevant program and solution backlogs as ART and Solution Train capacity becomes available

When ready, these new features and capabilities are presented at the relevant Program Increment (PI) Planning events, including Pre-PI Planning for Solution Trains to begin implementation of the epic’s MVP. The solution is developed during regular PIs, and the PI Milestones. Leading indicators and value stream key performance indicators (KPIs) provide the objective evaluation of progress.

The iterative, feedback-driven nature of epic development is such that completion of the epic as originally defined in the Lean Business Case is often not required. Some Features and Capabilities may be discarded, replaced with more valuable Features and Capabilities discovered during development of the MVP or implementation of the epic. Although certain epics may warrant additional monitoring, the most common case is that LPM considers an epic ‘done’ once its anticipated business outcome hypothesis has been evaluated.

  • If the benefit hypothesis has been proven true, the value streams will implement more features for the epic until they can no longer compete on value with features from other sources.
  • If the hypothesis is proven false, work on the epic is stopped and a decision is made to either pivot with a new hypothesis (and new epic) or to stop work altogether.

Even though an epic may no longer be considered a portfolio concern, epic owners remain available as needed to assist ARTs and Solution Trains responsible for implementation.


Learn More

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

Last update: 10 February 2021