SAFe Glossary

A

Agile ArchitectureAgile Architecture is a set of values and practices that support the active evolution of the design and architecture of a system while implementing new system capabilities.

Agile Release Train (ART)The Agile Release Train (ART) is a long-lived team of Agile teams, which, along with other stakeholders, develops and delivers solutions incrementally, using a series of fixed-length Iterations within a Program Increment (PI) timebox. The ART aligns teams to a common business and technology mission.

Agile TeamThe SAFe Agile Team is a cross-functional group of 5 to 10 people who have the ability and authority to define, build, and test some element of Solution value—all in a short Iteration timebox. Specifically, the SAFe Agile Team incorporates the DevTeam, Scrum Master, and Product Owner roles.

Architectural RunwayThe Architectural Runway consists of the existing code, components, and technical infrastructure needed to implement near-term features without excessive redesign and delay.

B

Business OwnersBusiness Owners are a small group of stakeholders who have the primary business and technical responsibility for governance, compliance, and return on investment (ROI) for a Solution developed by an Agile Release Train (ART). They are key stakeholders on the ART who must evaluate fitness for use and actively participate in certain ART events.

C

CapEx and OpExCapital Expenses (CapEx) and Operating Expenses (OpEx) describe Lean-Agile financial accounting practices in a Value Stream budget. In some cases, CapEx may include capitalized labor associated with the development of intangible assets—such as software, intellectual property, and patents.

Capabilities A Capability is a higher-level solution behavior that typically spans multiple ARTs. Capabilities are sized and split into multiple features to facilitate their implementation in a single PI.

Communities of Practice (CoPs)Communities of Practice (CoPs) are organized groups of people who have a common interest in a specific technical or business domain. They collaborate regularly to share information, improve their skills, and actively work on advancing the general knowledge of the domain.

ComplianceCompliance refers to a strategy and a set of activities and artifacts that allow teams to apply Lean-Agile development methods to build systems that have the highest possible quality, while simultaneously assuring they meet any regulatory, industry, or other relevant standards.

Continuous Delivery PipelineThe Continuous Delivery (CD) Pipeline (also referred to as ‘pipeline’) represents the workflows, activities, and automation needed to provide a continuous release of value to the end user.

Continuous Deployment (CD)Continuous Deployment (CD) is the process that takes validated Features from Continuous Integration and deploys them into the production environment, where they are tested and readied for release. It is is the third element in the four-part Continuous Delivery Pipeline of Continuous Exploration (CE), Continuous Integration (CI), Continuous Deployment, and Release on Demand.

Continuous Exploration (CE)Continuous Exploration (CE) is the process of continually exploring the market and user needs, and defining a Vision, Roadmap, and set of Features that address those needs. It’s the first element in the four-part Continuous Delivery Pipeline, preceding Continuous Integration (CI)Continuous Deployment (CD), and Release on Demand.

Continuous Integration (CI)Continuous Integration (CI) is the process of taking features from the Program Backlog and developing, testing, integrating, and validating them in a staging environment where they are ready for deployment and release.

Core ValuesThe four Core Values of alignment, built-in quality, transparency, and program execution represent the fundamental beliefs that are key to SAFe’s effectiveness. These guiding principles help dictate behavior and action for everyone who participates in a SAFe portfolio.

CustomersCustomers are the ultimate buyer of every Solution. They are an integral part of the Lean-Agile development process and Value Stream and have specific responsibilities in SAFe.

D

Dev TeamThe Dev Team is a subset of the Agile Team. It consists of the dedicated professionals who can develop and test a Story, Feature, or component. The Dev Team typically includes software developers and testers, engineers, and other dedicated specialists required to complete a vertical slice of functionality.

DevOpsDevOps is a mindset, a culture, and a set of technical practices. It provides communication, integration, automation, and close cooperation among all the people needed to plan, develop, test, deploy, release, and maintain a Solution.

Develop on CadenceDevelop on Cadence is an essential method for managing the inherent variability of systems development in a flow-based system, by making sure important events and activities occur on a regular, predictable schedule.

E

Economic FrameworkThe Economic Framework is a set of decision rules that align everyone to the financial objectives of the Solution and guides the economic decision-making process. It contains four primary constructs: Lean Budgets, Epic funding and governance, decentralized decision-making, and job sequencing based on the Cost of Delay (CoD).

EnablersEnablers support the activities needed to extend the Architectural Runway to provide future business functionality. These include exploration, infrastructure, compliance, and architecture development. They are captured in the various backlogs and occur at all levels of the Framework.

EnterpriseThe Enterprise represents the business entity to which each SAFe portfolio belongs.

Enterprise ArchitectThe Enterprise Architect promotes adaptive design, and engineering practices and drives architectural initiatives for the portfolio. Enterprise Architects also facilitate the reuse of ideas, components, services, and proven patterns across various solutions in a portfolio.

EpicAn Epic is a container for a Solution development initiative large enough to require analysis, the definition of a Minimum Viable Product (MVP), and financial approval prior to implementation. Implementation occurs over multiple Program Increments (PIs) and follows the Lean startup ‘build-measure-learn’ cycle.

Epic OwnersEpic Owners are responsible for coordinating portfolio Epics through the Portfolio Kanban system. They define the epic, its Minimum Viable Product (MVP), and Lean business case, and when approved, facilitate implementation.

Essential SAFe configurationThe Essential SAFe configuration is the heart of the Framework and is the simplest starting point for implementation. It’s the basic building block for all other SAFe configurations and describes the most critical elements needed to realize the majority of the Framework’s benefits.

F

FeaturesA Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI).

Full SAFe configurationThe Full SAFe configuration is the most comprehensive version of the Framework. It supports enterprises that build and maintain large integrated solutions, which require hundreds of people or more, and includes all levels of SAFe: team, program, large solution, and portfolio. In the largest enterprises, multiple instances of various SAFe configurations may be required.

GHI

Innovation and Planning IterationThe Innovation and Planning (IP) Iteration occurs every Program Increment (PI) and serves multiple purposes. It acts as an estimating buffer for meeting PI Objectives and provides dedicated time for innovation, continuing education, PI Planning, and Inspect and Adapt (I&A) events.

Inspect & Adapt (I&A)The Inspect and Adapt (I&A) is a significant event, held at the end of each Program Increment (PI), where the current state of the Solution is demonstrated and evaluated by the train. Teams then reflect and identify improvement backlog items via a structured, problem-solving workshop.

IterationIterations are the basic building block of Agile development. Each iteration is a standard, fixed-length timebox, where Agile Teams deliver incremental value in the form of working, tested software and systems. The recommended duration of the timebox is two weeks. However, one to four weeks is acceptable, depending on the business context.

Iteration ExecutionIteration Execution is how Agile Teams manage their work throughout the Iteration timebox, resulting in a high-quality, working, tested system increment.

Iteration GoalsIteration Goals are a high-level summary of the business and technical goals that the Agile Team agrees to accomplish in an Iteration. They are vital to coordinating an Agile Release Train (ART) as a self-organizing, self-managing team of teams.

Iteration PlanningIteration Planning is an event where all team members determine how much of the Team Backlog they can commit to delivering during an upcoming Iteration. The team summarizes the work as a set of committed Iteration Goals.

Iteration RetrospectiveThe Iteration Retrospective is a regular meeting where Agile Team members discuss the results of the Iteration, review their practices, and identify ways to improve.

Iteration ReviewThe Iteration Review is a cadence-based event, where each team inspects the increment at the end of every Iteration to assess progress, and then adjusts its backlog for the next iteration.

JKL

Large Solution LevelThe Large Solution Level contains the roles, artifacts, and processes needed to build large and complex solutions. This includes a stronger focus on capturing requirements in Solution Intent, the coordination of multiple Agile Release Trains (ARTs) and Suppliers, and the need to ensure compliance with regulations and standards.

Large Solution SAFe configurationThe Large Solution SAFe configuration is for developing the largest and most complex solutions that typically require multiple Agile release trains and Suppliers, but do not require portfolio-level considerations. This is common for industries like aerospace and defense, automotive, and government, where the large solution—not portfolio governance—is the primary concern.

Lean BudgetsLean Budgets is a set of practices that minimize overhead by funding and empowering Value Streams rather than projects while maintaining financial and fitness-for-use governance. This is achieved through objective evaluation of working systems, active management of Epic investments, and dynamic budget adjustments.

Lean Portfolio Management (LPM)The Lean Portfolio Management (LPM) function has the highest level of decision-making and financial accountability for the products and Solutions in a SAFe portfolio.

Lean User Experience (Lean UX)Lean User Experience (Lean UX) design is a mindset, a culture, and a process that embraces Lean-Agile methods. It implements functionality in minimum viable increments and determines success by measuring results against a benefit hypothesis.

Lean and Agile PrinciplesSAFe is based on nine immutable, underlying Lean and Agile Principles. These tenets and economic concepts inspire and inform the roles and practices of SAFe.

Lean-Agile LeadersLean-Agile Leaders are lifelong learners who are responsible for the successful adoption of SAFe and the results it delivers. They empower and help teams build better systems by learning, exhibiting, teaching and coaching SAFe’s Lean-Agile principles and practices.

Lean-Agile MindsetThe Lean-Agile Mindset is the combination of beliefs, assumptions, and actions of SAFe leaders and practitioners who embrace the concepts of the Agile Manifesto and Lean thinking. It’s the personal, intellectual, and leadership foundation for adopting and applying SAFe principles and practices.

M

MetricsMetrics are agreed-upon measures used to evaluate how well the organization is progressing toward the portfolio, large solution, program, and team’s business and technical objectives.

MilestonesMilestones are used to track progress toward a specific goal or event. There are three types of SAFe milestones: Program Increment (PI), fixed-date, and learning milestones.

Model-Based Systems Engineering (MBSE)Model-Based Systems Engineering (MBSE) is the practice of developing a set of related system models that help define, design, and document a system under development. These models provide an efficient way to explore, update, and communicate system aspects to stakeholders, while significantly reducing or eliminating dependence on traditional documents.

N

Nonfunctional Requirements (NFRs)Nonfunctional Requirements (NFRs) define system attributes such as security, reliability, performance, maintainability, scalability, and usability. They serve as constraints or restrictions on the design of the system across the different backlogs.

OP

Portfolio BacklogThe Portfolio Backlog is the highest-level backlog in SAFe. It provides a holding area for upcoming business and enabler Epics intended to create a comprehensive set of Solutions, which provides the competitive differentiation and operational improvements needed to address the Strategic Themes and facilitate business success.

Portfolio KanbanThe Portfolio Kanban is a method used to visualize, manage, and analyze the prioritization and flow of portfolio Epics from ideation to implementation and completion.

Portfolio LevelThe Portfolio Level contains the principles, practices, and roles needed to initiate and govern a set of development Value Streams. This is where strategy and investment funding are defined for value streams and their Solutions. This level also provides Agile portfolio operations and Lean governance for the people and resources needed to deliver solutions.

Portfolio SAFe configurationThe Portfolio SAFe configuration helps align portfolio execution to the enterprise strategy, by organizing Agile development around the flow of value, through one or more value streams. It provides business agility through principles and practices for portfolio strategy and investment funding, Agile portfolio operations, and Lean governance.

Pre-and Post-PI PlanningPre– and Post–Program Increment (PI) Planning events are used to prepare for, and follow up after, PI Planning for Agile Release Trains (ARTs) and Suppliers in a Solution Train.

Product ManagementProduct Management has content authority for the Program Backlog. They are responsible for identifying Customer needs, prioritizing Features, guiding the work through the Program Kanban and developing the program Vision and Roadmap.

Product Owner (PO)The Product Owner (PO) is a member of the Agile Team responsible for defining Stories and prioritizing the Team Backlog to streamline the execution of program priorities while maintaining the conceptual and technical integrity of the Features or components for the team.

Program BacklogThe Program Backlog is the holding area for upcoming Features, which are intended to address user needs and deliver business benefits for a single Agile Release Train (ART). It also contains the enabler features necessary to build the Architectural Runway.

Program Increment (PI)A Program Increment (PI) is a timebox during which an Agile Release Train (ART) delivers incremental value in the form of working, tested software and systems. PIs are typically 8 – 12 weeks long. The most common pattern for a PI is four development Iterations, followed by one Innovation and Planning (IP) Iteration.

Program Increment (PI) PlanningProgram Increment (PI) Planning is a cadence-based, face-to-face event that serves as the heartbeat of the Agile Release Train (ART), aligning all the teams on the ART to a shared mission and Vision.

Program KanbanThe Program and Solution Kanban systems are a method to visualize and manage the flow of Features and Capabilities from ideation to analysis, implementation, and release through the Continuous Delivery Pipeline.

Program LevelThe Program Level contains the roles and activities needed to continuously deliver solutions via an Agile Release Train (ART).

QR

RefactoringRefactoring is the activity of improving the internal structure or operation of a code or component without changing its external behavior.

Release Train Engineer (RTE)The Release Train Engineer (RTE) is a servant leader and coach for the Agile Release Train (ART). The RTE’s major responsibilities are to facilitate the ART events and processes and assist the teams in delivering value. RTEs communicate with stakeholders, escalate impediments, help manage risk, and drive relentless improvement.

Release on DemandRelease on Demand is the process by which Features deployed into production are released incrementally or immediately to Customers based on market demand.

RoadmapThe Roadmap is a schedule of events and Milestones that communicate planned Solution deliverables over a timeline. It includes commitments for the planned, upcoming Program Increment (PI) and offers visibility into the deliverables forecasted for the next few PIs.

S

SAFe Implementation RoadmapThe SAFe Implementation Roadmap consists of an overview graphic and a 12-article series that describes a strategy and an ordered set of activities that have proven to be effective in successfully implementing SAFe.

SAFe Program Consultants (SPCs)SAFe Program Consultants (SPCs) are change agents who combine their technical knowledge of SAFe with an intrinsic motivation to improve the company’s software and systems development processes. They play a critical role in successfully implementing SAFe. SPCs come from numerous internal or external roles, including business and technology leaders, portfolio/program/project managers, process leads, architects, analysts, and consultants.

Scrum MasterScrum Masters are servant leaders and coaches for an Agile Team. They help educate the team in Scrum, Extreme Programming (XP), Kanban, and SAFe, ensuring that the agreed Agile process is being followed. They also help remove impediments and foster an environment for high-performing team dynamics, continuous flow, and relentless improvement.

ScrumXPScrumXP is a lightweight process to deliver value for cross-functional, self-organized teams within SAFe. It combines the power of Scrum project management practices with Extreme Programming (XP) practices.

Set-Based DesignSet-Based Design (SBD) is a practice that keeps requirements and design options flexible for as long as possible during the development process. Instead of choosing a single point solution upfront, SBD identifies and simultaneously explores multiple options, eliminating poorer choices over time. It enhances flexibility in the design process by committing to technical solutions only after validating assumptions, which produces better economic results.

Shared ServicesShared Services represents the specialty roles, people, and services that are necessary for the success of an Agile Release Train (ART) or Solution Train but that cannot be dedicated full-time.

SolutionEach Value Stream produces one or more Solutions, which are products, services, or systems delivered to the Customer, whether internal or external to the Enterprise.

Solution Architect/EngineerThe Solution Architect/Engineering role represents an individual or small team that defines a shared technical and architectural vision for the Solution under development. They participate in determining the system, subsystems, and interfaces, validate technology assumptions and evaluate alternatives, working closely with the Agile Release Train (ARTs) and Solution Train.

Solution BacklogThe Solution Backlog is the holding area for upcoming Capabilities and enablers, each of which can span multiple ARTs and is intended to advance the Solution and build its architectural runway.

Solution ContextSolution Context identifies critical aspects of the operational environment for a Solution. It provides an essential understanding of requirements, usage, installation, operation, and support of the solution itself. Solution context heavily influences opportunities and constraints for releasing on demand.

Solution DemoThe Solution Demo is where the results of development efforts from the Solution Train are integrated, evaluated, and made visible to Customers and other stakeholders.

Solution ManagementSolution Management has content authority for the Solution Backlog. They work with customers to understand their needs, prioritize Capabilities, create the Solution vision and roadmap, define requirements, and guide work through the Solution Kanban.

Solution TrainThe Solution Train is the organizational construct used to build large and complex Solutions that require the coordination of multiple Agile Release Trains ARTs, as well as the contributions of Suppliers. It aligns ARTs with a shared business and technology mission using the solution Vision, Backlog, and Roadmap, and an aligned Program Increment (PI)

Spanning PaletteThe Spanning Palette contains various roles and artifacts that may be applicable to a specific team, program, large solution, or portfolio context. A key element of SAFe’s flexibility and configurability, the spanning palette permits organizations to apply only the elements needed for their configuration.

SpikesSpikes are a type of exploration Enabler Story in SAFe. Defined initially in Extreme Programming (XP), they represent activities such as research, design, investigation, exploration, and prototyping. Their purpose is to gain the knowledge necessary to reduce the risk of a technical approach, better understand a requirement, or increase the reliability of a story estimate.

StoriesStories are short descriptions of a small piece of desired functionality, written in the user’s language. Agile Teams implement small, vertical slices of system functionality and are sized so they can be completed by the in a single Iteration.

SupplierA Supplier is an internal or external organization that develops and delivers components, subsystems, or services that help Solution Trains provide Solutions to their Customers.

System DemoThe System Demo is a significant event that provides an integrated view of new Features for the most recent Iteration delivered by all the teams in the Agile Release Train (ART). Each demo gives ART stakeholders an objective measure of progress during a Program Increment (PI).

System TeamThe System Team is a specialized Agile Team that assists in building and using the Agile development environment, including Continuous Integration, test automation, and Continuous Deployment. The System Team supports the integration of assets from Agile teams, performs end-to-end Solution testing where necessary, and assists with deployment and release.

T

Team BacklogThe Team Backlog contains user and enabler Stories that originate from the Program Backlog, as well as stories that arise locally from the team’s local context. It may include other work items as well, representing all the things a team needs to do to advance their portion of the system.

Team KanbanTeam Kanban is a method that helps teams facilitate the flow of value by visualizing workflow, establishing Work In Process (WIP) limits, measuring throughput, and continuously improving their process.

Team LevelThe Team Level contains the roles, activities, events, and processes which Agile Teams build and deliver value in the context of the Agile Release Train (ART).

Test-FirstTest-First is a Built-In Quality practice derived from Extreme Programming (XP) that recommends building tests before writing code to improve delivery by focusing on the intended results.

UV

Value StreamsValue Streams represent the series of steps that an organization uses to build Solutions that provide a continuous flow of value to a Customer. SAFe value streams are used to define and realize Portfolio-level business objectives and organize Agile Release Trains (ARTs) to deliver value more rapidly.

VisionThe Vision is a description of the future state of the Solution under development. It reflects Customer and stakeholder needs, as well as the Feature and Capabilities, proposed to meet those needs.

W

Weighted Shortest Job First (WSJF)Weighted Shortest Job First (WSJF) is a prioritization model used to sequence jobs (ex., Features, Capabilities, and Epics) to produce maximum economic benefit. In SAFe, WSJF is estimated as the Cost of Delay (CoD) divided by job size.