The SAFe (Scaled Agile Framework) Big Picture Explained

Introduction

Welcome to the first post in our series on the Scaled Agile Framework (SAFe) Requirements Model, where we aim to provide you with a comprehensive understanding of how SAFe helps organizations scale Agile principles across different levels. In this “big picture” post, we will present an overview of the SAFe requirements model, briefly introducing the three levels – Team, Program, and Portfolio – that comprise the framework. In the subsequent posts, we will take a deep dive into each of these levels to explore their intricacies in detail. By the end of this series, you’ll have a solid grasp of the roles, processes, and elements that make up the SAFe framework, empowering you to apply these concepts in your organization effectively.

Be sure to follow along as we unravel the complexities of the SAFe Requirements Model, one level at a time.

The SAFe Big Picture Highlights

The Big Picture serves as both an organizational and process model for agile requirements practices, and we’ll delve into its many intricacies. As an overview, the following highlights stand out:

The Team Level

At the Team level, agile teams consist of 7±2 members who define, build, and test user stories through a series of iterations and releases. In smaller enterprises, there may only be a few such teams. In comparison,

larger enterprises may have groups or pods of agile teams collaborating to develop more extensive functionality into complete products, features, architectural components, subsystems, etc. The product owner manages the backlog of user stories and tasks the team must complete.

The Program Level

At the Program level, large-scale system functionality is developed through multiple teams working in a synchronized Agile Release Train (ART). The ART follows a standard cadence of timeboxed iterations and milestones with fixed dates and quality requirements while the scope remains variable (no iron triangle). The ART produces releases or potentially shippable increments (PSIs) at regular, typically fixed, 60- to 120-day intervals. These increments can be released to the customer or not, depending on the customer’s ability to adopt new products and external events influencing timing.

Defining system features at this level is generally called the product manager, although various other titles can apply to this position.

The Solution Level

Multiple Agile Release Trains (ARTs) and Suppliers at the Solution Level collaborate to deliver large and complex solutions. The Solution Level addresses the challenges faced when building these comprehensive solutions that require additional coordination, architecture, and integration work. A Solution Train, similar to an ART, is responsible for synchronizing and coordinating the efforts of multiple ARTs and suppliers. The Solution Train delivers integrated, tested, and evaluable solution increments, following the same cadence as the ARTs within the train. The Solution Management team, which includes the Solution Manager and Solution Architect/Engineer, is responsible for defining the solution’s capabilities, guiding the overall architectural direction, and ensuring that the various ARTs and suppliers work together to deliver a cohesive, high-quality solution.

The Portfolio Level

At the Portfolio level, we discuss a combination of investment themes to guide the enterprise’s investment priorities. Investment themes drive the portfolio vision, expressed as a series of larger, epic-scale initiatives allocated to different release trains over time. These themes ensure that the work being carried out aligns with the business strategy.

Big Picture: Team Level

Agile teams are crucial as they write and test the code that delivers value to end users. The “front line” of software development is composed of agile teams that develop and test code while working together on building more extensive systems. Each agile team has a maximum of seven to nine members, encompassing all roles that are needed to define, build, and test the software for its feature or component. Roles include a Scrum/Agile Master, product owner, dedicated developers, testers, test automation experts, and possibly a tech lead.

In their daily work, the team receives support from architects, external QA resources, documentation specialists, database experts, SCM/build/infrastructure support personnel, internal IT, and others. This support enables the core team to develop, test, and deliver working, effective, and tested software.

Testing is integral to value delivery, making testers essential team members. Testers often belong to the QA organization but are dedicated to an agile team. They primarily align with the team but collaborate with the QA organization for skills development, automation expertise, and specialty testing capabilities. The agile team is responsible for the quality of their work product and cannot delegate this responsibility to other organizations.

Teams are usually organized to deliver software features or components, with most enterprises having a mix of both. Agile teams are self-organizing and reorganizing as needed based on the program backlog. The team composition is dynamic enough to adapt to changing priorities.

In larger enterprises, several teams (three to ten) cooperate to build a more significant feature, system, or subsystem (the program domain in the Big Picture). Experience shows that even for large systems, architectural partitions lead to “pods” of developers organized around implementation domains. This implies that about 50 to 100 people must collaborate intensively on building their “next bigger thing” in the hierarchy, which is referred to as a program. This size also enables face-to-face, collaborative release planning.

There might be multiple programs for large systems, each handling different aspects of the overall solution. This complexity requires effective coordination and communication among the various programs to ensure seamless integration and alignment of objectives.

The Big Picture’s Team Level highlights the importance of collaboration, adaptability, and shared responsibility within agile teams. Each team plays a crucial role in developing and delivering value to end users, and effective teamwork is vital to the success of large-scale systems. As the foundation of the SAFe framework, understanding the team level sets the stage for exploring the higher levels of the model, which involve managing and coordinating the efforts of multiple teams to achieve broader organizational goals.

Roles in the Agile Team

Product Owner

Scrum is the prevalent agile method, and the product owner role is distinct, albeit arbitrarily, defined within it. In Scrum, the product owner determines user requirements, prioritizes them, and maintains the product backlog. Furthermore, even if a team isn’t using Scrum, implementing the product owner role—can significantly simplify the team’s work and organize the entire team around a single, prioritized backlog.

The product owner’s responsibilities extend beyond these tasks, in alignment with Agile Manifesto principle #4—Business people and developers must work together daily throughout the project—the product owner should ideally be co-located (virtually or physically) with the team and actively participate in the team’s daily activities.

Scrum Master

For teams implementing Scrum, the Scrum Master is a crucial (though occasionally transitional) role. The Scrum Master serves as the team-based management/leadership proxy, assisting the team in transitioning to the new method and constantly facilitating a team dynamic designed to optimize performance. In teams that don’t adopt Scrum, a similar leadership role typically falls on a team lead, an internal or external coach, or the team’s line manager. As their skills progress, many Agile Masters become future leaders by demonstrating their ability to deliver user value and continuously improve agile practices.

Developers and Testers

The remaining core team members are the developers and testers who create and test the code. Given that this is an agile team, the team size is generally limited to around three to four developers plus one to two testers, who are (ideally) co-located and collaborate to define, build, test, and integrate stories into the code baseline.

Iterations

In agile development, new features are built during short, time-boxed events called iterations (sprints in Scrum). Each iteration represents a valuable increment of new functionality, achieved through a continuously repeating pattern: plan the iteration, build and test stories, demonstrate new functionality to stakeholders, inspect and adapt, and repeat. The iteration serves as the “heartbeat of agility” for the team, with teams focusing primarily on developing new features within these short timeboxes. Agile teams in larger enterprises typically adopt a standard iteration length and share start and stop boundaries to ensure consistent code maturity at each iteration-boundary integration point. All teams in the Big Picture have the same iteration length for simplicity. Though no mandated length exists, most have converged on a recommended two-week duration.

Number of Iterations per “Release”

A series of iterations aggregates larger, system-wide functionality for release (or potential release) to external users. In the Big Picture, we’ve illustrated four development iterations (with complete iteration backlogs) followed by one hardening (or stabilization) iteration (with an empty backlog) before each release increment. This pattern is arbitrary, with no fixed rule for the number of iterations before a potentially shippable increment (PSI). Many teams follow this model with four to five development iterations and one hardening iteration per release, creating a cadence of a PSI about every 90 days. This rhythm aligns with a reasonable external release frequency for customers and provides a quarterly planning cadence for the enterprise. The length and number of iterations per release increment and the decision on when to release an increment are left to the enterprise’s discretion.

User Stories and the Team Backlog

User stories (often referred to as just stories) serve as the versatile, agile replacement for what has conventionally been called software requirements.

Initially developed within the framework of XP, user stories have become pervasive in agile development in general and are commonly taught in Scrum, XP, and most other agile methodologies. In agile, user stories are the primary elements carrying the customer’s requirements through the value stream—from needs analysis to code and implementation.

Contrary to requirements (which, by standard definition, represent something the system must do to meet a business need or contractual obligation), user stories are concise statements of intent describing what the system needs to do for a specific user. As typically taught, the user story often adopts a standard user-voice format as follows:

As a <user role>, I can <activity> so that <business value>.

This format helps the team concentrate on the user’s role and the business benefit of the new functionality. This construct is essential to agile’s strong emphasis on value delivery.

Team Backlog

The team’s backlog (often called a project or product backlog) comprises all the user stories the team has identified for implementation. Each team has its backlog, managed and prioritized by its product owner. While the team’s backlog may also contain other items—defects, refactors, infrastructure work, etc.—the team’s primary focus remains yet-to-be-implemented user stories.

Identifying, maintaining, prioritizing, scheduling, elaborating, implementing, testing, and accepting user stories constitute the primary requirements management process at play in the agile enterprise.

Tasks

To track the activities involved in delivering stories in more detail, teams usually break down stories into tasks that individual team members must complete to finish the story. Some agile training employs the task object as the basic estimating and tracking metaphor. However, the focus of iteration tracking should be on the story level, as this keeps the team centered on business value rather than individual tasks. Tasks offer a micro-work breakdown structure that teams can use (or not) to facilitate coordination, estimation, tracking status, and assigning individual responsibilities to help ensure the completion of the stories and the iteration.

Big Picture: Program Level

At the Program Level, we encounter additional organizational structures, roles, processes, and requirements artifacts tailored to construct larger-scale systems, applications, products, and suites.

Releases and Potentially Shippable Increments

While every iteration aims to generate a shippable increment of software, teams (particularly those in larger-scale enterprises) may find it impractical or unsuitable to ship an increment at each iteration boundary. For instance, during a series of iterations, the team might accumulate technical debt that needs resolution before shipping. Technical debt can consist of defects to be fixed, minor code refactoring, postponed system-wide testing for performance, reliability, or standards compliance, or finalizing user documentation. The Big Picture includes hardening iterations (represented by an iteration with an empty backlog) to allocate time for these extra tasks.

Furthermore, there are valid business reasons for not shipping every increment to the customer. These include the following:

  • Possible interference with customer licensing and service agreements
  • Potential overhead and business disruption for the customer regarding installation, user training, etc.
  • Risk of disrupting the customer’s current operations due to minor regressions or defects

For these and other reasons, most programs consolidate a series of iterations into a potentially shippable increment, which can be released or withheld based on the prevailing business context.

Vision, Features, and the Program Backlog

Within the enterprise, the product management function (or possibly program management or business analysis) is mainly responsible for preserving the Vision of the products, systems, or applications within their sphere of influence.

The Vision addresses the essential questions for the system, application, or product, including the following:

  • What issue does this specific solution address?
  • What features and advantages does it offer?
  • Who are the intended users?
  • What levels of performance, reliability, etc., does it provide?
  • Which platforms, standards, applications, and so on will it support?

The Main Content of the Vision Is a Set of Features

A Vision may be preserved in a document, backlog repository, or straightforward briefing or presentation format. Regardless of its form, the primary content of the Vision document is a prioritized collection of features designed to deliver value to users.

Nonfunctional Requirements

Moreover, the Vision must also encompass various nonfunctional requirements, such as reliability, accuracy, performance, quality, compatibility standards, and so on, necessary for the system to achieve its goals. Unimplemented Features Populate the Program Backlog Similar to the team’s backlog, which mainly contains stories, the program (or release) backlog holds the set of desired and prioritized features that have yet to be implemented. The program backlog may or may not include estimates for the features. However, any estimates at this level are rough and imprecise, avoiding excessive investment in premature feature elaboration and estimation.

Release Planning

In line with emerging agile enterprise practices, each release increment timebox begins with a release planning session that the enterprise uses to establish the organizational context and align teams with shared business objectives for the release. The input for the release planning session is the current Vision, accompanied by a set of objectives and a desired, prioritized feature set for the upcoming release.

The teams plan the release by breaking features into stories and applying the agreed-upon iteration cadence and knowledge of their velocity, typically in a group setting. During this process, the teams resolve their interdependencies and design the release by placing stories into the iterations available within the PSI timebox. They also negotiate scope trade-offs with product management, using their known velocity and estimates for the new stories to determine what is feasible and what is not. In addition to the plan itself, another key outcome of this process is a commitment to a set of release objectives and a prioritized feature set. Subsequently, the teams strive to fulfill their commitment by meeting the primary objectives of the release, even if it turns out that not every feature can make the deadline.

The Roadmap

The outcomes of release planning are utilized to update the (product or solution) Roadmap, which offers an understanding of how the enterprise aims to deliver increasing value over time.

The Roadmap comprises a series of planned release dates, each with a theme, a set of objectives, and a prioritized feature set. The “next” release on the Roadmap is committed to the enterprise based on the work completed in the most recent release planning session. Releases beyond the next one are not committed, and their scope is somewhat vague.

Thus, the Roadmap embodies the enterprise’s current “plan of intent” for upcoming and future releases. However, it is subject to change—as development facts, business priorities, and customer needs change—and therefore release plans beyond the next release should not generally be used to establish any external commitments.

Product Management

In agile, there can be a challenge with the seemingly overlapping responsibilities of the product manager and the product owner. For instance, in Scrum, the product owner is responsible for the following:

representing the interests of everyone with a stake in the resulting project… achieves initial and ongoing funding by creating the initial requirements, return on investment objectives, and release plans.

In some smaller organizational contexts, that definition functions adequately, and one or two product owners are all that are needed to define and prioritize software requirements. However, in the larger software enterprise, the set of responsibilities conferred in the Scrum product owner is more typically a much broader set of responsibilities shared between the team and technology-based product owners and market or program-based product managers, who carry out their traditional responsibilities of both defining the product and presenting the solution to the marketplace.

However, it is also worth noting that the title of the person who assumes this role may vary by industry segment.

Responsibilities of the Agile Product Manager in the Enterprise

Regardless of the title (we will continue to use product manager generically), when an agile transition is underway, the person playing that role must fulfill the following primary responsibilities:

  • Own the Vision and program (release) backlog
  • Manage release content
  • Maintain the Product Roadmap
  • Build an effective product manager/product owner team

Big-Picture: Portfolio Level

At the apex of the Big Picture, we find the portfolio management function, encompassing individuals, teams, and organizations dedicated to managing the enterprise’s investments in line with the enterprise’s business strategy. We also discover two new artifact types, investment themes and epics, which jointly form the portfolio vision.

Investment Themes

A collection of investment themes defines the relative investment objectives for the enterprise or business unit. These themes guide the vision for all programs, and new epics stem from these themes. The portfolio managers, who may be line-of-business owners, product councils, or others with fiduciary responsibilities to stakeholders, are responsible for deriving these decisions. The outcome of the decision process is a set of themes—crucial product value propositions that offer marketplace distinction and competitive advantage. Themes have a considerably longer lifespan than epics, and themes may remain mostly unchanged for a year or more.

Epics and the Portfolio Backlog

Epics symbolize the most comprehensive expression of a customer’s need. Epics are development initiatives designed to deliver the value of an investment theme and are identified, prioritized, estimated, and preserved in the portfolio backlog. Before release planning, epics are broken down into specific features, then transformed into more detailed stories for implementation.

Epics can be expressed in bullet form, user-voice story form, as a sentence or two, in video, as a prototype, or in any form suitable to convey the product initiative’s intent. With epics, the goal is strategic intent, not specificity. In other words, the epic only needs to be detailed enough to initiate further discussion about the types of features an epic suggests.

Architectural Runway

Design (architecture) and requirements are merely two facets of the same coin—the “what” and the “how.” Although this post concentrates on requirements, we cannot overlook architecture, as experience shows that teams that construct some amount of architectural runway, which is the capacity to implement new features without excessive refactoring, will eventually triumph in the marketplace. Thus, any effective examination of agile requirements must also address the topic of architecture. As a result, the system architecture is a first-class component of the Big Picture and a standard portfolio investment consideration for the agile enterprise.

Summary

In this post, we presented the Big Picture as the fundamental requirements artifact, process, and organizational framework for handling software requirements in a lean and agile way. For agile teams, the model employs the minimal amount of artifacts, roles, and practices required for a team to be efficient. However, the model grows as necessary to the Program and Portfolio levels, consistently providing the most streamlined approach to managing software requirements, even as teams collaborate to construct increasingly larger systems of systems. In the upcoming chapters, we will delve deeper into each of these levels.