What is the Scaled Agile Portfolio Level?
The Scaled Agile Portfolio Level is the highest level of concern in the Scaled Agile Framework (SAFe), providing strategic direction and funding to value streams.
The Scaled Agile Portfolio Level is the highest in the Scaled Agile Framework, where the organization’s strategy is aligned with the execution of the work. It provides the necessary business alignment, strategy, and investment funding. This level involves formulating strategic themes that guide the portfolio, setting the context for decision-making. It also includes Lean Portfolio Management, which aligns strategy and execution by applying Lean and systems thinking approaches to strategy and investment funding, Agile portfolio operations, and governance.
The Scaled Agile Portfolio level introduces:
- two new artifact types: investment themes and epics
- a new backlog (the Scaled Agile Portfolio backlog)
- a new team (the Scaled Agile Portfolio management team)
- and the container concepts of Scaled Agile Portfolio Vision and architectural runway.
We’ll begin by discussing investment themes, as that is where everything starts.
What are Investment themes in SAFe?
Investment themes in SAFe are strategic business objectives that guide the allocation of portfolio budgets.
Investment themes are a key aspect of SAFe’s Portfolio Level. They represent the set of business objectives that guide the allocation of portfolio budget in a SAFe portfolio. These themes are derived from the enterprise business strategy and provide a way to communicate strategic intentions for the portfolio. They guide the funding of value streams and help inform the decision-making process regarding which initiatives to run to provide the most value to the business. The themes enable the Lean Portfolio Management function to align strategy to execute effectively.
What are the SAFe Investment Horizons?
- Horizon 1 – Investment in existing product offerings—enhancements, support, and maintenance
- Horizon 2 – Investment in new products and services—products that will increase revenue and/or gain new market share in the current or near-term budget period
- Horizon 3 – Investment in futures—advanced product and service offerings that require investment today but will not contribute to revenue until future years
- Horizon 0 – Reducing investment (sunset strategy) for existing offers that are nearing the end of their useful life
Themes have a much longer lifespan than epics, and investment themes may remain primarily unchanged for up to a year or more. A project management office (PMO) may support the Portfolio Management Team to provide ongoing governance and visibility into the investments.
Who manages the SAFe Portfolio?
The Lean Portfolio Management (LPM) function manages the SAFe portfolio.
The SAFe portfolio is managed by the Lean Portfolio Management (LPM) function, a cross-functional group of people with the authority and competency to fund value streams, manage the portfolio’s work flow, and ensure governance. The LPM includes roles such as the Lean Portfolio Manager, Enterprise Architect, and Epic Owners. They are responsible for strategy and investment funding, Agile portfolio operations, and Lean governance. Their main goal is to align strategy to execution, balancing speed, quality, and value delivery in implementing and supporting the organization’s strategic themes and initiatives.
What is a SAFe Portfolio Epic?
The strategic investment themes drive all new development, and requirements epics are derived from these decisions.
Epics are large-scale development initiatives that realize the value of investment themes.
They are the highest-level requirements artifact used to coordinate development. In the requirements model, they sit between investment themes and features.
- Epics are usually driven (parented by) investment themes. However, some epics can be independent (they do not require a parent to exist).
- Epics are not implemented directly. Instead, they are broken down into Features, and then into User Stories, which the teams use for actual coding and testing.
- Epics are not directly testable. They are tested through the acceptance tests associated with the features and stories that implement them.
What is the Scaled Agile Portfolio Backlog?
The Scaled Agile Portfolio Backlog is a prioritized list of epics to be analyzed and implemented to advance the portfolio’s strategic objectives.
The Portfolio Backlog is the highest-level backlog in the Scaled Agile Framework (SAFe). It’s a prioritized list of business and architectural epics. When implemented, these epics are large initiatives that will realize some portion of the portfolio vision or the strategic themes. The backlog provides a comprehensive view of all the potential work that the different value streams in the portfolio can undertake. It’s a key tool for the Lean Portfolio Management function to align strategy and execution.
Epics deliver the value the theme implies and are identified, prioritized, estimated, and maintained in the Scaled Agile Portfolio backlog. Before release planning, epics are decomposed into features, which in turn drive release planning.
Epics may be expressed in bullet form, as a sentence or two, in a video, in a prototype, in user interface mock-ups, or in any form of expression suitable for conveying the intent of the product initiative. With epics, the objective is vision, not specificity. In other words, the epic need only be described in detail sufficient to initiate further discussion about the types of features an epic implies.
Epics, Features, and Stories
It’s evident by now that epics, features, and stories are all ways of expressing user needs and implied benefits but at different levels of abstraction. This approach reduces premature specificity and the overhead of managing these artifacts for larger systems. More importantly, the reduced specificity of features and epics increases the team’s agility by allowing them to interpret requirements in ways that are easiest to implement and most consistent with the current implementation constructs. Referring to our e-mail example from the previous chapter, we might find the following epic-feature story hierarchy.
What is the SAFe Architectural Runway and Architectural Epics?
The Architectural Runway in SAFe is the existing code, components, and technical infrastructure needed to implement near-term features without excessive redesign.
The Architectural Runway in the Scaled Agile Framework refers to the existing technical infrastructure – including code, components, and design patterns – that supports implementing new features in a product without requiring significant redesign or delay. It’s a metaphor for the existing architecture that allows teams to iterate and deliver incrementally. The runway is continuously extended by implementing enabler epics and maintaining a technological platform that can efficiently and sustainably accommodate changes and new features efficiently and sustainably.
At the Scaled Agile Portfolio level, we also find the last significant block of topics to discuss: Architectural Runway and architectural epics. The architectural runway can be defined as follows:
A system with architectural runway contains existing or planned infrastructure sufficient to allow the incorporation of current and anticipated requirements without excessive refactoring.
In the context of an enterprise’s portfolio of products and the face of a series of shorter, incremental releases, architectural runway answers a crucial question:
What technology initiatives need to be underway now so that we can reliably deliver a new class of features in the next year or so?
Here, we’re not discussing side R&D projects that an enterprise may use to determine technology strategies, establish feasibility, etc. Those are localized efforts and can easily be managed by teams or system architects. Instead, we’re discussing large-scale changes to the code base necessary to support features on the current roadmap and changes that could affect most, or even all, development teams. Here are some examples:
- Implement a common install, licensing, and user authentication model across each product in the suite.
- Convert the transaction server to a microservices-based architecture.
- Redesign the operating system to support symmetrical multiprocessing.
These changes are not simple refactors. They will involve significant, structural changes that could affect millions of lines of code and require dozens (or even hundreds) of person-years. And, if the enterprise wants to accomplish it next year or even the year after, it must start now.
To start now, this work needs to be defined and communicated to the team like any other major initiative, even though the end-user value may be a year or so down the road.
There are at least two types of epics: business epics, which are functional or user-experience epics like those we have already described, and architecture epics, which are used to implement the technological changes necessary for significant elements of the Scaled Agile Portfolio. Within the enterprise, such initiatives must be elevated to the Portfolio level so appropriate teams can start laying the foundation. After all, they require substantial investment. A simple “We’ll refactor it later” approach is not economically viable. No enterprise wants to “do over” the last x00 person-years of work, especially when they always knew they needed to evolve certain core technologies, platforms, security models, and so on, in a coordinated manner.
How do you Implementing Architectural Epics?
Architectural Epics are implemented through their breakdown into features and stories, prioritization in the Portfolio Backlog, and subsequent development and integration by Agile teams.
Architectural Epics in SAFe are large-scale development items that require analysis, the definition of a Minimum Viable Product, and financial approval before implementation. Once approved, these epics are broken down into features and user stories that Agile teams can handle. These smaller items are prioritized in the backlog and pulled into Program Increments for development. Continuous integration and testing are vital throughout the development process to ensure that the epic’s implementation aligns with the architectural runway and contributes to extending this runway for future development work.
However, what should an enterprise do since the agile enterprise no longer relies on the big bang, waterfall, “branch-merge-and-crash-next-year” strategies? The answer is simple to state but challenging to execute. Yet, it’s a crucial agile enterprise ability: Architectural epics will be implemented incrementally in the main code line, just like any other epic. By doing so, development teams commit to a “do no harm” refactoring approach. In other words, they implement these large-scale refactors in small increments. At each PSI, they commit to “do no harm” to the systems or its users. They roll out the architectural changes piecemeal and reveal the new capabilities to the users only when there’s sufficient infrastructure to do so. It isn’t easy. It is agile. And it does work.
Architectural Runway: Portfolio, Program, and Team
The continuous build-out and maintenance of new architectural runway are the responsibility of all mature agile teams. Failing to do so will result in one of two negative outcomes:
- Release dates will be missed because large-scale, just-in-time infrastructure refactoring adds unacceptable risk to scheduling.
- Failure to systematically extend the architecture means teams eventually run out of runway. New features cannot be added without significant refactoring. Velocity slows. The system eventually becomes so brittle and unstable that it has to be entirely rewritten.
This work must happen continuously at each Portfolio, Program, and Team level.
- The Scaled Agile Portfolio-level architectural runway is achieved by defining, communicating, and implementing architecture epics that drive the company’s technology vision. Some will require significant levels of investment and consume substantial resources. In the short term, some may even reduce the velocity of current and new feature implementations. Because failing to implement them will eventually compromise the company’s position in the market, architectural epics must be visible, estimated, and planned just like any other epic.
- Program: At the Program level, product managers, system teams, project teams, and architects translate the architectural epics into architectural features relevant to each release. They are prioritized, estimated, and resourced like any other feature. And, like features, each architectural initiative must also be conceptually complete at each release boundary to not compromise the new release.
- Team: At the Team level, refactors and design spikes are often necessary to extend the runway, and they are prioritized along with user stories. This way, architectural work is visible, accountable, and demonstrable at every iteration boundary. This is achieved by agreement and collaboration with system architects, product owners, and agile tech leads, who determine what spikes need to happen and when.