Lean-Agile Portfolio Management for a Modern Strategic Planning

CODA Doc Administration

Explore

Scaled Agile Framework - SAFe 5

Portfolio Backlog

Content Page. The Portfolio Backlog is the highest-level backlog in SAFe.

⁠

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

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⁠

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.

⁠

Navigation Bar

⁠

Portfolio Kanban Content Page. The Portfolio Kanban system is a method to visualize and manage the flow of portfolio Epics, from ideation through analysis, implementation, and completion.⁠

⁠

Scaled Agile Framework - SAFe 5 Header Page. Here you may find a list of contents with all the Knowledge associated to the Portfolio Level of the Scaled Agile Framework (SAFe 5)⁠

⁠

Portfolio Vision Content Page. The Portfolio Vision is a description of the future state of a portfolio’s Value Streams and Solutions and describes how they will cooperate to achieve the portfolio’s objectives and the broader aim of the Enterprise.⁠

⁠

Include this copyright notice with the copied content.

Read the FAQs on how to use SAFe content and trademarks here:

⁠

https://www.scaledagile.com/about/about-us/permissions-faq/⁠

Explore Training at:

⁠

This link can't be embedded.⁠

Portfolio Backlog

Details

Managing the Portfolio Backlog

Moving to Implementation