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 with story point size estimates

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.

However, in addition to job size, 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 forward and works with Product and Solution Management and System and Solution Architecture/Engineering to split the epics into Features or Capabilities, which are then managed in the respective program and solution Kanban systems (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.

Due to the scope of epics, completion to original intent is not always the desired case. So, it’s likely that some identified features and capabilities may eventually be discarded. Once its anticipated business outcome hypothesis has been evaluated, the epic is considered done from an LPM perspective.

  • 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, then a decision is made to either pivot with a new hypothesis (and new epic) or to stop work on the Epic. In either case, the epic advances to done, and this marks the completion of work item for the Cumulative Flow Diagram (CFD), if applied at this level.

Epic Owners remain available, during implementation, on a pull basis to share responsibility until the teams have attained a sufficient understanding of the work.


Learn More

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

Last update: 6 September 2019