Introduction

We have now arrived at the final installment of our series on the Scaled Agile Framework (SAFe) Requirements Model, where we will examine the Portfolio Level. In this concluding post, we will discuss the strategic aspects of SAFe, including investment themes, portfolio management, and the interplay between epics, features, and stories. We’ll also explore the architectural runway and architectural epics, which play a crucial role in enabling the continuous delivery of value at an enterprise scale. By the end of this post, you will have a holistic understanding of the SAFe Requirements Model, empowering you to implement and leverage SAFe in your organization successfully.

Be sure to revisit our earlier posts that provided a “big picture” overview and in-depth explorations of the Team and Program Levels to gain a comprehensive understanding of the entire framework.

The SAFe Portfolio Level

For numerous software organizations, ranging from modestly-sized enterprises with around 100 professionals to those that develop and manage only a couple of products, the team model (incorporating user stories, tasks, and acceptance tests) combined with the program model (integrating features and nonfunctional requirements) may suffice for managing system requirements in an agile manner. In this context, guiding releases with a feature-based vision and steering iterations with stories created by the teams might be all that is necessary.

However, there is another category of enterprises—those employing hundreds or even thousands of practitioners and managing numerous products—where the governance and management model for new software asset development demands additional artifacts and even higher levels of abstraction. In the Big Picture, this is the Portfolio level.

It is worth noting that the Team, Program, and Portfolio “level” boundaries we have established here are arbitrary and serve more as a mental model—a way to think about things at increasingly higher levels of abstraction, scope, and scale—rather than a specific prescription for a particular enterprise. Nevertheless, this level does resemble some actual large and very large-scale agile implementations that have applied the model in variations of the form described here.

The Portfolio level introduces:

  • two new artifact types: investment themes and epics
  • a new backlog (the portfolio backlog)
  • a new team (the portfolio management team)
  • and the container concepts of portfolio vision and architectural runway.

We’ll begin by discussing investment themes, as that is where everything starts.

Investment Themes

Investment themes (or product themes) embody the initiatives that guide an enterprise’s investment in systems, products, applications, and services. They represent crucial product or service value propositions that offer market differentiation and competitive advantage. The collection of strategic investment themes for an enterprise or a business unit within an enterprise establishes the relative investment objectives for that entity. Managers are empowered to develop the initiative in the most economically and business-sensible manner for the enterprise within the partition (budget allocation). However, they typically cannot exceed the budget or borrow resources from other themes without the agreement of the relevant stakeholders. The enterprise exercises its fiduciary responsibility by directing investment towards agreed-upon business priorities through this process.

Portfolio Management Team

The portfolio management function, which consists of individuals ultimately responsible for the individual lines of business, is responsible for making these decisions. In larger enterprises, this typically occurs at the business unit level based on an annual or biannual budgeting process. The portfolio management team makes decisions based on a combination of the following:

  • 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.

Epics and the Portfolio Backlog

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, then into user stories, 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.

Portfolio Backlog

Epics deliver the value the theme implies and are identified, prioritized, estimated, and maintained in the 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.

Architectural Runway and Architectural Epics

At the 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 in 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 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.

Implementing Architectural Epics

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 in the main code line incrementally, 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 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.

Summary

In this post, we explored the Big Picture’s highest portfolio level. We introduced strategic investment themes, epics, the portfolio backlog, and the concept of the architectural runway as essential components for managing agile requirements at scale. We also introduced the portfolio management team as the functional unit responsible for establishing the strategic direction of the products and services developed by the enterprise.