Skip to content
Scaled Agile Framework - SAFe 5

icon picker
Portfolio Backlog

Content Page. The Portfolio Backlog is the highest-level backlog in SAFe.
image.png
Innovation comes from the producer, not the customer.
—W. Edwards Deming

Portfolio Backlog

It provides a holding area for upcoming business and enabler Epics intended to create and evolve a comprehensive set of Solutions.
Portfolio are made visible, developed, and managed through the , where they proceed through various process states until they are approved or rejected by . 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 collaboratively determine which epics should be chosen for implementation based on the results of a participatory budgeting event, which is described in the 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.
image.png
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, prioritization. Moreover, adjustments may also be made to match the agreed-upon capacity allocation and solution investment horizons as specified by the in .
An understanding of available ART capacity must enter into consideration, because the job duration used by
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 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).
image.png
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 . 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.

Navigation Bar

© Scaled Agile, Inc.
Include this copyright notice with the copied content.
Read the FAQs on how to use SAFe content and trademarks here:
Explore Training at:
This link can't be embedded.
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.