SAFe® Glossary

Willkommen beim SAFe® 4.6 Glossary

Das Scaled Agile Framework (SAFe®) ist eine online frei zugängliche Wissensdatenbank mit bewährten, integrierten Mustern für die Implementierung von Lean-Agile Entwicklung. Es bietet eine umfassende Anleitung für die Arbeit auf Portfolio-, Großlösungs-, Programm- und Teamebene.

Hier finden Sie weitere Infos zum Scaled Agile Framework (SAFe®) und hier geht es zu unseren SAFe® Trainings.

Hier erhalten Sie das vollständige Glossar als PDF der Scaled Agile, Inc.

Agile Architecture ist eine Sammlung von Werten und Praktiken, die die aktive 
Entwicklung des Designs und der Architektur eines Systems fördern, während neue System-Capabilitys implementiert werden

Der Agile Release Train (ART) ist ein auf Dauer angelegtes Team von Agile Teams, das zusammen mit seinen Stakeholdern innerhalb eines Value Streams inkrementell eine oder mehrere Lösungen,  bereitstellt und wo möglich betreibt.

Das SAFe Agile Team ist eine cross-funktionale Gruppe von fünf bis zehn Personen, die über die Fähigkeit und Verantwortung verfügen, eine Lösung von Wert, in einer kurzen Iteration zu erzeugen, definieren, entwickeln, testen und wo sinnvoll zu verteilen und releasen. 
 

Der Architectural Runway dient der kurzfristigen Umsetzung von Features. Er besteht aus vorhandenem Code, Komponenten und technischer Infrastruktur, die ohne exzessives Redesign und Verzögerung für die Umsetzung dieser erforderlich sind.

Built-in Quality Praktiken stellen sicher, dass jedes Element der Solution über die gesamte Entwicklung hinweg bei jedem Inkrement den angemessenen Qualitätsstandards entspricht.

Die Business Solutions- and Lean Systems Engineering-Kompetenz beschreibt, wie Lean-Agile Prinzipien und Praktiken auf die Spezifikation, Entwicklung, Bereitstellung und Weiterentwicklung von großen, komplexen Software- und Cyber-physikalischen Systemen angewendet werden.
 

Business Owners sind eine kleine Gruppe von Stakeholdern, die die maßgebliche geschäftliche und technische Verantwortung für Governance, Compliance und den Return on Investment (ROI) einer Solution eines Agile Release Trains (ART) haben. Sie sind Key-Stakeholder des ART, die die Gebrauchstauglichkeit bewerten und daher aktiv an bestimmten ART Events teilnehmen müssen.

Eine Capability ist das Verhalten einer Lösung auf höherer Ebene, das normalerweise in mehreren ARTs entwickelt wird. Capabilities sind in mehrere Features unterteilt, um ihre Implementierung in einem einzelnen PI zu ermöglichen.

Bei Communities of Practice (CoPs) handelt es sich um Personen, die ein gemeinsames Interesse an einer bestimmten Domäne haben und die regelmäßig zusammenarbeiten, um Informationen zu teilen, ihre Fertigkeiten zu erweitern und aktiv darauf hinarbeiten, ihre Kenntnisse auszuweiten.
 

Compliance bezieht sich auf eine Strategie und eine Reihe von Aktivitäten und Artefakten, die es Teams ermöglichen, Lean-Agile-Entwicklungsmethoden anzuwenden, um Systeme mit der höchstmöglichen Qualität zu erstellen und gleichzeitig sicherzustellen, dass sie alle regulatorischen, branchenspezifischen oder anderen relevanten Standards erfüllen.

Die Continuous Delivery Pipeline (auch als „Pipeline“ bezeichnet) beschreibt die Workflows, Aktivitäten und die Automatisierung, die zu einem kontinuierlichen Release der Features führen, die der Endbenutzer als Wert oder Nutzen wahrnimmt.

Continuous Deployment (CD) ist der Prozess, der validierte Features aus Continuous Integration in die Produktionsumgebung verteilt, wo sie getestet und auf das Release vorbereitet werden. Es ist der dritte Schritt in der vierteiligen Continuous Delivery Pipeline, die aus Continuous Exploration (CE), Continuous Integration (CI), Continuous Deployment und Release on Demand besteht.

Continuous Exploration (CE) ist der Prozess, bei dem die Anforderungen des Marktes und der Benutzer kontinuierlich untersucht und eine Vision, eine Roadmap und eine Reihe von Features definiert werden, die diese Anforderungen erfüllen. Es ist der erste Schritt in der vierteiligen Continuous Delivery Pipeline und geht Continuous Integration (CI), Continuous Deployment und Release on Demand voraus.

Continuous Integration (CI) ist der Prozess Features aus dem Program Backlog zu übernehmen und sie in einer Staging-Umgebung zu entwickeln, testen, integrieren und zu validieren. Dort werden sie bereitgestellt für ein Deployment nach Produktion und ein folgendes Release.

Die vier Core Values Alignment, Built-in Quality, Transparenz und Program Execution sind die grundlegenden Überzeugungen, die das Kernstück der Effektivität von SAFe bilden. Diese Leitsätze bestimmen das Handeln für alle, die mit SAFe arbeiten.

Customer (Kunden) sind die letztendlichen Käufer jeder Solution. Sie sind ein integraler Bestandteil des Lean-Agile-Entwicklungsprozesses und Value Streams und haben spezifische Zuständigkeiten in SAFe.

Das Entwicklungsteam ist ein Teil des Agile Teams. Es besteht aus voll zugeordneten Fachleuten, die eine Story, ein Feature oder eine Komponente entwickeln und testen können. Das Entwicklungsteam umfasst in der Regel Softwareentwickler, Tester, Ingenieure und andere engagierte Spezialisten, die zur Vervollständigung fachlicher Anforderung erforderlich sin

DevOps ist eine Denkweise, eine Kultur und eine Reihe technischer Praktiken. DevOps bietet Kommunikation, Integration, Automation und enge Zusammenarbeit zwischen allen Personen, die für die Planung, Entwicklung, Test, Bereitstellung, Release und Wartung einer Solution benötigt werden.

Develop on Cadence ist eine essentielle Methode beim bewältigen inhärenter Variabilität in der Systementwicklung. In einem Flow-basierten System, erfolgen wichtige Aktivitäten gemäß eines regelmäßigen, vorhersehbaren Zeitplans.

Die DevOps- and Release on Demand-Kompetenz beschreiben, wie DevOps und eine Continous-Delivery-Pipeline implementiert werden müssen, um ein Unternehmen in die Lage zu versetzen, Kunden-Nutzen entweder in seiner Gesamtheit oder in Teilen, jederzeit, auf Nachfrage des Marktes  und der Kunden zu releasen.
 

Das Economic Framework ist eine Zusammenstellung von Entscheidungsregeln, die dafür sorgen, dass alle auf die finanziellen Ziele hinarbeiten, und die den Prozess wirtschaftlicher Entscheidungen leiten. Es enthält vier primäre Konstrukte: Lean Budgets, Epic-Finanzierung und -Kontrolle, dezentralisierte Entscheidungsfindung und Job-Sequenzierung auf Basis von Cost of Delay (CoD).

Enabler bilden die Erweiterung des Architectural Runway für zukünftige Geschäftsfunktionen. Dazu gehören Entwicklungen für Explorationen, Infrastruktur, Compliance und Architektur. Sie werden in den verschiedenen Backlogs erfasst und erscheinen in allen Ebenen des Frameworks.

Das Enterprise (Unternehmen) repräsentiert die Geschäftseinheit, der jedes SAFe-Portfolio angehört.

Der Enterprise Architect fördert das adaptive Design und die technischen Methoden und treibt Architekturinitiativen aus der Portfolio-Ebene. Enterprise Architects kümmern sich auch um die Wiederverwendung von Ideen, Komponenten, Services und bestätigten Pattern über verschiedene Solutions innerhalb eines Portfolios.

Eine Epic ist ein Container für eine Solution – eine Entwicklungsinitiative, groß genug, um eine Analyse, die Definition von MVPs (Minimum Viable Products) und die finanzielle Genehmigung vor einer Implementierung zu erfordern. Die Implementierung erfolgt über mehrere Program Increments (PIs) und folgt dem Lean-Startup-„Build-Measure-Learn“-Zyklus.

Epic Owners koordinieren die Epics durch das Portfolio Kanban-System. Sie definieren eine Epic, ihre MVPs (Minimum Viable Products), den Lean-Business-Case und wenn genehmigt unterstützen Sie die Implementierung.

Die Essential SAFe-Konfiguration ist das Herz des Frameworks und der einfachste Ausgangspunkt für eine Implementierung. Es ist der grundlegende Baustein für alle anderen SAFe-Konfigurationen und beschreibt die wichtigsten Elemente, die zur Realisierung der meisten Vorteile des Frameworks erforderlich sind.

Ein Feature ist ein Service, der die Bedürfnisse eines Stakeholder erfüllt. Jedes Feature enthält eine Nutzenhypothese und Akzeptanzkriterien und ist so klein, dass es von einem einzelnen Agile Release Train (ART) in einem Program Increment (PI) bereitgestellt werden kann.

Die Foundation enthält die unterstützenden Prinzipien, Werte, Denkweisen, Implementierungs- Leitlinien und Führungsrollen, die für die erfolgreiche Bereitstellung von Kundennutzen erforderlich sind.

Die Full SAFe Configuration ist die umfassendste Version des Frameworks. Sie unterstützt Unternehmen, die große integrierte Solutions (Lösungen) erstellen und pflegen, die Hunderte von Personen oder mehr erfordern, und umfasst alle Ebenen von SAFe: Team, Programm, Large Solution und Portfolio. Im den größten Unternehmen sind möglicherweise mehrere Instanzen verschiedener SAFe Configurations erforderlich.

Die Innovation and Planning (IP) Iteration erfolgt zu Ende jedes Program Increment (PI) und hat verschiedene Aufgaben. Sie dient als Puffer für die Erreichung von PI-Zielen und stellt Zeit für die Innovation, laufende Schulung, PI-Planung und des Inspect and Adapt (I&A)-Event bereit.

Inspect and Adapt (I&A) ist ein wichtiges Event, das am Ende jedes Program Increment (PI) stattfindet und bei dem der aktuelle Stand der Solution gezeigt und vom Train evaluiert wird. Die Teams reflektieren ihre Arbeit und identifizieren in einem Problemlösungs-Workshop Backlog-Eintrage für Verbesserungen.

Iterations sind die grundlegenden Zeitabschnitte (Time-Boxes) der Agile Entwicklung. Jede Iteration ist eine Timebox fester Dauer, bei der die Agile Teams inkrementell Wert in Form von Software und Systemen bereitstellen, die funktionieren und getestet sind. Die empfohlene Dauer der Timebox ist zwei Wochen. Je nach Geschäftskontext sind jedoch eine bis vier Wochen akzeptabel.

Iteration Execution ist der Prozess, mit dem Agile Teams ihre Arbeit innerhalb der Iteration Timebox erledigen. Sie sorgen so für ein hochwertiges, funktionierendes und getestetes System Increment.

Iteration Goals sind eine Zusammenfassung der geschäftlichen und technischen Ziele, denen das Agile Team in einer Iteration folgt. Sie sind entscheidend für das Koordinieren eines Agile Release Train (ART) als selbstorganisierendes, selbstverwaltendes Team von Teams.

Iteration Planning ist ein Event, bei dem alle Teammitglieder bestimmen, wie viel des Team Backlogs sie bis zur nächsten Iteration liefern können. Das Team fasst die Arbeit als eine Reihe zugesagter Iteration Goals zusammen.

Die Iteration Retrospective ist ein regelmäßig stattfindendes Meeting, bei dem die Mitglieder eines Agile Teams die Ergebnisse der Iteration besprechen, ihre Methoden prüfen und Prozessverbesserungen identifizieren.

Das Iteration Review ist ein kadenzbasiertes Event, bei dem jedes Team das gelieferte Inkrement prüft, um den Fortschritt zu bewerten, und anschließend seinen Backlog für die nächste Iteration anzupassen.

Der Large Solution Level enthält die Rollen, Artefakte und Prozesse, die zur Erstellung großer und komplexer Solutions (Lösungen) erforderlich sind. Es hat einen stärkeren Fokus auf der Erfassung von Anforderungen in Solution Intent, der Koordination mehrerer Agile Release Trains (ART) und Lieferanten (Supplier) und stellt die Einhaltung von Vorschriften und Standards sicher.

Die Large Solution SAFe Konfiguration ist für die Entwicklung der größten und komplexesten Solutions gedacht, die in der Regel mehrere Agile Release Trains und Suppliers, aber keine Portfolioebene benötigen. Dies ist in Branchen wie Luftfahrt und Verteidigung, Automotive und Government üblich, wo die Integration großer Lösungen und nicht die Finanzielle Steuerung über ein Portfolio das Hauptanliegen ist.

Bei Lean Budgets handelt es sich um eine Reihe von Methoden, die den Overhead für die Vergabe von Budgets minimieren, statt über Projekte zu steuern, stärken sie Value Streams und deren ARTs über ein langfristiges Budget-Funding und erlauben so eine Delegation von Budgetverantwortung auf den Train. Dies wird durch objektive Evaluierung von gelieferten Systemen, aktivem Management von Epic-Investitionen und dynamischen Budget-Anpassungen erreicht.

Lean Budget Guardrails beschreiben die Budget-, Governance- und Ausgabenrichtlinien und - praktiken für Lean-Budgets, welche einem bestimmten Portfolio zugeordnet sind.
 

Die Funktion Lean Portfolio Management (LPM) ist die oberste Entscheidungsebene. Es hat das höchste Maß an Entscheidungskompetenz und finanzieller Verantwortung für die Produkte und Solutions in einem SAFe-Portfolio.

Das Lean Enterprise ist ein florierendes Unternehmen im digitalen Zeitalter, das seinen Kunden wettbewerbsfähige Systeme und Lösungen nachhaltig in kürzester Durchlaufzeit liefert.

SAFe basiert auf neun unveränderlichen, grundlegenden Lean und Agile Prinzipien. Diese Grundsätze und wirtschaftlichen Konzepte sind die Basis für alle Rollen und Praktiken von SAFe.

Die Kompetenz Lean-Agile Leadership beschreibt, wie Lean-Agile Leaders organisatorische Veränderungen und operative Exzellenz vorantreiben und aufrechterhalten, indem Einzelpersonen und Teams befähigt werden, ihr höchstes Potenzial abzurufen. Sie erreichen dies, indem sie die Lean-Agile-Denkweise, Werte, Prinzipien und Praktiken von SAFe lernen, vorleben, lehren und coachen.
 

Das Lean-Agile Mindset ist die Kombination von Überzeugungen, Annahmen und Handlungen von SAFe- Leadern und -Praktikern. die auf den Konzepten des Agilen Manifesto und von Lean beruhen. Es ist die persönliche, intellektuelle und Führungsgrundlage zum anpassen und anwenden von SAFe Prinzipien und Praktiken.

Lean User Experience (Lean UX) Design ist eine Denkweise, Kultur und ein Prozess, der Lean-Agile-Methoden nutzt. 
 

Metrics sind abgestimmte Metriken, um zu bewerten, wie gut die Organisation auf Portfolio-, Large Solution-, Programm- und Team-Ebene beim Erreichen der geschäftlichen und technischen Ziele voranschreitet.

Milestones werden verwendet, um den Fortschritt in Bezug aus ein bestimmten Ziel oder Ereignis zu verfolgen. Es gibt drei Arten von SAFe Milestones: Program Increment (PI) Milestones, zeitlich feste Milestones und Milestones des Lernens, zum Beispiel das überprüfen einer Hypothese.

Model-Based Systems Engineering (MBSE) ist die Praxis, eine Reihe verwandter Systemmodelle zu entwickeln, die dabei helfen, ein System in der Entwicklung zu definieren, zu entwerfen und zu dokumentieren. Diese Modelle bieten eine effiziente Möglichkeit Systemaspekte für Stakeholder zu evaluieren, zu aktualisieren und zu kommunizieren während die Abhängigkeit von herkömmlichen Dokumenten erheblich reduziert wird.

Nonfunctional Requirements (NFRs) definieren Systemattribute wie Sicherheit, Verlässlichkeit, Leistung, Wartungsfähigkeit, Skalierbarkeit und Nutzbarkeit. Sie dienen als Randbedingungen oder Einschränkungen auf das Systemdesign über die verschiedenen Backlogs hinweg.

Das Portfolio Backlog ist das Backlog der obersten SAFe Ebene. Es bietet einen Arbeitsbereich für anstehende Business- und Enabler-Epics, die für eine umfassenden Reihe von Solutions vorgesehen sind. Ziel ist die erforderlichen, wettbewerbsfähigen Differenzierungen und betrieblichen Verbesserungen bereitzustellen, die erforderlich sind, um die strategischen Themen zu adressieren und den Geschäftserfolg zu fördern.

Das Portfolio Kanban ist eine Methode, um die Priorisierung und den Fluss von Portfolio- Epics von der Ideenfindung bis zur Implementierung und Fertigstellung zu visualisieren, zu verwalten und zu analysieren.

Das Portfolio Level enthält die Prinzipien, Methoden und Rollen, die erforderlich sind, um eine Reihe von Entwicklungs-Value Streams zu initiieren und zu steuern. Hier werden die Strategie und die Investitionsfinanzierung für Value Streams und ihre Solutions definiert. Diese Ebene bietet auch Agile-Portfolio-Operationen und Lean-Governance für die Mitarbeiter und Ressourcen, die für die Bereitstellung von Solutions benötigt werden.

Die Portfolio-SAFe Configuration alignt die Portfolioausführung entlang der Unternehmensstrategie, indem die Agile Entwicklung um den operationalen Wertfluss durch einen oder mehrere Value Streams organisiert wird. Es bietet geschäftliche Flexibilität durch Grundsätze und Praktiken für Portfoliostrategie und Investitionsfinanzierung, Agile Portfoliooperationen und Lean Governance.

Pre- and Post-Program Increment (PI) Planning Events werden verwendet, um die PI Planung für Agile Release Trains (ARTs) und Suppliers in einem Solution Train vor- und nachzubereiten.

Product Management hat die inhaltliche Autorität für das Program Backlog. Sie sind verantwortlich Kundenbedürfnisse zu identifizieren, Features zu priorisieren, die dafür notwendigen Arbeiten durch ein Program Kanban zu steuern und entwickeln die Program Vision und Roadmap.

Der Product Owner (PO) ist ein Mitglied des Agile-Teams und verantwortlich für die Definition von Stories und die Priorisierung des Team-Backlogs. Ziel ist die Umsetzung von Programmprioritäten zu optimieren und gleichzeitig die konzeptionelle und technische Integrität der Features oder Komponenten für das Team beizubehalten.

Das Program Backlog ist die Liste anstehender Features, die dazu bestimmt sind, für einen Agile Release Train (ART) die Nutzerbedürfnisse zu befriedigen und geschäftlichen Wert zu erzeugen. Es enthält auch die Enabler Features, die für den Bau des Architectural Runway erforderlich sind.

Ein Program Increment (PI) ist eine Timebox, in der ein Agile Release Train (ART) inkrementell Wert in Form von funktionierender und getesteter Software und Systemen liefert. PIs dauern normalerweise acht bis zwölf Wochen. Das häufigste Muster eines PI sind vier Entwicklungsiterationen, gefolgt von einer Innovation and Planning (IP)-Iteration.

Program Increment (PI) Objectives sind eine Zusammenfassung der geschäftlichen und technischen Ziele, die ein Agile Team beim anstehenden Program Increment (PI) erreichen möchte.

Program Increment (PI) Planning ist ein kadenzbasiertes Face-to-Face-Event, das als Herzschlag des Agile Release Train (ART) fungiert. Hierbei werden die Teams im ART auf eine gemeinsame Mission und Vision ausgerichtet.

Die Program and Solution Kanban Systeme dienen zur Visualisierung und Verwaltung des Ablaufs von Features und Capabilities von der Idee über die Analyse, die Implementierung bis zum Release durch die Continuous Delivery Pipeline.

Das Program Level enthält die Rollen und Aktivitäten, die für die kontinuierliche Bereitstellung von Solutions über einen Agile Release Train (ART) notwendig sind.

Refactoring ist die Aktivität zur Verbesserung der internen Struktur oder des Ablaufs eines Programms oder einer Komponente, ohne das externe Verhalten zu ändern.

Der Release Train Engineer (RTE) ist eine dienende Führungskraft und ein Coach für den Agile Release Train (ART) . Die Hauptaufgaben des RTE sind die Erleichterung der ART-Events und -Prozesse, sowie die Unterstützung der Teams bei der Wertschöpfung. RTEs kommunizieren mit Stakeholdern, eskalieren Hindernisse, helfen beim Risikomanagement und treiben kontinuierlich Verbesserungen voran.

Release on Demand ist der Prozess, bei dem in der Produktion verteilte Features basierend auf der Marktnachfrage inkrementell oder sofort freigegeben werden.

Die Roadmap ist ein Zeitplan von Ereignissen und Meilensteinen, die geplante Solution- Lieferungen für einen Zeitraum kommunizieren. Sie enthält Zusagen für das geplante, anstehende Program Increment (PI) und bietet einen Einblick über Lieferungen, die für die nächsten PIs prognostiziert werden.

Die SAFe Implementation Roadmap besteht aus einer Übersichtsgrafik und einer 12-teiligen Serie, die eine Strategie und eine geordnete Reihe von Aktivitäten beschreibt, die sich bei der erfolgreichen Implementierung von SAFe als effektiv erwiesen haben.

SAFe Program Consultants (SPCs) sind Change Agents, die ihr technisches Wissen über SAFe mit einer intrinsischen Motivation kombinieren, um die Software- und System- Entwicklungsprozesse des Unternehmens zu verbessern. Sie spielen eine entscheidende Rolle bei der erfolgreichen Implementierung von SAFe. SPCs kommen aus zahlreichen internen oder externen Rollen, etwa fachliche oder technologische Führungskräfte, wie Portfolio-, Programm-, Projektmanager, Prozessverantwortlichen, Architekten, Analysten und Beratern.

SAFe for Government ist eine Zusammenstellung von Erfolgsmustern, mit deren Hilfe im öffentlichen Bereich Lean-Agile-Praktiken in einem behördlichen Kontext implementiert werden können.
 

SAFe® for Lean Enterprises ist eine Wissensdatenbank mit bewährten, integrierten Prinzipien, Praktiken und Kompetenzen für Lean, Agile und DevOps.

Scrum Masters sind die dienenden Führungskräfte und Coaches eines Agile Teams. Sie helfen das Team in Scrum, Extreme Programming (XP), Kanban und SAFe zu schulen und sorgen dafür, dass dem vereinbarte Agile Prozess gefolgt wird. Sie helfen auch bei der Beseitigung von Hindernissen und fördern eine Umgebung für Hochleistungs-Teams, Continuous Flow und kontinuierliche Verbesserung.

ScrumXP ist ein leichtgewichtiger Prozess zur Wertschöpfung für cross-funktionale, selbstorganisierte SAFe-Teams. Es kombiniert die Leistungsfähigkeit von Scrum- Projektmanagement- mit Extreme Programming (XP) -Praktiken.

Set-Based Design (SBD) ist eine Praxis, die Anforderungen und Designoptionen, während des Entwicklungsprozesses, so lange wie möglich flexibel hält. Statt anfangs eine einzelne „punktuelle“ Lösung auszuwählen, identifiziert SBD mehrere Optionen und untersucht sie gleichzeitig, wobei nach und nach schwache Lösungen verworfen werden. Es erhöht die Flexibilität im Entwurfsprozess, indem technische Lösungen erst übernommen werden, nachdem die Annahmen validiert wurden, was zu besseren wirtschaftlichen Ergebnissen führt.

Bei Shared Services handelt es sich um spezialisierte Rollen, Menschen und Services, die für den Erfolg eines Agile Release Trains (ART) oder Solution Train erforderlich sind, aber nicht Vollzeit zugeordnet werden können.

Jeder Value Stream produziert eine oder mehrere Solutions. aus Produkten, Services oder Systemen, die dem internen oder externen Kunden des Unternehmens bereitgestellt werden.

Die Rolle Solution Architect / Engineering repräsentiert eine einzelne Person oder ein kleines Team, die die gemeinsam genutzte technische und architektonische Vision für die in Entwicklung befindliche Solution definiert. Sie beteiligen sich an der Festlegung des Systems, der Subsysteme und der Schnittstellen, validieren Technologie-Annahmen und evaluieren Alternativen. Dabei arbeiten sie eng mit dem Agile Release Train (ARTs) und dem Solution Train zusammen.

Der Solution Backlog ist die Liste anstehender Capabilities und Enablers, die sich alle über mehrere ARTs hinweg erstrecken können. Er ist dazu bestimmt, die Solution voranzubringen und den Architectural Runway zu bauen.

Der Solution Context identifiziert kritische Aspekte der Betriebs-Umgebung einer Solution. Er bietet ein essentielles Verständnis von Anforderungen, Nutzung, Installation, dem Betrieb und Support der Solution selbst. Der Solution Context beeinflusst stark die Möglichkeiten und Einschränkungen für Release on Demand.

Bei der Solution Demo werden die Ergebnisse der Entwicklungsbemühungen vom Solution Train integriert, evaluiert und für Customer und andere Stakeholder sichtbar gemacht.

Solution Management hat die inhaltliche Autorität für das Solution Backlog. Sie arbeiten zusammen mit den Kunden um deren Bedürfnisse zu verstehen, Capabilities zu priorisieren, die Solution Vision und Roadmap zu erstellen und die notwendigen Arbeiten durch das Solution Kanban zu steuern.

Der Solution Train ist das organisatorische Konstrukt, das zum Aufbau großer und komplexer Solutions verwendet wird, die die Koordination mehrerer Agile Release Trains (ARTs) sowie die Beiträge von Suppliers erfordern. Es verbindet ARTs unter einer gemeinsamen Geschäfts- und Technologie-Mission unter Verwendung von Solution Vision, Backlog und Roadmap und einem ausgerichteten Program Increment (PI) .

Die Spanning Palette enthält verschiedene Rollen und Artefakte, die für ein bestimmtes Team, Programm, eine Large Solution, oder einen Portfoliokontext anwendbar sind. Die Spanning Palette ist ein SAFe-Schlüsselelement mit hoher Flexibilität. Die Konfigurierbarkeit ermöglicht Organisationen nur die Elemente zu verwenden, die benötigt werden.

Spikes entsprechen in SAFe explorativen Enabler Storys Ursprünglich im Extreme Programming (XP) definiert und repräsentieren sie Aktivitäten wie Forschung, Design, Untersuchung, Exploration und Prototyping. Ihr Zweck besteht darin, das notwendige Wissen zu erwerben, um das Risiko eines technischen Ansatzes zu verringern, eine Anforderung besser zu verstehen oder die Zuverlässigkeit von Story Estimates zu erhöhen.

Stories sind kurze, in der Sprache des Benutzers formulierte Beschreibungen einer gewünschten Teil-Funktionalität. Agile Teams implementieren kleine, vertikale Stücke der Systemfunktionalität und sind so dimensioniert, dass sie in einer einzigen Iteration fertiggestellt werden können.

Ein Supplier ist eine interne oder externe Organisation, die Komponenten, Subsysteme oder Services entwickelt und liefert, die Solution Trains dabei unterstützen, Solutions für ihre Kunden bereitzustellen.

Die System Demo ist ein wichtiges Event, das eine integrierte Sicht neuer Features für die aktuelle Iteration bietet. Sie wird von allen Teams im Agile Release Train (ART) bereitgestellt. Jede Demo bietet den ART -Stakeholdern eine objektive Fortschritts-Messung innerhalb eines Program Increments (PI).

Das System Team ist ein spezielles Agile Team, das beim Erstellen und Nutzen der Agile Entwicklungsumgebung hilft, einschließlich Continuous Integration, Testautomatisierung und Continuous Deployment. Das System Team unterstützt die Integration von Assets aus den Agile Teams, führt bei Bedarf End-to-End-Solution-Test durch und unterstützt bei Deployment und Release.

Das Team Backlog enthält Benutzer- und Enabler-Stories, die aus dem Program Backlog stammen, sowie Stories aus dem lokalen Team-Kontext. Es kann auch andere Arbeitsaufgaben enthalten, die das Team erledigen muss, um seinen Teil des Systems voranzubringen.

Team Kanban ist eine Methode, die Teams dabei hilft, den Wertefluss und die Arbeitsabläufe zu visualisieren, Work in Process (WIP) Limits festzulegen, den Durchsatz zu messen und Ihren Prozess laufend zu verbessert.

Das Team Level enthält die Rollen, Aktivitäten, Ereignisse und Prozesse, die den Agile Teams bei der Schöpfung und Bereitstellung von Wert im Kontext des Agile Release Train (ART) helfen.

Die Kompetenz Team and Technical Agility beschreibt die kritischen Fertigkeiten, sowie Lean-Agile-Prinzipien und -Praktiken, die erforderlich sind, um leistungsfähige Agile Teams aufzubauen, die qualitativ hochwertige  Solutions mit gutem technischen Design entwickeln. (Conway Law)
 

Test-First ist eine von Extreme Programming (XP) abgeleitete Built-in-Quality-Methode. Es wird zuerst ein Test geschrieben und dann nur soviel Code erzeugt bis das Testergebnis erfüllt ist. Die Implementierung wird also durch Fokussierung auf die erwarteten Ergebnisse optimiert.

Value Stream Coordination bietet Unterstützung für das Behandeln von Abhängigkeiten und Ausnutzen von Möglichkeiten in einem Portfolio.

Value Streams stellen eine Reihe von Schritten dar, die eine Organisation zum Erstellen von Solutions verwendet. Diese Lösungen erzeugen einen kontinuierlichen Wertfluss für den Kunden. SAFe Value Streams werden verwendet, um Geschäftsziele auf Portfolioebene zu definieren und zu verwirklichen, und organisieren Agile Release Trains (ARTs), um schneller Werte zu liefern.

Die Vision ist eine Beschreibung des zukünftigen Zustands der in Entwicklung befindlichen Solution. Sie spiegelt die Bedürfnisse von Kunden und Stakeholdern sowie die Features und Capabilities wider, die diesen Anforderungen entsprechen.

Weighted Shortest Job First (WSJF) ist ein Priorisierungsmodell, das verwendet wird, um Jobs (z. B. Features, Capabilities und Epics) zu sortieren, um einen maximalen wirtschaftlichen Nutzen zu gewinnen. WSJF wird in SAFe als Quotient aus Cost of Delay (CoD) und Jobsize geschätzt.