SAFe 4.0 – Glossar - Scaled agile framework€¦ · Lean-Agile Leaders Lean-Agile Leaders sind Personen, die ständig hinzulernen und für die erfolgreiche Umsetzung von SAFe und

©2017 Scaled Agile, Inc. Alle Rechte vorbehalten. | www.scaledagileframework.com 1

SAFe® 4.0 – Glossar

Scaled Agile Framework® – Begriffe und Definitionen DEUTSCH

bereitgestellt von

VERSION 4.0.2


Agile Architecture Agile Architecture ist eine Sammlung von Werten und Praktiken, die das Design und die Architektur eines Systems fördern und dabei neue Geschäftsfunktionen implementieren.

Agile Release Train Der Agile Release Train (ART) ist ein langfristig bestehendes Team-of-Agile-Teams, das zusammen mit anderen Beteiligten inkrementell Solutions entwickelt und bereitstellt. Dabei wird eine Abfolge feststehender Iterationen innerhalb der Program-Increment-Timebox verwendet. Der ART richtet Teams im Hinblick auf gemeinsame Geschäfts- und Technologie-Missionen aus.

Agile Teams Agile Teams sind Teams bestehend aus drei bis neun engagierten Individuen, die alle Rollen abdecken, die zum Definieren, Erstellen und Testen eines qualitativen und wertvollen Inkrements in einer Iteration erforderlich sind.

Architectural Runway Der Architectural Runway besteht aus vorhandenem Code, Komponenten und technischer Infrastruktur, die für die kurzfristige Umsetzung von priorisierten Features erforderlich sind.

Budgets Siehe Lean-Agile Budgeting.

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

Business Epic Siehe Epic.

Business Owners Business Owners sind eine kleine Gruppe von Beteiligten, die die Hauptverantwortung für die technische Ausführung, Gebrauchstauglichkeit, Governance und Return on Investment (ROI) einer Solution tragen, welche durch einen Agile Release Train (ART) entwickelt wird. Sie sind Key-Stakeholder am ART und nehmen aktiv an bestimmten Ereignissen teil.

Capability Eine Capability ist ein High-level Solution-Verhalten, das sich normalerweise über mehrere Agile Release Trains (ARTs) erstreckt. Ihre Größe und ihr Umfang werden so angepasst, dass sie in ein einzelnes Program Increment passen.

CapEx und OpEx Kapitalausgaben (CapEx) und Betriebsausgaben (OpEx) beschreiben Lean-Agile-Finanz-Praktiken zur Nachverfolgung von Kapitalausgaben (CapEx) und Betriebsausgaben (OpEx) innerhalb eines Value Stream Budgets. In manchen Fällen enthalten CapEx möglicherweise kapitalisierte Eigenleistungen, die bei der Entwicklung immaterieller Vermögenswerte wie Software, geistigem Eigentum und Patenten anfallen.


Communities of Practice Communities of Practice (CoPs) sind Gruppen von Menschen mit gemeinsamem Interesse in einem bestimmten technischen oder geschäftlichen Bereich. Sie arbeiten regelmäßig zusammen, um Informationen auszutauschen, ihre Fähig- und Fertigkeiten zu verbessern und das allgemeine Wissen in diesem Bereich zu vergrößern.

Continuous Integration Continuous Integration ist eine Built-in Quality-Methode, bei der Teammitglieder ihre Arbeit laufend einbringen und überprüfen. Dabei werden automatisierte Umgebungen zum Erstellen und Testen verwendet, damit Probleme und Defekte zügig erkannt werden.

Coordination Siehe Value Stream Coordination.

Core Values Core Values definieren die Ideale und Überzeugungen, die das Kernstück der Effektivität von SAFe bilden. Diese lauten: Ausrichtung, Built-in Quality, Transparenz und Programmausführung.

Customer Der Customer ist jede Person, die die Arbeit eines Value Streams konsumiert. Customer sind ein integraler Bestandteil des agilen Entwicklungsprozesses und Value Streams.

Develop on Cadence Develop on Cadence ist eine Strategie zur Verwaltung der inhärenten Variabilität bei der Solutionentwicklung, bei der wichtige Ereignisse und Aktivitäten gemäß einem regelmäßigen, vorhersehbaren Zeitplan erfolgen.

DevOps DevOps ist eine Denkweise, eine Kultur und eine Reihe technischer Methoden, die zusammen genommen die Kommunikation, Zusammenarbeit und Kooperation, der an der Entwicklung, dem Testen, Bereitstellen und Pflegen einer Solution beteiligten Fachleute fördern.

Economic Framework Das Economic Framework ist eine Zusammenstellung von Entscheidungsregeln, die dafür sorgen, dass alle Beteiligten auf das Missionsziel hinarbeiten, die die wirtschaftlichen Vor- und Nachteile abwägen und die Einhaltung des vom Program Portfolio Management vorgegebenen Budgets sicherstellen.

Enablers Enablers bringen die Erkundungs-, Infrastruktur- und Architekturentwicklungsaktivitäten voran, die für die Unterstützung der zukünftigen Geschäftsfunktionalität erforderlich sind. Enablers stammen aus dem Backlog und treten auf allen Ebenen des Frameworks auf, wo sie als Enabler Portfolio Epics, Enabler Capabilities, Enabler Features oder Enabler Stories bezeichnet werden.

Enterprise Das Enterprise stellt die Geschäftsentität dar, bei der die ultimative strategische, treuhänderische und Governance-Autorität über alle Value Streams der Entwicklung liegt, aus denen ein Portfolio besteht.

Enterprise Architect Der Enterprise Architect fördert das adaptive Design und die technischen Methoden und bringt strategische Architekturinitiativen für ein Portfolio voran. Enterprise Architects kümmern sich um die Wiederverwendung von Ideen, Komponenten und bestätigten Muster über Solutions hinweg.


Epic Eine Epic ist eine wesentliche Initiative, die normalerweise Einfluss auf mehrere Value Streams und ARTs hat. Epics erfordern eine Analyse mit einem leichtgewichtigen Business Case und eine finanzielle Genehmigung vor der Umsetzung. Es gibt zwei Arten von Epics: Business Epics und Enabler Epics, die auf den Ebenen Portfolio, Value Stream und Program Level auftreten können.

Epic Owners Epic Owners sind für die Koordinierung der Portfolio Epics durch das Portfolio Kanban-System verantwortlich. Sie entwickeln den Business Case und arbeiten nach erfolgter Genehmigung direkt mit den Stakeholdern in den ausgewählten Agile Release Trains (ARTs) zusammen, um die Implementierung voranzutreiben.

Feature Ein Feature ist ein vom System bereitgestellter Service, der die Bedürfnisse der Stakeholder erfüllt und von einem einzelnen ART bereitgestellt werden kann. Jedes Feature enthält eine Übersicht der Nutzenargumente und Akzeptanzkriterien und passt in ein einzelnes Program Increment.

Implementing 1-2-3 Implementing 1-2-3 ist ein bewährtes Vorgehensmuster für die Einführung von SAFe. Es beschreibt drei grundlegende Schritte: 1) Schulung von Lean-Agile Change Agents, 2) Schulung von Führungskräften, Managern und Leitern, 3) Schulung von Teams und das Aufsetzen von Agile Release Trains (ARTs).

Innovation and Planning Iteration Die Innovation and Planning Iteration erfolgt zu jedem PI und dient verschiedenen Zwecken. Sie dient als Puffer für die Erreichung von PI-Zielen und stellt Zeit für die Innovation, laufende Schulung, PI-Planung und Inspect and Adapt (I&A)-Ereignisse dar.

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

Iteration Execution Iteration Execution ist die Vorgehensweise, mit der Agile Teams ihre Arbeit innerhalb der Iteration Timebox ausführen und die für ein hochwertiges, funktionierendes und getestetes System Increment sorgt. Jede Iteration folgt einem Standardmuster: Planen der Iteration, Festlegen eines Ziels, Ausführung, Präsentation der Arbeitsergebnisse gegenüber den Stakeholdern und Abhalten einer Retrospektive.

Iteration Goals Iteration Goals sind Zusammenfassungen der geschäftlichen und technischen Ziele, die das Team und der Product Owner zur Erreichung in einer Iteration vereinbaren. Sie dienen als Kommunikationsmechanismus innerhalb des Teams und gegenüber den Stakeholdern des Teams. Sie stellen sicher, dass die PI-Ziele erreicht werden.


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

Iteration Retrospective Die Iteration Retrospective ist ein Meeting, bei dem die Teammitglieder die Ergebnisse der Iteration besprechen, ihre Methoden prüfen und versuchen, den Prozess zu verbessern.

Iterations Iterations sind eine standardmäßige Timebox fester Dauer, bei denen die Teams inkrementellen Wert in Form von Software und Systemen bereitstellen, die funktionieren und getestet sind. Die Iterationsdauer ist frei wählbar und beträgt meist zwischen einer und drei Wochen. Zwei Wochen ist die vorgeschlagene und häufigste Dauer.

Lean-Agile Budgeting Lean-Agile Budgeting ist eine Reihe von Methoden, die Value Streams ermöglichen und finanzieren, wobei die finanzielle Governance und die Gebrauchsfähigkeit durch objektive Evaluierung und dynamische Budgetanpassungen aufrechterhalten wird.

Lean-Agile Leaders Lean-Agile Leaders sind Personen, die ständig hinzulernen und für die erfolgreiche Umsetzung von SAFe und die dadurch geschaffenen Ergebnisse verantwortlich sind. Sie helfen den Teams, bessere Systeme zu erstellen, indem sie die Prinzipien und Methoden von SAFe leben, jederzeit an den Tag legen, anderen beibringen und coachen.

Lean-Agile Mindset Ein Lean-Agile Mindset kombiniert die Konzepte des Agile Manifesto und des Lean Thinking. Es dient als Grundlage für die SAFe Principles und -Methoden

Metrics Metrics sind vereinbarte Messgrößen, die verwendet werden, um zu prüfen, wie gut die Organisation SAFe annimmt und sich den geschäftlichen und technischen Zielen des Portfolios, des Value Streams, des Program und Teams annähert.

Milestones Milestones werden verwendet, um den Fortschritt hin zu einem bestimmten Ziel oder Ereignis nachzuverfolgen. Es gibt drei Arten von SAFe Milestones: terminlich feststehende Milestones, Program Increment Milestones und Milestones bezüglich des Lernens.

Model-Based Systems Engineering Model Based Systems Engineering (MBSE) ist eine Methodik, die sich auf die Entwicklung verschiedener verbundener Systemmodelle konzentriert, die zum Definieren und Designen des Systems verwendet werden. Modelle bieten eine effiziente Möglichkeit zum Erkunden, Aktualisieren und Kommunizieren von Systemaspekten gegenüber Beteiligten und reduzieren oder gar eliminieren dabei die Abhängigkeit von herkömmlichen Dokumenten.

Nonfunctional Requirements Non-functional Requirements (NFRs) definieren Systemattribute wie Sicherheit, Verlässlichkeit, Leistung, Wartungsfähigkeit, Skalierbarkeit und Nutzbarkeit. Sie dienen als Beschränkungen des Systemdesigns über die verschiedenen Backlogs hinweg.


Program Increment Planning Program Increment (PI) Planning ist ein kadenzbasierendes face-to-face Planungsereignis, das als der Herzschlag des Agile Release Train (ART) fungiert. Hierbei werden die Bemühungen aller Teams im ART auf ein gemeinsames Ziel ausgerichtet.

Portfolio Backlog Das Portfolio Backlog ist eine priorisierte Liste der Epics, die durch das Portfolio Kanban-System für die Implementierung genehmigt wurden.

Portfolio Business Epic Portfolio Business Epics sind große Geschäftsinitiativen, die oft über mehrere Value Streams und mehrere bereitzustellende Program Increments hinweg reichen.

Portfolio Kanban Das Portfolio Kanban ist eine Methode, die zum Visualisieren und Verwalten der Analyse, Priorisierung und des Ablaufs von Portfolio Epics von der Idee über die Umsetzung bis zur Fertigstellung verwendet wird.

Portfolio Level Das Portfolio Level enthält die Rollen, Artefakte und Prozesse, die zur Umsetzung der strategischen Absicht des Portfolios erforderlich sind. Es definiert die Value Streams und Finanzierung für die Menschen und andere Ressourcen, die die Solutions erstellen.

Pre- and Post-PI Planning Pre- and post-PI (Program Increment) Planning Meetings werden verwendet, um die PI Planung für mehrere Agile Release Trains (ARTs) und Suppliers in einem großen Value Stream vor- und nachzubereiten.

Product Management Product Management ist die Inhaltsautorität für das Program Level und das Backlog. Es ist verantwortlich für die Identifizierung der Bedürfnisse der Customers, für die Priorisierung von Features und die Entwicklung der Program Vision und Roadmap.

Product Owner Der Product Owner ist die Inhaltsautorität für das Team Level. Product Owner sind verantwortlich für das Team Backlog, die Priorisierung und Annahme der Stories sowie die Repräsentation des Customers gegenüber dem Agile Team.

Program Backlog Das Program Backlog ist eine priorisierte Liste der Features. Sein Zweck besteht darin, die Benutzerbedürfnisse aufzuführen und geschäftlichen Nutzen zu generieren. Es enthält auch die Enabler Features, die erforderlich sind, um den Architectural Runway zu erstellen.

Program Epics Program Epics sind Initiativen, die signifikant genug sind, um eine Analyse anhand eines leichtgewichtigen Business Case und eine finanzielle Genehmigung vor der Umsetzung zu erfordern. Deren Umfang ist auf einen einzelnen Agile Release Train (ART) beschränkt, ihre Entwicklung kann mehrere Program Increments erfordern.


Program Increment Ein Program Increment (PI) ist eine Timebox, innerhalb der ein Agile Release Train (ART) inkrementellen Wert in Form von Software und Systemen bereitstellt, die funktionieren und getestet sind. 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 Kanban Das Program Kanban ist eine Methode, die verwendet wird, um die Analyse, Priorisierung und den Ablauf von Program Epics und Features von der Idee bis zur Fertigstellung für einen einzelnen Agile Release Train (ART) zu visualisieren und zu verwalten.

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

Program Increment Objectives Program Increment (PI) Objectives sind eine integrierte Zusammenfassung der PI-Ziele aller Teams für einen Agile Release Train (ART). Sie werden verwendet, um den Plan gegenüber den Stakeholdern zu kommunizieren und die erreichten Ziele des ART für ein Program Increment zu messen.

Program Portfolio Management Program Portfolio Management (PPM) ist eine Funktion, in der Personen arbeiten, die die ultimative Entscheidungsgewalt über ein Portfolio haben. Diese Personen sind verantwortlich für die Strategie, die Finanzierung, allgemeine Programmelementeverwaltung und die Portfolio Governance.

Release Ein Release ist die private oder öffentliche Bereitstellung wertvoller, funktionierender und umfassend getesteter und validierter Solution Increments.

Release Any Time Release any time ist eine Methode, bei der der Agile Release Train (ART) die Entwicklungskadenz vom Solution Release-Zyklus abkoppelt. Innerhalb entsprechender technischer und geschäftlicher Governance können ARTs jederzeit alles Notwendige releasen.

Release Management Release Management ist eine Funktion, die den Status des Release gegenüber Stakeholdern kommuniziert, verifiziert, dass die Solution die relevanten Qualitäts- und Governance-Kriterien erfüllt und die endgültige Genehmigung für das Release gibt.

Release Train Engineer Der Release Train Engineer (RTE) ist eine dienende Führungskraft und Coach für den Agile Release Train (ART). Er kümmert sich um die Prozesse, Events und die PI-Durchführung des ART. Er oder sie eskaliert Hindernisse und hilft, Risiken zu beheben, Wert zu liefern, und bei der kontinuierlichen Verbesserung des Prozesses.

Roadmap Die Roadmap ist ein Plan für die zeitliche Abfolge von Ereignissen und Meilensteinen, die geplante Lieferungen für einen Zeitraum kommunizieren. Sie enthält Zusagen für das geplante PI und bietet Transparenz über die prognostizierten Lieferungen der anstehenden PIs.


SAFe Principles SAFe Principles definieren die neun grundlegenden Überzeugungen, fundamentalen Wahrheiten und wirtschaftlichen Gegebenheiten, die über effektive Rollen und Methoden eine erfolgreiche Umsetzung von SAFe vorantreiben.

Scrum Master Scrum Masters sind die dienenden Führungskräfte und Coaches eines Agile Teams. Sie schulen das Team in Scrum, Extreme Programming, Kanban und SAFe und stellen sicher, dass der definierte Prozess eingehalten wird. Sie helfen auch bei der Beseitigung von Hindernissen und fördern eine Umgebung für Hochleistungs-Teams, Continuous Flow und kontinuierliche Verbesserung.

ScrumXP ScrumXP ist ein leichtgewichtiger Prozess für funktionsübergreifende, selbstorganisierte Teams, die im SAFe-Kontext Werte schaffen. ScrumXP führt die Stärken von Scrum-Projektmanagement- und von Extreme Programming inspirierten technischen Methoden zusammen.

Set-Based Design Set-Based Design ist eine Methode, bei der die Anforderungen und Designoptionen über einen längeren Zeitraum hinweg flexibel gehalten werden. Statt anfangs eine einzelne „punktuelle" Lösung auszuwählen, nutzt Set-Based Design die Identifikation mehrerer Design-Optionen, um nach und nach schwache Lösungen zu verwerfen. Dies führt zu einem flexibleren Designprozess.

Shared Services Shared Services stellt spezialisierte Rollen dar, Menschen und Services, die für den Erfolg eines Agile Release Trains (ART) oder Value Streams erforderlich sind, aber nicht Vollzeit in einem bestimmten ART tätig sind (z. B. Sicherheitsexperten, Datenbankadministratoren).

Solution Eine Solution ist ein Produkt, ein Service oder ein System, das dem Customer bereitgestellt wird oder einen Value Stream innerhalb einer Organisation unterstützt.

Solution Architect/Engineering Solution Architect/Engineering sind die Personen und Teams, die die technische Verantwortung für die Gesamtarchitektur und das technische Design der Solution tragen. Sie helfen bei der Ausrichtung des Value Streams und des Agile Release Trains (ART) auf eine gemeinsame technologische und architektonische Vision.

Solution Context Der Solution Context identifiziert kritische Aspekte der Umgebung für die Solution. Er identifiziert den Einfluss der Anforderungen, Nutzung, Installation, des Betriebs und Supports der Solution selbst.

Solution Demo Bei der Solution Demo werden die Ergebnisse mehrerer Agile Release Trains (ARTs) zusammen mit Beiträgen von Lieferanten integriert, evaluiert sowie Customers und anderen Beteiligten präsentiert.


Solution Intent Der Solution Intent stellt ein Repository für die Speicherung, Verwaltung und Kommunikation von Wissen der aktuellen und geplanten Solution dar, wo notwendig auch eine Historie der Einträge.

Solution Management Das Solution Management hat die inhaltliche Verantwortung für das Value Stream Level. Sie arbeiten zusammen mit den Customers , um deren Bedürfnisse zu verstehen, die Vision und Roadmap zu erstellen und Anforderungen zu definieren. Diese Arbeit wird unterstützt durch ein Value Stream Kanban.

Spanning Palette Die Spanning Palette enthält verschiedene Rollen und Artefakte, die für jedes Level des Frameworks anwendbar sind. Sie wird genutzt, um verschiedene SAFe Elemente auf ein bestimmtes Team, Program, einen bestimmten Value Stream oder ein bestimmtes Portfolio Level anzuwenden.

Stories Stories sind kurze, in der Sprache des Benutzers formulierte, einfache Beschreibungen einer gewünschten Teil-Funktionalität. Jede Story unterstützt die inkrementelle Entwicklung, indem sie ein kleines, vertikales Stück der Systemfunktionalität implementiert.

Strategic Themes Strategic Themes sind zerlegte, differenzierte Geschäftsziele, die ein Portfolio mit der Geschäftsstrategie des Enterprise verbinden. Sie bieten den Geschäftskontext für eine Entscheidungsfindung und dienen als Input zur Vision, zum Budget und zu den Backlogs für das Portfolio, den Value Stream und die Program Levels.

Supplier Ein Supplier ist eine Organisation, die Komponenten und Subsysteme entwickelt und bereitstellt, die Value Streams dabei unterstützen, Werte für ihre Customers zu generieren.

System Architect/Engineering System Architect/Engineering stellt eine Einzelperson oder ein kleines Team dar, die/das die allgemeine technische und architektonische Vision für die in der Entwicklung befindliche Solution definiert. Diese Personen nehmen an der Festlegung des Systems, der Subsysteme und Schnittstellen teil. Sie validieren technologische Annahmen und evaluieren Alternativen.

System Demo Die System Demo findet am Ende einer jeden Iteration statt und liefert die integrierte Form neuer Features, die von allen Teams des Agile Release Trains (ART) für diese Iteration bereitgestellt wurden. Sie bietet dem ART eine objektive Fortschritts-Messung innerhalb eines Program Increments.

System Team Das System Team, ein spezielles Agile Team, unterstützt beim Erstellen und Nutzen der Agile Entwicklungs-Umgebung, insbesondere für Continous-Integration und Test-Automatisierung. Das System Team integriert Werte aus den Agile Teams, führt bei Bedarf einen End-to-End-Solution-Test durch und unterstützt bei der Bereitstellung. Deren Mitglieder kümmern sich oft um die System Demo.


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

Team Demo In der Team Demo wird am Ende jeder Iteration der Fortschritt gemessen und Feedback zu diesem eingeholt. Hierzu wird jede Story, jeder Spike, jedes Refactoring und jedes neue Non-Functional Requirement (NFR) vorgestellt, welche in der letzten Iteration entwickelt wurden.

Team Kanban Team Kanban ist eine Methode, die den Wertfluss fördert, indem sie die Work in Process (WIP) visualisiert und WIP Limits festlegt, den Durchsatz misst und den Prozess laufend verbessert.

Team Level Das Team Level enthält die Rollen, Aktivitäten und das Prozessmodell für die Teams, die den Agile Release Train (ART) antreiben.

Team PI Objectives Team PI Objectives beschreiben die geschäftlichen und technischen Ziele, die ein Agile Team beim anstehenden Program Increment (PI) erreichen möchte. Sie fassen die geschäftliche und technische Absicht zusammen und validieren diese, wodurch die Kommunikation, Ausrichtung und Sichtbarkeit verbessert werden.

User Experience User Experience Designer unterstützen eine konsistente User Experience über die Komponenten und Systeme der übergeordneten Solution hinweg, während Agile Teams die Verantwortung für die Implementierung der Solution tragen, einschließlich der benutzerbezogenen Elemente.

Value Stream Backlog Der Value Stream Backlog ist das Repository für alle anstehenden Capabilities und Enablers, von denen sich jede(r) über mehrere Agile Release Trains (ARTs) hinweg erstrecken kann. Diese werden verwendet, um die Solution voranzubringen und den Architectural Runway zu erstellen.

Value Stream Coordination Value Stream Coordination bietet Anleitung für das Behandeln von Abhängigkeiten über Value Streams in einem Portfolio hinweg.

Value Stream Engineer Der Value Stream Engineer (VSE) ist eine dienende Führungskraft und Coach für einen Value Stream. VSEs fördern Value Stream-Prozesse, -Ereignisse und -Ausführung und treiben kontinuierliche Verbesserung voran.

Value Stream Epics Value Stream Epics sind signifikante Initiativen, die eine leichtgewichtige Business-Analyse nutzen, um eine finanzielle Genehmigung vor der Umsetzung sicherzustellen. Deren Umfang ist auf einen einzelnen Value Stream beschränkt, ihre Entwicklung kann mehrere Program Increments (PIs) dauern.


Value Stream Kanban Der Value Stream Kanban ist eine Methode, die von der Idee bis zur Fertigstellung die Analyse, Priorisierung und Flussoptimierung der Value Stream Epics und Capabilities unterstützt.

Value Stream Level Das Value Stream Level bietet die Rollen, Verantwortlichkeiten und Aktivitäten, die notwendig sind, um die Erstellung großer und komplexer Solutions zu unterstützen. Diese erfordern normalerweise mehrere Agile Release Trains (ARTs) sowie die Beiträge von Suppliers. Dieses optionale Level wird von Organisationen verwendet, die sich den größten Systemherausforderungen ausgesetzt sehen, welche multidisziplinäre Software- und Systemfachleute erfordern.

Value Stream PI Objectives Value Stream PI Objectives sind geschäftliche und technische Ziele, die von Value Stream-Beteiligten für ein Program Increment (PI) identifiziert wurden. Sie kommunizieren gegenüber Beteiligten, was der Value Stream im anstehenden PI liefern will. Sie werden für große Value Streams mit mehreren Agile Release Trains (ARTs) oder Suppliers verwendet.

Value Streams Value Streams repräsentieren eine Reihe von Schritten, für eine Organisation, um Solutions zu erstellen. Sie erzeugen einen kontinuierlichen Wertfluss für den Customer. Value Streams sind das wesentliche Mittel zum Verständnis geschäftlicher Ziele, sie organisieren Teams und Agile Release Trains (ARTs) und liefern die geschäftlichen Werte. Sie werden durch einen ART realisiert.

Vision Die Vision ist eine Beschreibung oder eine zukünftige Ansicht der zu entwickelnden Solution. Sie gibt die Bedürfnisse des Customers und der Beteiligten wieder, außerdem die vorgeschlagenen Features und Capabilities. Die Vision bietet einen übergeordneten Kontext zur Übersicht und zum Zweck der zu entwickelnden Solution.

Weighted Shortest Job First Weighted Shortest Job First (WSJF) ist ein Priorisierungsmodell, das verwendet wird, um Backlog Items wie Features, Capabilities und Epics zu sortieren, um einen maximalen wirtschaftlichen Nutzen in einem Flow-optimierten System zu gewinnen. WSJF berechnet sich als Quotient aus Cost of Delay CoD und Jobsize.

Übersetzungsqualität des SAFe-Glossars Wir haben sorgfältig an der genauen und korrekten Übersetzung dieses Glossars gearbeitet. Jedoch ist keine Übersetzung perfekt! Wenn Sie Verbesserungen der Glossardefinitionen vorschlagen möchten, bitte senden Sie Ihre Vorschläge an: [email protected]


Erläuterungen zu Akronymen und Abkürzungen

ART Agile Release Train Agile Release Train

BO Business Owner Geschäftsverantwortlicher

BV Business Value Business Value

BVIR Big Visual Information Radiator Big Visual Information Radiator

CFD Cumulative Flow Diagram Cumulative Flow Diagram

CapEx Capital Expenses Capital Expenses

CI Continuous Integration Kontinuierliche Integration

CoD Cost of Delay Cost of Delay

CoP Community of Practice Community of Practice

DoD Definition of Done Definition of Done

DSU Daily Stand-up Daily Stand-up

EA Enterprise Architect Enterprise Architect

EO Epic Owner Epic Owner

FW Firmware Firmware

HW Hardware Hardware

I&A Inspect and Adapt Inspect und Adaption (I&A)

IP Innovation and Planning (Iteration) Innovation und Planung (Iteration)

MBSE Model-Based Systems Engineering Model-Based Systems Engineering

NFR Non-functional Requirements Nichtfunktionale Anforderungen

OE Opportunity Enablement Opportunity Enablement

OpEx Operating Expenses Betriebsausgaben

PDCA Plan, Do, Check, Adjust Plan, Do, Check, Adjust

PI Program Increment Programminkrement

PM Product Manager Product Manager

PM/PO Product Manager / Product Owner Product Manager / Product Owner

PO Product Owner Product Owner

PPM Program Portfolio Management Programm-Portfoliomanagement

ROAM Resolved, Owned, Accepted, Mitigated Resolved, Owned, Accepted, Mitigated

RR Risk Reduction Risk Reduction


RTE Release Train Engineer Release Train Engineer

S4T SAFe® for Teams SAFe® for Teams

SAFe® Scaled Agile Framework Scaled Agile Framework

SA SAFe® Agilist SAFe® Agilist

SM Scrum Master Scrum Master

SMART Specific, Measurable, Achievable, Specific, Measurable, Achievable, Realistic, Time-bound Realistic, Time-bound

SoS Scrum of Scrums Scrum of Scrums

SP SAFe® Practitioner SAFe® Practitioner

SPC SAFe® Program Consultant SAFe® Program Consultant

SW Software Software

UX User Experience Benutzererfahrung

VS Value Stream Wertstrom

VSE Value Stream Engineer Value Stream Engineer

WIP Work in Progress Work in Progress

WSJF Weighted Shortest Job First Weighted Shortest Job First

XP Extreme Programming Extreme Programming


SAFe®-Zertifizierungen Es gibt eine Zertifizierung für jeden im SAFe Learning Path

SAFe® 4 Certified Program Consultant Ein SAFe® 4 Certified Program Consultant (SPC4) ist als SAFe Profi für die Schulung von Führungskräften, Change Agents, Beratern und Team-Mitgliedern verantwortlich, um eine Lean-Agile Transformation auf Unternehmens-Ebene voranzubringen. Wichtige Kompetenzbereiche sind die SAFe Implementierung, der Start und die Förderung eines Agile Release Train (ART) und der Ausbau des Lean-Agile Portfolios durch den Aufbau weiterer ARTs.

SAFe® 4 Certified Agilist Ein SAFe® 4 Certified Agilist (SA) ist eine SAFe Führungskraft des Unternehmens, die Teil einer Lean-Agile Transformation ist. Schlüssel-Bereiche seiner Kompetenz sind die Anwendung der Lean-Agile-Prinzipien und die aktive Schaffung von Wert über Agile Release Trains (ARTs) und der Aufbau eines Agile Portfolio mit Lean-Agile Budgeting.

SAFe® 4 Certified Release Train Engineer Ein SAFe® 4 Certified Release Train Engineer (RTE) ist ein SAFe dienender Programm-Leiter und Coach, der dafür verantwortlich ist, die End-to-End Bereitstellung von Nutzen in einzelnen Programmen oder einem Lean-Agile Enterprise voranzutreiben. Wichtige Kompetenzbereiche sind das Program Increment-Planning, das Führen durch ein Program Increment und das Beraten von Teams bei der kontinuierlichen Verbesserung bei der Bereitstellung von Nutzen.

SAFe® 4 Certified Product Owner/Product Manager Ein SAFe® 4 Certified Product Owner/Product Manager (POPM) ist ein SAFe Product Owner oder ein Produktmanager, der mit den Customers und Entwicklungsorganisationen zusammenarbeitet, um die Anforderungen zu identifizieren, zu verfeinern und zu kommunizieren. Wichtige Kompetenzbereiche sind das Identifizieren von Bedürfnissen der Customers, das Beschreiben von Epics, Capabilities, Features und Stories und die Priorisierung der Anforderungen.

SAFe® 4 Certified Scrum Master Ein SAFe® 4 Certified Scrum Master (SSM) ist ein SAFe Scrum Master, der Scrum-Methoden in eine Organisation integriert. Kern-Kompetenzen sind die Anwendung von Scrum und Kanban zur Förderung von Team Meetings, die Unterstützung der Programmausführung und das Coaching von Agile Teams.

SAFe® 4 Certified Advanced Scrum Master Ein SAFe® 4 Certified Advanced Scrum Master (SASM) ist ein SAFe Scrum Master mit langjähriger Erfahrung, der für die Verbesserung der Team-Ergebnisse verantwortlich ist. Wichtige Kompetenzbereiche sind die Identifizierung und Lösung von Team Anti Patterns, die Verbesserung des Wertflusses mithilfe von Kanban und technischen Methoden, die Unterstützung der Ausführung auf Programmebene und die Anwendung von Problemlösungstechniken, um eine laufende Verbesserung voranzutreiben.


SAFe® 4 Certified Practitioner Ein SAFe® 4 Certified Practitioner (SP) ist ein SAFe Teammitglied, das für die Anwendung von Scrum, Kanban und XP in einer SAFe Umgebung verantwortlich ist. Wichtige Verantwortungsbereiche sind die Planung von Program Increments und Iterations, das Herunterbrechen von Anforderungen auf Stories, die inkrementelle Entwicklung, Berücksichtigung von Built-in Quality, das Sichtbarmachen von Wert durch Demos auf Team- und Program Level und das Eliminieren von Hindernissen, um eine kontinuierliche Verbesserung voranzutreiben.

Finden Sie heraus, welcher SAFe Schulungs- und Zertifizierungspfad der Richtige für Sie ist. Informationen dazu finden Sie unter:

www.scaledagile.com/which-course


SAFe® SCHULUNGEN IN IHRER NÄHE FINDEN

„Es fühlt sich so an, als haben wir in nur 2 Wochen eine 156 Jahre alte Barriere durchbrochen. Danke für die Unterstützung.“

– Senior Level Architect eines Fortune Global 500-Unternehmens

Schulungen stehen im Mittelpunkt des Kundenerfolgs.

Unsere beliebten Schulungen werden von Scaled Agile und unserem Global Partner Network in 35 Ländern an 350 Orten weltweit angeboten. Alle konzentrieren sich darauf, Unternehmen in die Lage zu versetzen, das

Optimum aus der Anpassung von SAFe herauszuholen.

Finden Sie eine SAFe Schulung in Ihrer Nähe: www.scaledagile.com/calendar


Mehr Infos Wenn Sie mehr über SAFe erfahren möchten, besuchen Sie diese Websites.

SAFe Fallstudien: www.scaledagileframework.com/case-studies

Scaled Agile Framework: www.scaledagileframework.com

Einführung in SAFe www.scaledagileframework.com/introduction-to-safe

Rollenbasierte SAFe-Schulung und -Zertifizierung: www.scaledagile.com

SAFe-Präsentationen und -Videos: www.scaledagileframework.com/videos-and-presentations

Bücher über SAFe: www.scaledagileframework.com/books

Über Scaled Agile, Inc. Die Mission von Scaled Agile mit Stammsitz in Boulder, Colorado, USA, besteht darin, aufbauend auf dem Scaled Agile Framework ®(SAFe®) großen Unternehmen zu helfen, bessere Ergebnisse zu erzielen, das Mitarbeiter-Engagement zu stärken und die Wirtschaftlichkeit durch Anwendung von Lean-Agile Prinzipien und Methoden zu verbessern.

Scaled Agile unterstützt tausende Fachleute durch Schulungen, Zertifizierungen, Beratungsdienste und ein globales Partnernetzwerk in 35 Ländern an 350 Orten. Als Mitglied der 1 % Versprechen Philanthropie-Bewegung leistet Scaled Agile seinen Beitrag zur Gemeinde vor Ort und strebt an, andere Unternehmen davon zu überzeugen, Gleiches zu tun.

Kontakt: Scaled Agile, Inc. 5480 Valmont Rd, Suite 100 Boulder CO 80301 USA +1.303.554.4367 [email protected] www.scaledagile.com

Documents

SAFe 4.0 – Glossar - Scaled agile framework€¦ · Lean-Agile Leaders Lean-Agile Leaders sind Personen, die ständig hinzulernen und für die erfolgreiche Umsetzung von SAFe und