SAFe-Lexikon: Alle wichtigen Begriffe aus der SAFe-Welt, übersetzt und erklärt
Das SAFe-Glossar ist eine Sammlung von Definitionen für alle Elemente im SAFe Big Picture. Zusätzlich finden Sie in unserem Lexikon auch Erklärungen für gängige Begriffe, die im Framework verwendet werden. Einige sind einzigartig für SAFe (z. B. PO Sync), während andere allgemein in der Lean-Agile-Entwicklung üblich sind (z. B. MVP). Wir führen sie hier mit auf, um ihre Bedeutung im Kontext von SAFe zu verdeutlichen.
A
Acceptance Criteria (Akzeptanzkriterien)
Akzeptanzkriterien liefern die Informationen, die erforderlich sind, um sicherzustellen, dass eine Story, ein Feature oder eine Capability korrekt implementiert ist und die relevanten Funktionen und NFRs abdeckt.
Acceptance Test Driven Development (Akzeptanztestgetriebene Entwicklung)
Akzeptanztestgetriebene Entwicklung ist eine testorientierte, agile Testpraktik, die mit verhaltensgetriebener Entwicklung (BDD) gleichzusetzen ist.
Agile (Agil)
Agil definiert eine Reihe von Werten, Prinzipien und Praktiken für die iterative Entwicklung, die vor allem durch das Agile Manifest beschrieben werden.
Agile Manifesto (Agiles Manifest)
Das Agile Manifest ist das wegweisende Dokument, das die vier Werte und zwölf Prinzipien der Agilen Softwareentwicklung beschreibt.
Agile Product Delivery
Die Kernkompetenz “Agile Product Delivery” ist ein kundenorientierter Ansatz zum Definieren, Erstellen und Veröffentlichen einer kontinuierlichen Wertschöpfung wertvoller Produkte und Dienstleistungen für Kunden:innen und Benutzer:innen.
Agile Program Management Office ⇾ Value Management Office
Agile Release Train (ART)
Ein Agile Release Train (ART) ist ein auf längere Zeit ausgelegtes Team aus mehreren agilen Teams (Agile Teams), das im Zusammenspiel untereinander und mit anderen Stakeholdern eine oder mehrere Lösungen inkrementell (schrittweise erfolgend, aufeinander aufbauend) entwickelt, liefert und wenn möglich betreibt. Ein ART agiert innerhalb eines Wertstroms.
Agile Teams
Im Rahmen des Scaled Agile Frameworks (SAFe) ist ein Agile Team eine crossfunktionale Gruppe von 5-11 Personen, die in kurzen Zeitintervallen (Iterationen) kontinuierlich und aufeinander aufbauend Mehrwerte definiert, erstellt, testet und ausliefert.
Architect Sync (Architekten-Sync)
Der Architekten-Sync ist eine Veranstaltung des Solution Trains, um sicherzustellen, dass neue Entwürfe und Kompromisse innerhalb des Solution Trains einheitlich gehandhabt werden, sodass die Möglichkeit besteht, Implementierungsansätze zu steuern, ohne dass es zu Verzögerungen kommt.
ART Backlog, früher: Program Backlog
Das ART Backlog ist der Ort für anstehende Features, die Benutzerbedürfnisse adressieren und Geschäftsnutzen durch einen einzelnen Agile Release Train (ART) liefern sollen. Es enthält auch die Enabler-Features, die für den Aufbau der Architectural Runway des betreffenden ART erforderlich sind.
ART Kanban, früher: Program Kanban
ART Kanbans dienen zur Visualisierung und Verwaltung von Features respektive Capabilities von der Idee über die Analyse, die Implementierung bis zum Release durch die Continuous Delivery Pipeline.
ART PI Risks, früher: Program Risiks
ART-PI-Risiken werden von den Teams während der PI Planung identifiziert und stellen Risiken und Hindernisse dar, die die Zielerreichung, beeinträchtigen könnten.
ART Planning Board, früher: Program Board
Das ART Planning Board zeigt die Feature-Liefertermine des PI, Feature-Abhängigkeiten zwischen den Teams und relevante Meilensteine.
ART Predictability Measure, früher: Program Predictability Measure
Die Programmvorhersagbarkeitskennzahl fasst die geplanten gegenüber den tatsächlichen Geschäftswerten für alle Teams des ART zusammen und ist ein wichtiger Indikator für die Leistung und Zuverlässigkeit des ART.
ART Sync
Der ART Sync ist ein Event des Agile Release Trains, das den Product Owner Sync mit dem Scrum of Scrums (SoS) kombiniert.
B
Backlog Refinement
Das Backlog Refinement ist eine Aktivität, die ein- oder zweimal während der Iteration oder des Inkrements stattfindet, um die anstehenden Stories im Team Backlog zu diskutieren, zu schätzen und ein grundlegendes Verständnis für ihre Akzeptanzkriterien zu schaffen.
Baseline Solution Investments, BSIs
Baseline Solution Investments (BSIs) sind die Kosten, die durch Entwicklung, Support und Betrieb der Lösungen für die Ermöglichung der aktuellen Geschäftsfähigkeit durch jeden Wertstrom entstehen.
Batch Size (Chargengröße)
Die Größe des Arbeitsvorrats (Chargengröße) ist ein Maß dafür, wie viel Arbeit (Anforderungen, Entwürfe, Code, Tests und andere Arbeitselemente) in einem bestimmten Zeitfenster vom System bearbeitet wird.
Behavior-Driven Development, BDD (Verhaltensgetriebene Entwicklung)
Die verhaltensgetriebene Entwicklung (Behavior-Driven Development, BDD) ist eine agile Praxis, die durch die Definition (und möglicherweise Automatisierung) von Tests vor oder als Teil der Spezifikation des Systemverhaltens für eine hohe Qualität sorgt.
Benefit Hypothesis (Nutzenhypothese)
Die Nutzenhypothese ist der erwartete messbare Nutzen für den Endbenutzer oder das Unternehmen als Teil eines Features oder Capability.
Big Visible Information Radiator, BVIR
Ein Big Visible Information Radiator (BVIR) ist eine grafische Anzeige, die essentielle Daten auf einen Blick erfasst und kommuniziert (z. B. Burndown-Charts, Programmboard, Build-Status-Tafeln).
Built-In Quality (Integrierte Qualität)
Integrierte Qualitätspraktiken stellen sicher, dass jedes Element der Solution über die gesamte Entwicklung hinweg bei jedem Inkrement (Zuwachs) den angestrebten Qualitätsstandards entspricht.
Burn-down (Burn-up) Chart
Burn-Down- und Burn-Up-Charts sind grafische Darstellungen, die den Arbeitsfortschritt in Abhängigkeit zum zeitlichen Fortschritt zeigen.
Business Agility (Geschäftliche Agilität)
Geschäftliche Agilität beschreibt die Fähigkeit, im digitalen Zeitalter wettbewerbsfähig zu sein und sich mit Hilfe innovativer, digitaler Geschäftslösungen erfolgreich weiterzuentwickeln, indem schnell auf Veränderungen und entstehende Möglichkeiten am Markt reagiert kann.
Business and Technology (Geschäft und Technologie)
Geschäft und Technologie in SAFe beschreibt, wie funktionale Bereiche in allen Teilen des Unternehmens geschäftliche Agilität (Business Agility) ermöglichen, indem sie kontinuierlich neue Wege erforschen, um Lean-Agile-Prinzipien und -Praktiken in ihrem eigenen Kontext anzuwenden.
Business Context (geschäftlicher Kontext)
Der geschäftliche Kontext ist ein Agendapunkt der PI Planung, der durch die Business Owner präsentiert wird. Hierzu wird der aktuelle Zustand des Unternehmens beschrieben, die Portfolio-Vision dargestellt und Informationen bereitgestellt, wie effektiv derzeitige Produkte existierende Kundenbedürfnisse adressieren.
Business Owner
Business Owner sind eine kleine Gruppe von Stakeholdern. Sie haben die geschäftliche und technische Hauptverantwortung für Governance, Compliance und Return on Investment (ROI) für eine von einem Agile Release Train (ART) entwickelte Solution. Sie sind wichtige Stakeholder im ART, die die Nutzbarkeit bewerten und aktiv an bestimmten ART-Events teilnehmen müssen.
C
CALMR
Der CALMR-Ansatz für DevOps ist ein Mindset, das Agile Release Trains zum Erreichen einer kontinuierlichen Wertschöpfung anleitet, indem sie gleichzeitig Fortschritte in der Lieferkultur, der Automatisierung, dem Lean Ablauf, der Messung und der Wiederherstellung berücksichtigen und koordinieren. CALMR = Culture, Automation, Lean, Measurement, Recovery
Capabilities
Eine Capability beschreibt eine fachliche Anforderung auf Solution-Ebene, die typischerweise mehrere ARTs betrifft. Capabilities werden innerhalb eines Programminkrements (PI) umgesetzt und dafür in mehrere Features heruntergebrochen.
Capacity Allocation (Zuordnung von Kapazitäten)
Die Zuordnung von Kapazitäten ist eine Leitplanke aus der Budgetierung nach Lean. Sie hilft dabei das Backlog in Bezug auf neue Features, Enablern und technischer Schuld auszubalancieren und Kapazitäten für das kommende Programminkrement (PI) zu allokieren (dafür bereitzustellen).
Coach Sync, früher: Scrum of Scrums
Das Coach Sync ist ein Event innerhalb eines ARTs. Es unterstützt den ART dabei, Abhängigkeiten zu koordinieren und Transparenz über Fortschritte und Hindernisse zu schaffen.
Committed PI Objectives (verpflichtende PI-Ziele)
Die verpflichtenden PI-Ziele sind eine Reihe von SMART-formulierten Zielen, die von jedem Team erstellt werden, wobei derGeschäftswert von den Business Ownern zugewiesen wird.
Communities of Practice (CoP)
Communities of Practice (CoP) sind selbstorganisierte Gruppen, die ein gemeinsames Interesse an einer bestimmten technischen oder geschäftlichen Domäne teilen. Sie arbeiten regelmäßig zusammen, um Informationen auszutauschen, ihre Kompetenzen zu verbessern und aktiv das grundlegende Domänenwissen weiterzuentwickeln.
Compliance
Compliance bezeichnet eine Herangehensweise und Sammlung von Aktivitäten, Artefakten und Normen, um die Einhaltung von regulatorischen, branchenspezifischen oder anderen relevanten Standards zu gewährleisten. Diese ermöglichen den Teams hochwertige Systeme in der Anwendung von Lean-Agile Entwicklungsmethoden zu bauen.
Confidence Vote (Zutrauensabstimmung)
Die Zutrauensabstimmung findet gegen Ende der PI-Planung statt, bei der die Teams über ihr Vertrauen in die Erfüllung der PI-Ziele abstimmen.
Continuous Delivery Pipeline
Die Continuous Delivery Pipeline (CDP) bildet die Workflows, Aktivitäten und Automatisierungen ab, die erforderlich sind, um eine neue Funktionalität von der Idee bis zum Release on Demand an den Endbenutzer zu ermöglichen.
Continuous Deployment (CD)
Continuous Deployment (CD) ist der Prozess, der validierte Features von einer Staging-Umgebung in die Produktionsumgebung überführt, um sie für den Release on Demand vorzubereiten.
Continuous Exploration (CE)
Die ständige Sondierung (Continuous Exploration) des Markts und der Kundenbedürfnisse ist Treiber für Innovationen und unterstützt die gemeinsame Ausrichtung zu dem “Was” als Lösung verfolgt und gebaut werden sollte. Diese Bedürfnisse werden in eine Vision, Roadmap und einem Set an Features einer Solution überführt, um sie weiterführend adressieren zu können.
Continuous Integration (CI)
Continuous Integration (CI) ist der Prozess, bei dem Funktionen aus dem Programm-Backlog entnommen und in einer Staging-Umgebung entwickelt, getestet, integriert und validiert werden, sodass sie für den produktiven Einsatz und Release on Demand bereit sind.
Continuous Learning Culture
Die Kernkompetenz “Continuous Learning Culture” beschreibt eine Reihe von Werten und Praktiken, die sowohl jede:n Einzelne:n, als auch das gesamte Unternehmen dazu ermutigen, Wissen, Kompetenzen, Leistung und Innovation kontinuierlich zu verbessern.
Core Values (Grundwerte)
Die vier Grundwerte Alignment, Built-in Quality, Transparency und Program Execution beschreiben die grundlegenden Wertvorstellungen, die für die Effektivität von SAFe entscheidend sind. Sie bestimmen das Handeln aller, die Teil einer SAFe-Implementierung sind.
Cost of Delay, CoD (Verzögerungskosten)
Die Verzögerungskosten stellen den Geldbetrag oder den Wert dar, der durch die Verzögerung oder den Verzicht auf die Ausführung einer Aufgabe verloren geht, und werden bei der WSJF-Priorisierung verwendet.
Customer (Kund:innen)
Kunden:innen sind die Leistungsempfänger:innen (des Mehrwerts) und somit Nutzer:innen der durch die verschiedenen Wertströme des Unternehmens generierten Business-Lösungen.
Customer Centricity (Kund:innenzentrierung)
Kund:innenzentrierung ist ein Mindset und beschreibt, wie man (geschäftliche) Vorhaben kundenzentriert gestaltet. Hierzu ist es nötig, den Fokus darauf zu setzen, für Kunden:innen positive Erfahrungen durch ein vollständiges Angebot von Produkten und Dienstleistungen des jeweiligen Unternehmens zu erzeugen.
Customer Journey Map (Visualisierung der Kundenerfahrung)
Eine Customer Journey Map veranschaulicht die Erfahrungen, die ein Anwender bei der Auseinandersetzung mit dem betrieblichen Wertstrom, den Produkten und Dienstleistungen eines Unternehmens macht.
D
Daily Stand-up, jetzt: ⇾ Team Sync
Das Daily Stand Up (DSU) ist ein tägliches Teamereignis, bei dem jedes Teammitglied beschreibt, was es gestern getan hat, um die Iterationsziele voranzubringen, woran es heute arbeiten wird, um die Iterationsziele zu erreichen, und welchen Blockaden es beim Erreichen der Iterationsziele begegnet ist.
Decentralized Decision-Making (dezentrales Entscheiden)
Dezentrales Entscheiden überträgt die Entscheidungsbefugnis an diejenigen, die am nächsten am Wissen und an den Informationen sind, um Verzögerungen zu reduzieren, den Produktentwicklungsfluss zu erhöhen und die Qualität der Entscheidungen zu verbessern.
Definition of Done
Die Definition of Done kommuniziert die Vollständigkeit eines Wertzuwachses und schafft ein gemeinsames Verständnis darüber, welche Arbeit als Teil eines Inkrements (Zuwachses) abgeschlossen wurde.
Design Thinking
Design Thinking ist ein kund:innenzentrierter Prozess zur Gestaltung von wünschenswerten Produkten, die über ihren Lebenszyklus gewinnbringend und nachhaltig zukunftsfähig sind.
Develop on Cadence (Entwicklung im Takt)
Entwicklung im Takt ist eine aufeinander abgestimmte Sammlung von Praktiken, die Agile Teams unterstützen, indem sie eine verlässliche Abfolge von Ereignissen und Aktivitäten bereitstellen, die in einem regelmäßigen, vorhersehbaren Zeitplan auftreten.
Development Value Streams (Entwicklungswertströme)
Entwicklungswertströme sind die Abfolge von Aktivitäten, die erforderlich sind, um eine Geschäftshypothese in eine Solution umzuwandeln. Beispiele sind das Design eines medizinischen Geräts oder eines geophysikalischen Satelliten oder die Entwicklung und Bereitstellung einer Softwareanwendung, wie beispielsweise eines SaaS-Systems oder einer E-Commerce-Website.
DevOps
DevOps (Development & Operations) beschreibt ein Mindset, eine Kultur und eine Sammlung von Vorgehensweisen und Technologien. DevOps sorgt für Kommunikation, Integration, Automatisierung und enge Zusammenarbeit zwischen allen an der Lösung beteiligten Menschen, die benötigt werden, um eine Lösung zu planen, entwickeln, prüfen, ausliefern und betreiben zu können.
E
Empathy Map (Empathiekarte)
Eine Empathiekarte ist ein Design-Thinking-Werkzeug, das Teams hilft, ein tiefes, gemeinsames Verständnis für ihre Kunden zu entwickeln.
Enablers
Ein Enabler unterstützt die Aktivitäten, die für die Erweiterung der Architectural Runway erforderlich sind, um Funktionen und Features bereitzustellen. Hierzu gehören Exploration (Sondierung), Architektur, Infrastruktur und Compliance. Enabler werden in verschiedenen Backlogs erfasst und kommen im gesamten Framework vor.
Enterprise (Unternehmen)
Das Unternehmen repräsentiert die Geschäftseinheit zu der das jeweilige SAFe-Portfolio zuzuordnen ist.
Enterprise Architect
Ein:e Enterprise Architect etabliert die technische Strategie und Roadmap, die das Portfolio befähigt, aktuelle und geplante Geschäftslösungen zu unterstützen. Dies geschieht über den Architectural Runway.
Enterprise Solution Delivery
Die Kernkompetenz “Enterprise Solution Delivery” beschreibt, wie Lean-Agile-Prinzipien und Handlungsweisen auf Spezifikation, Entwicklung, Bereitstellung und Betrieb von großen und anspruchsvollen Softwareanwendungen, Netzwerken und cyber-physikalischen Systemen angewendet werden.
Epic
Ein Epic ist ein Container für wesentliche Investitionen innerhalb eines Portfolios für die Entwicklung einer bedeutsamen Solution. Aufgrund des erheblichen Umfangs und ihrer Auswirkungen erfordern Epics die Definition eines Minimum Viable Product (MVP) und die Abstimmung und Genehmigung durch das Lean Portfolio Management (LPM) vor der Implementierung.
Epic Hypothesis Statement (Epic-Hypothese)
Die Epic-Hypothese erfasst, organisiert und kommuniziert wichtige Informationen über ein Epic.
Epic Owner
Epic Owner sind für die Koordination von Portfolio-Epics durch das Portfolio-Kanban-System verantwortlich. Sie definieren das Epic, dessen Minimum Viable Product (MVP) und den Lean-Business-Case. Wenn das Epic genehmigt ist, unterstützen sie die Implementierung.
Essential SAFe
Essential SAFe beinhaltet das minimale Set von Rollen, Events und Artefakten, die benötigt werden, um mit einem Agile Release Train (ART) als Team agiler Teams kontinuierlich Kundenlösungen zu entwickeln.
Estimation Poker (Schätzpoker)
Schätzpoker ist eine kollaborative Technik zur relativen Schätzung der Größe von Stories, Features und WSJF in SAFe.
Extreme Programming, XP
Extreme Programming (XP) ist ein Set von agilen Software-Engineering-Praktiken, die die Softwarequalität und die Reaktionsfähigkeit auf sich ändernde Kundenanforderungen verbessern und hauptsächlich von Kent Beck entwickelt wurden.
F
Features
Ein Feature beschreibt einen Service, der einen Bedarf eines Stakeholders erfüllt. Jedes Feature enthält eine Nutzenhypothese und Akzeptanzkriterien. Jedes Feature ist so dimensioniert oder aufgeteilt, dass es von einem einzelnen Agile Release Train (ART) in einem Programminkrement (PI) geliefert werden kann.
Final Plan Review (Finale Planüberprüfung)
In der Aktivität der "finalen Planüberprüfung" der PI Planung präsentieren die Teams die endgültigen Pläne (PI Ziele, Last, Risiken) zur Kommunikation an den ART und zur Abnahme durch die Business Owner.
Foundation
Die Foundation enthält die unterstützenden Prinzipien, Werte, Mindset sowie die Implementation Roadmap und Lean-Agile Leadership, die für die erfolgreiche Bereitstellung von Kundennutzen erforderlich sind.
Full SAFe
Full SAFe ist die umfassendste Konfiguration, die alle sieben Kernkompetenzen beinhaltet, um Business Agility zu erreichen.
G
Gemba
Gemba ist der Ort, an dem die Arbeit ausgeführt wird. Hier können die Stakeholder beobachten, wie die Teams ihre spezifischen Aktivitäten in ihren betrieblichen Wertströmen ausführen. Es bietet eine Möglichkeit, Ansatzpunkte für unaufhörliche Verbesserung besser und schneller zu erkennen.
H
Hackathon
Hackathons sind Innovationsveranstaltungen, bei denen Teammitglieder frei wählen können, woran sie und mit wem sie daran arbeiten wollen. Voraussetzung ist, dass die Arbeit die Mission des Unternehmens widerspiegelt und, dass die gemachte Arbeit am Ende des Hackathon vorgeführt wird.
I
Innovation and Planning Iteration (Innovations- und Planungsiteration)
Die Innovations- und Planungsiteration (IP-Iteration) ist die letzte Iteration eines jeden Programminkrement (PI). Sie dient als Puffer für die Erreichung von PI-Zielen, stellt Zeit für Innovation und Weiterbildung zur Verfügung, wie auch für das PI-Planung und das Inspect & Adapt (I&A)-Event.
Inspect & Adapt, I&A (Inspizieren & Anpassen)
Inspizieren & Anpassen (I&A) ist ein wichtiges Event, das am Ende jedes Programminkrements (PI) stattfindet und bei dem der aktuelle Stand der entwickelten Solution gezeigt und vom Train evaluiert wird. Die Teams reflektieren ihre Arbeit und identifizieren in einem Problemlösungs-Workshop Backlog-Eintrage für mögliche Verbesserungen.
Integration Point (Integrationspunkt)
Ein Integrationspunkt schafft ein "Pull-Ereignis", das die verschiedenen Lösungselemente zu einem integrierten Ganzen zusammenführt. Die Betrachtung des integrierten Ganzen hilft den Stakeholdern dabei sicherzustellen, dass die sich entwickelnde Lösung den tatsächlichen und zukünftigen Geschäftsanforderungen entspricht.
Investment Horizons (Investmenthorizonte)
Investmenthorizonte zeigen die Ausgabenzuweisungen für Lösungen an, die von den Wertströmen geliefert werden. Dies hilft den Wertstrom- und Budgetverantwortlichen, fundiertere Investmententscheidungen zu treffen. Außerdem richten die Investmenthorizonte das Portfolio an Strategic Themes aus.
Iteration
Iterationen sind die wesentlichen Zeitabschnitte (Time-Boxes) in der agilen Entwicklung. Jede Iteration ist ein fester Zeitabschnitt, in dem die Agilen Teams inkrementell Kundennutzen in Form von funktionierenden und getesteten Produkten und Systemen bereitstellen. Die empfohlene Dauer einer Iteration ist zwei Wochen. Je nach Geschäftskontext sind jedoch bis zu vier Wochen akzeptabel.
Iteration Execution (Iterationsdurchführung)
Die Iterationsdurchführung beschreibt, wie Agile Teams ihre Arbeit innerhalb einer Iteration steuern. Damit sorgen sie für ein hochwertiges, funktionierendes und getestetes Systeminkrements.
Iteration Goals (Iterationsziele)
Die Iterationsziele sind eine Zusammenfassung der geschäftlichen und technischen Ziele, die das Agile Team in einer Iteration erreichen möchte. Sie sind entscheidend für die Koordination eines Agile Release Trains (ART) als selbstorganisierendes, selbstverwaltendes Team von Agile Teams.
Iteration Planning (Iterationsplanung)
Die Iterationsplanung ist eine Veranstaltung, bei der alle Teammitglieder bestimmen, wie viel des Team-Backlogs sie während einer bevorstehenden Iteration liefern können. Das Team fasst die Arbeit als eine Reihe von verpflichtenden Iterationszielen zusammen.
Iteration Retrospective (Iterationsretrospektive)
Die Iterationsretrospektive ist ein regelmäßiges Ereignis, bei dem Mitglieder des Agile Teams die Ergebnisse der Iteration diskutieren, ihre angewendeten Praktiken überprüfen und Verbesserungsmöglichkeiten ermitteln.
Iteration Review (Iterationsüberprüfung)
Die Iterationsüberprüfung ist ein regelmäßiges Meeting, bei dem jedes Team das Inkrement am Ende einer jeden Iteration überprüft, um Entwicklungsfortschritte zu bewerten und abschließend das Team-Backlog für die nächste Iteration anzupassen.
K
Knowledge Worker (Wissensarbeiter:innen)
Wissensarbeiter:innen sind Personen, die über die notwendigen Fähigkeiten und Kenntnisse verfügen, um komplexe Probleme in ihrem Fachgebiet zu lösen.
L
Large Solution SAFe
Large Solution SAFe umfasst zusätzliche Rollen, Praktiken und Leitplanken zum Aufbau und zur Weiterentwicklung komplexer Anwendungen, Netzwerke und cyberphysischer Systeme.
Lead Time (Vorlaufzeit)
Die Lead Time ist die Zeit, die von der Erledigung einer Arbeit des vorherigen Schrittes bis zur Erledigung im aktuellen Schritt vergeht.
Lean
Lean ist ein Wissensfundus und ein Set von Praktiken zur Verbesserung von Effizienz und Effektivität durch die Verringerung von Verzögerungen und die Eliminierung nicht wertschöpfender Aktivitäten.
Lean Budget Guardrails (Leitplanken)
Leitplanken beschreiben die Richtlinien und Praktiken für Budgetierung, Ausgaben und Steuerung für ein bestimmtes Portfolio.
Lean Budgets
Lean Budgets ist ein Lean-Agile-Ansatz zur Finanzsteuerung, der den Durchsatz und die Produktivität erhöht, indem er den mit der Projektkostenrechnung verbundene Mehraufwand und die damit verbundenen Kosten reduziert.
Lean Business Case
Ein Lean Business Case (LBC) ist ein leichtgewichtiger Ansatz zur Beschreibung von Epics, einschließlich ihrer MVPs und des prognostizierten Geschäftswerts.
Lean Governance
Lean Governance ist eine Dimension des Lean Portfolio Managements, die die Überwachung und Entscheidungsfindung bei Ausgaben, Audit und Compliance, Ausgabenprognosen und Messungen unterstützt.
Lean Portfolio Management
Die Kernkompetenz “Lean Portfolio Management” bringt Strategie und Ausführung in Einklang, indem Lean- und Systems-Thinking-Ansätze auf Strategie, Investitionsfinanzierung sowie auf agilen Portfoliobetrieb und -steuerung angewendet werden.
Lean Quality Management System, QMS (Qualitätsmanagementsystem)
Ein Qualitätsmanagementsystem (QMS) schreibt Praktiken, Richtlinien und Verfahren vor, die erforderlich sind, um Sicherheit und Wirksamkeit zu bestätigen. SAFe-Organisationen wechseln von der traditionellen zur Lean-QMS-Governance.
Lean User Experience (Lean UX)
Lean User Experience Design beschreibt ein Mindset, eine Kultur und einen Prozess, das Lean-Agile-Methoden umfasst. Es implementiert Funktionalität in minimal funktionsfähigen Inkrementen und bestimmt den Erfolg durch Messung der Ergebnisse anhand einer Nutzenhypothese.
Lean-Agile Center of Excellence (Lean-Agiles Kompetenzteam)
Das Lean-Agile Center of Excellence (LACE) ist ein kleines Team, das sich der Anwendung der SAFe Lean-Agile Arbeitsweise widmet.
Lean-Agile Leadership
Die Kernkompetenz “Lean-Agile Leadership” beschreibt, wie Lean Agile Leaders organisatorische Veränderung sowie operative Exzellenz vorantreiben und aufrechterhalten, indem sie Einzelpersonen und Teams dazu befähigen, ihr höchstes Potenzial zu erreichen.
Lean Agile Mindset
Das Lean Agile Mindset ist die Kombination aus Überzeugungen, Annahmen, Einstellungen und Handlungen von Menschen in einem SAFe-Kontext, die sich die Konzepte des Agilen Manifests und des Lean Thinking zu eigen machen. Es ist die persönliche, intellektuelle und führungsbezogene Grundlage für die Übernahme und Anwendung von SAFe-Prinzipien und -Praktiken.
Lean-Agile Principles (Lean-Agile-Prinzipien)
SAFe basiert auf zehn unveränderlichen, grundlegenden Lean-Agile-Prinzipien. Diese Grundsätze und wirtschaftlichen Konzepte sind die Basis für alle Rollen und Praktiken in SAFe.
Little's Law (Little-Theorem)
Das Little-Theorem beschreibt die Warteschlangentheorie und besagt, dass die durchschnittliche Wartezeit auf einen Service gleich dem Verhältnis der durchschnittlichen Warteschlangenlänge geteilt durch die durchschnittliche Verarbeitungsrate ist.
M
Measure and Grow (Messen und Wachsen)
Mit Messen und Wachsen werden Portfolios mit Blick auf ihre Fortschritte in Richtung Business Agility bewertet und nächste Schritte zur Verbesserung festgelegt.
Metrics (Metriken)
Metriken sind abgestimmte Messgrößen, die helfen zu bewerten, wie gut die Organisation auf Portfolio-, Large Solution-, Program- und Team-Ebene beim Erreichen der geschäftlichen und technischen Ziele voranschreitet.
Milestones (Meilensteine)
Meilensteine werden verwendet, um den Fortschritt hin zu einem bestimmten Ziel oder Ereignis nachzuverfolgen. Es gibt drei Arten von Meilensteinen im SAFe-Kontext: Programminkrement (PI), Termin- und Lernmeilensteine.
Minimum Marketable Feature (Minimales vermarktbares Feature)
Das Minimum Marketable Feature (MMF) ist die Mindestfunktionalität, die Teams bauen/liefern können, um die Nutzenhypothese des Features zu verifizieren.
Minimum Viable Product (Minimal nutzbares Produkt)
In SAFe ist ein Minimum Viable Product (MVP) eine frühe und minimale Version eines neuen Produkts oder einer Solution, die verwendet wird, um die Nutzenhypothese eines EPICs zu beweisen oder zu widerlegen. Im Gegensatz zu Storyboards, Prototypen, Mockups, Wireframes und anderen Analysetechniken ist das MVP ein tatsächliches Produkt, das von echten Kunden verwendet wird, um validiertes Lernen zu erzeugen.
Model-Based Systems Engineering (MBSE)
Beim Model-Based Systems Engineering (MBSE) werden eine Reihe in Verbindung stehender Systemmodelle entwickelt, die dabei helfen, ein System während seiner Entwicklung zu definieren, zu entwerfen und zu dokumentieren. Diese Modelle bieten eine effiziente Möglichkeit Systemaspekte im Sinne der Stakeholder zu evaluieren, zu aktualisieren und zu kommunizieren.
Dabei wird die Abhängigkeit von bestehenden Dokumentationen erheblich reduziert.
Modified Fibonacci Sequence (Modifizierte Fibonacci-Reihe)
Bei der relativen Schätzung wird eine modifizierte (unreine) Fibonacci-Reihe (1, 2, 3, 5, 8, 13, 20, 40, 100) verwendet, um die inhärente Unsicherheit widerzuspiegeln, wenn die Größe des zu schätzenden Auftrags größer wird.
N
Nonfunctional Requirements, NFRs (Nichtfunktionale Anforderungen)
Nichtfunktionale Anforderungen definieren Systemattribute wie Sicherheit, Zuverlässigkeit, Leistung, Wartbarkeit, Skalierbarkeit und Benutzerfreundlichkeit. Sie dienen als Vorgaben oder Restriktionen für das Design des Systems über die verschiedenen Backlogs hinweg.
O
Objective and Key Results, OKRs (Ziele und Schlüsselergebnisse)
In SAFe können Ziele und Schlüsselergebnisse (Objectives and Key Results, OKRs) verwendet werden, um wichtige Informationen über ein strategisches Thema zu definieren, zu organisieren und zu kommunizieren und den Fortschritt durch konkrete, spezifische und messbare Aktionen zu verfolgen.
Operational Value Streams (Operative Wertströme)
Operative Wertströme (OVS) bezeichnen die Abfolge von Aktivitäten, die erforderlich sind, um Kunden:innen ein Produkt oder eine Dienstleistung bereitzustellen. Beispiele sind die Herstellung eines Produkts, die Erfüllung eines Auftrags, die Aufnahme und Behandlung eines medizinischen Patienten, die Bereitstellung eines Kredits oder die Erbringung einer professionellen Dienstleistung.
Organizational Agility
Die Kernkompetenz “Organizational Agility” beschreibt, wie Lean denkende Mitarbeiter:innen und agile Teams ihre Geschäftsprozesse optimieren, Strategien mit klaren und ausschlaggebend neuen Verpflichtungen entwickelt werden und sich die Organisation nach Bedarf schnell anpassen kann, um neue Chancen zu nutzen.
Organizational Change Management (Organisatorisches Changemanagement)
Organisatorisches Changemanagement ist ein Sammelbegriff rund um alle Ansätze zur Vorbereitung, Unterstützung und Begleitung von Einzelpersonen, Teams und Organisationen bei der Durchführung von organisatorischen Veränderungen.
P
Pareto Analysis (Pareto-Analyse)
Die Pareto-Analyse ist eine Technik, die während eines Inspect&Adapt-Ereignisses verwendet wird, um die Anzahl der Maßnahmen einzugrenzen, die den größten Gesamteffekt erzeugen.
Participatory Budgeting (partizipative Budgetierung)
Die partizipative Budgetierung ist der Prozess, den das Lean Portfolio Management verwendet, um das Gesamtbudget eines Portfolios auf seine Wertströme zu allokieren.
Personas
Personas sind fiktive Konsument:innen und/oder Nutzer:innen, die aus der Markt- bzw. Kundenforschung abgeleitet werden, um einen kundenzentrierten Ansatz in der Produktentwicklung vorantreiben.
Phase Gates (Stage-Gates)
Stage-Gates sind traditionelle Governance-Meilensteine, die in SAFe durch Meilensteine, basierend auf der objektiven Evaluation von funktionierenden Systemen, ersetzt werden.
PI Objectives
Programminkrement (PI) Objectives sind eine Zusammenfassung der geschäftlichen und technischen Ziele, die ein Agile Team oder ein Train im kommenden Programminkrement (PI) erreichen will.
Plan-Do-Check-Adjust, PDCA
Plan-Do-Check-Adjust (PDCA) ist eine iterative, vierstufige Methode zur Steuerung der Variabilität und zur Durchführung von Anpassungen als Reaktion auf Feedbacks während der Produktentwicklung.
Planning Interval (PI), früher: Program Increment
Ein Planning Interval (PI) ist ein Zeitabschnitt, in der ein Agile Release Train (ART) inkrementell Wert, in Form funktionierender und getesteter Software und Systeme liefert. PIs dauern normalerweise acht bis zwölf Wochen. Das häufigste Muster eines PIs sind vier Entwicklungsiterationen, gefolgt von einer Innovations- und Planungsiteration (IP).
Portfolio
Ein SAFe Portfolio richtet die Strategie auf die Umsetzung über eine Sammlung von Entwicklungswertströmen aus. Jeder Wertstrom arbeitet im Rahmen eines gemeinsamen Governance-Modells und liefert eine oder mehrere Solutions, die das Unternehmen benötigt, um den gefassten Geschäftsauftrag zu erfüllen.
Portfolio Backlog
Das Portfolio Backlog ist das Backlog der höchsten SAFe-Ebene. Es bietet einen Ort für kommende Geschäftsideen sowie für Enabler Epics, die darauf abzielen, ein umfassendes Angebot an Solutions zu schaffen und zu entwickeln.
Portfolio Canvas
Das Portfolio Canvas umfasst die Entwicklungswertströme, die in einem SAFe-Portfolio enthalten sind, die Werterwartungen und die Lösungen, die sie liefern, die Kunden, die sie bedienen, die Budgets, die jedem Wertstrom zugewiesen sind, und andere wichtige Aktivitäten und Ereignisse, die erforderlich sind, um die Portfolio-Vision zu erreichen.
Portfolio Kanban
Das Portfolio Kanban-System ist eine Methode zur Visualisierung, Verwaltung und Analyse der Priorisierung und des Durchlaufs von Portfolio-Epics, von der Ideenfindung bis zur Implementierung und Fertigstellung.
Portfolio SAFe
Portfolio SAFe verbindet Strategie und Umsetzung, um die Lösungsentwicklung rund um die Wertschöpfung durch einen oder mehrere Wertströme zu organisieren.
Portfolio Vision
Die Portfolio Vision ist eine Beschreibung des zukünftigen Zustands der Wertströme und Solutions eines Portfolios. Sie beschreibt, wie diese zusammenhängen müssen, um die Ziele des Portfolios und das damit verbundene Unternehmensziel zu erreichen.
Pre-and Post-PI Planning (Pre- & Post-PI-Planung)
Pre- & Post-PI-Planung werden durchgeführt, um die PI-Planungen der Agile Release Trains (ARTs) und Lieferanten in einem Solution Train vor- und nachzubereiten.
Problem-Solving Workshop (Problemlösungs-Workshop)
Der Problemlösungs-Workshop ist Teil der Veranstaltung Inspect and Adapt (I&A) und ist ein strukturierter Ansatz, um die Ursache von systemischen Problemen zu finden.
Product Management (Produktmanagement)
Das Produktmanagement ist verantwortlich für die Erarbeitung und Unterstützung bei der Entwicklung wertschöpfender, realisierbarer, funktionsfähig und nachhaltiger Produkte, die die Kundenbedürfnisse über den Produktlebenszyklus hinweg erfüllen.
Product Owner, PO
Ein:e Product Owner (PO) ist als Mitglied des Agile Teams verantwortlich für die Definition und Priorisierung von Stories im Team Backlog verantwortlich. Product Owner stellen die Einhaltung der Programmprioritäten sicher und gewährleisten gleichzeitig die konzeptionelle und technische Integrierbarkeit der Features oder Komponenten.
Product Owner (PO) Sync
Der PO Sync ist ein regelmäßiges Meeting eines ART, um einen Überblick darüber zu erhalten, wie gut der ART bei der Erfüllung seiner PI-Ziele vorankommt, um Probleme oder Möglichkeiten bei der Feature-Entwicklung zu besprechen und um eventuelle Umfangsanpassungen zu bewerten.
Program Backlog, jetzt: ⇾ ART Backlog
Das ART Backlog ist der Ort für anstehende Features, die Benutzerbedürfnisse adressieren und Geschäftsnutzen durch einen einzelnen Agile Release Train (ART) liefern sollen. Es enthält auch die Enabler-Features, die für den Aufbau der Architectural Runway des betreffenden ART erforderlich sind.
Program Board, jetzt: ⇾ ART Planning Board
Program Increment (PI), jetzt: ⇾ Planning Interval (PI)
Program Increment (PI) Planning
Programminkrementplanung ist ein kadenzbasiertes Event und gibt den Herzschlag eines Agile Release Train (ART) vor, das idealerweise als Präsenzveranstaltung organisiert wird. Hier richten sich die Teams im ART auf eine gemeinsame Mission und Vision aus.
Program Kanban, jetzt: ⇾ ART Kanban
Program Predictability Measure, jetzt: ⇾ ART Predictability Measure
Program Risiks (Programmrisiken), jetzt: ⇾ ART PI Risks
R
Refactoring
Unter Refactoring versteht man die Verbesserung der internen Struktur oder Funktionsweise eines Codes oder einer Komponente, ohne das externe Verhalten zu verändern.
Relative Estimation (Relative Schätzung)
Bei der relativen Schätzung werden Aufträge miteinander verglichen, um deren Größe und Wert schnell abzuschätzen.
Release on Demand
Release on Demand ist der Prozess, der neue Funktionalitäten sofort oder inkrementell je nach Bedarf an Kunden:innen ausliefert.
Release Train Engineer (RTE)
Ein:e Release Train Engineer (RTE) ist Servant Leader (dienende Führungskraft) und Coach für einen Agile Release Train (ART). Die Hauptaufgaben sind die unterstützende Begleitung der ART-Events und -Prozesse sowie der Teams bei der Entwicklung und Lieferung der Wertschöpfung. RTEs kommunizieren mit Stakeholdern, eskalieren Impediments (Hindernisse), helfen beim Risikomanagement und treiben unermüdlich Verbesserungen voran.
Relentless Improvement (Unaufhörliche Verbesserung)
Unaufhörliche Verbesserung ist die vierte Säule des SAFe House of Lean und fördert Lernen und Wachstum durch kontinuierliche Reflexion und Prozessverbesserungen.
Roadmap
Die Roadmap ist ein Zeitplan von Ereignissen und Meilensteinen der geplante Solutionlieferungen entlang eines Planungshorizonts.
ROAMing Risks
Das ROAMing von Risiken ist eine Aktivität im Rahmen der PI Planung, bei der die von den Teams identifizierten Programmrisiken in einem breiteren Managementkontext adressiert werden.
Root Cause Analysis (Ursache-Wirkungs-Analyse)
Eine Ursache-Wirkungs-Analyse wendet eine Reihe von Problemlösungstechniken an, um die tatsächlichen Ursachen eines Problems als Teil des Inspizieren & Anpassen (Inspect & Adapt) Events zu identifizieren.
S
SAFe Big Picture, BP
Das SAFe Big Picture ist eine Visualisierung der primären Rollen, Aktivitäten und Artefakte des Frameworks. Über die klickbaren Icons auf scaledagileframework.com kann auf SAFe Artikel zugegriffen werden.
SAFe Fellow
SAFe® Fellows sind ausgewählte Experten, die die größten Organisationen der Welt dabei unterstützen, ihre digitale Transformation zu beschleunigen und Business Agility zu erreichen. Der Weg zum SAFe® Fellow ist eine Reise, die jahrelange Praxis und Engagement erfordert. Mit der Auszeichnung von Scaled Agile als SAFe® Fellow werden Menschen (zurzeit etwa 40 weltweit) geehrt, die ein Höchstmaß an Kompetenz und Vordenkergeist in der Praxis und den Prinzipien von SAFe bewiesen haben. Das Programm wurde 2015 ins Leben gerufen und zeichnet Personen aus, die über die nötige Tiefe und Breite an Erfahrung verfügen, um auf den höchsten Komplexitätsebenen der digitalen Transformation von Unternehmen zu arbeiten, und die sich als Vordenker im Bereich Lean-Agile etabliert haben.
SAFe for Government
SAFe for Government ist eine Zusammenstellung von erfolgreichen Vorgehensweisen, mit deren Hilfe Lean-Agile-Praktiken in einem behördlichen Kontext implementiert werden können.
SAFe for Lean Enterprises
SAFe for Lean Enterprises ist das weltweit führende Framework für geschäftliche Agilität. SAFe integriert die Stärke von Lean, Agile und DevOps in ein umfassendes Betriebssystem, das Unternehmen hilft, im digitalen Zeitalter erfolgreich zu sein, indem innovative Produkte und Dienstleistungen schneller, vorhersehbarer und mit höherer Qualität geliefert werden.
SAFe Implementation Roadmap
Die SAFe Implementation Roadmap besteht aus einer Übersichtsgrafik und einer 12-teiligen Artikelserie, die eine Strategie in Form einer Reihenfolge von Aktivitäten beschreibt, die sich bei erfolgreichen Implementierungen von SAFe als effektiv erwiesen haben.
SAFe Lean Startup Cycle
Der SAFe Lean Startup-Zyklus ist ein hochgradig iterativer Bauen-Messen-Lern-Zyklus für Produktinnovation sowie strategische Investitionen. Diese Strategie zur Implementierung von Epics bietet die wirtschaftlichen und strategischen Vorteile eines Lean Startups, indem Investitionen und Risiken inkrementell verwaltet werden. SAFe unterstützt hier mit der Etablierung von Fluss und Transparenz.
SAFe Practice Consultants (SPCs)
Zertifizierte SAFe Practice Consultants (SPCs) sind Treiber:innen der Transformation (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 bei der erfolgreichen Implementierung von SAFe eine entscheidende Rolle. SPCs können aus verschiedenen internen oder externen Rollen kommen, wie etwa fachliche oder technologische Führungskräfte, Portfolio-, Programm-, Projektmanager:innen, Prozessverantwortliche, Architekt:innen, Analyst:innen und Berater:innen.
SAFe Scrum, früher: ScrumXP
SAFe Scrum ist ein Prozess zur Wertschöpfung für crossfunktionale, selbstorganisierte Teams innerhalb von SAFe. Er kombiniert die Leistungsfähigkeit von Scrum mit der von Extreme Programming (XP).
Scrum Master
Scrum Master sind Servant Leader (dienende Führungskräfte) und Coaches eines Agile Teams. Sie unterstützen das Team in ihrer Arbeit mit Scrum, Extreme Programming (XP), Kanban und SAFe und sorgen dafür, dass der vereinbarte agile Prozess verfolgt wird. Sie helfen auch bei der Beseitigung von Impediments (Hindernissen) und fördern eine Umgebung für Hochleistungs-Teams mit kontinuierlichem Durchsatz und treiben unermüdlich Verbesserungen voran.
Scrum of Scrums, jetzt: ⇾ Coach Sync
ScrumXP, jetzt: ⇾ SAFe Scrum
ScrumXP ist ein Prozess zur Wertschöpfung für crossfunktionale, selbstorganisierte Teams innerhalb von SAFe. Er kombiniert die Leistungsfähigkeit von Scrum mit der von Extreme Programming (XP).
Set-Based Design
Set-Based Design (SBD) ist eine Praktik, 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 Varianten und untersucht sie parallel, wobei nach und nach schwache Optionen verworfen werden. Dieses Vorgehen erhöht die Flexibilität im Entwurfsprozess, indem technische Lösungen erst übernommen werden, nachdem die Annahmen validiert wurden. Dies führt schlussendlich zu besseren wirtschaftlichen Ergebnissen.
Shared Services
Shared Services stellen spezielle Rollen, Personen und Dienstleistungen dar, die für den Erfolg eines Agile Release Trains (ART) oder Solution Trains benötigt werden, aber nicht in Vollzeit zur Verfügung stehen.
Silos
Silos sind funktional orientierte Organisationskonstrukte, die mit Richtlinien und Verfahren wiederholbare, effiziente Abläufe für Spezialist:innen innerhalb dieser Funktionseinheit sicherstellen, ohne den größeren und ganzheitlicheren Wertfluss über mehrere Funktionseinheiten hinweg zu verstehen und zu berücksichtigen.
Solution
Jeder Wertstrom produziert eine oder mehrere Solutions in Form von Produkten, Services oder Systemen, die internen oder externen Kunden:innen bereitgestellt werden.
Solution Architect
Ein Solution Architect ist verantwortlich für die Definition und Kommunikation einer gemeinsam genutzten technischen und architektonischen Vision für einen Solution Train. Damit wird gewährleistet, dass das System oder die zu entwickelnde Solution für den vorgesehenen Zweck geeignet ist.
Solution Context (Solution-Kontext)
Der Solution-Kontext identifiziert kritische Aspekte der operativen Umgebung für eine Solution. Er liefert ein wesentliches Verständnis für Anforderungen, Nutzung, Installation, Betrieb und Support der Solution selbst. Der Solution Kontext beeinflusst in hohem Maße die Möglichkeiten und Beschränkungen für Release on Demand.
Solution Demo
Die Solution Demo integriert die Entwicklungsanstrengungen aller ARTs und Lieferanten des Solution Train je PI und macht sie für Kunden und andere Stakeholder zur Bewertung und zum Feedback sichtbar.
Solution Intent (Solution-Intention)
Die Solution-Intention ist der Ort zur Speicherung, Verwaltung und Kommunikation des Wissens über das aktuelle und beabsichtigte Verhalten der Solution. Dazu gehören bei Bedarf sowohl feste, als auch variable Spezifikationen und Entwürfe, Verweise auf geltende Normen, Systemmodelle sowie funktionale und nichtfunktionale Tests und die Rückverfolgbarkeit.
Solution Management
Das Solution Management ist verantwortlich für die Definition und Unterstützung des Aufbaus von erstrebenswerten, realisierbaren, tragfähigen und nachhaltigen Geschäftslösungen mit großem Umfang, die die Kundenbedürfnisse fortwährend erfüllen.
Solution Train
Der Solution Train ist das organisatorische Konstrukt zur Erstellung großer und komplexer Solutions, die die Koordination mehrerer Agile Release Trains sowie die Beiträge von Zulieferern erfordern. Er richtet die ARTs auf eine gemeinsame geschäftliche und technologische Mission, unter Verwendung der Solution Vision, des Solution Backlogs und der Solution Roadmap sowie eines abgestimmten Programminkrements (PI), aus.
Solution Train Backlog
Das Solution Train Backlog ist der Ort für anstehende Capabilities und Enabler, die mehrere Agile Release Trains betrifft. Sie sind dazu bestimmt, die Solution voranzubringen und die Architectural Runway zu bauen.
Solution Train Engineer (STE)
Ein:e Solution Train Engineer (STE) ist ein Servant Leader (dienende Führungskraft) und Coach für den Solution Train, welche:r die Arbeit aller ARTs und Lieferanten im Wertstrom erleichtert und leitet.
Spanning Palette (übergreifende Palette)
Die übergreifende Palette enthält verschiedene Rollen und Artefakte, die für ein bestimmtes Team-, ein Programm-, eine Large Solution- oder einen Portfoliokontext gelten können und ist Bestandteil des Big Pictures.
Spike (Pikser)
Ein Pikser ist eine spezielle Story (Exploration Enabler Story), die das notwendige Wissen zu Tage fördert, eine Anforderung besser zu verstehen oder die Zuverlässigkeit einer Story-Schätzung zu erhöhen. Sie werden genutzt, um das Risiko eines technischen Ansatzes zu reduzieren.
Sprint
Der Sprint Begriff stammt aus der Scrum-Methode und ist gleichbedeutend mit dem Begriff Iteration in SAFe.
Stories
Stories sind kurze Beschreibungen eines kleinen Teils der gewünschten Funktionalität. Stories werden in der Sprache der Benutzer:innen geschrieben. Agile Teams implementieren kleine, vertikal geschnittene Teile der Funktionalität und sind so dimensioniert, dass sie innerhalb einer Iteration abgeschlossen werden können.
Story Map (Story-Karte)
Eine Story-Karte ist eine Design-Thinking-Methode, die Stories entsprechend den notwendigen Aktivitäten für ein bestimmtes Ziel von Benutzer:innen organisiert.
Story Point (Story-Punkte)
Ein Story-Punkt ist eine einzelne Zahl, die bei der relativen Schätzung verwendet wird, um eine Bewertung als Kombination von verschiedenen Variablen darzustellen: Volumen, Komplexität, Wissen und Unsicherheit.
Strategic Themes (Strategische Themen)
Strategische Themen sind differenzierende Geschäftsziele, die ein Portfolio mit der Strategie des Unternehmens verbinden. Sie beeinflussen die Portfoliostrategie und liefern den geschäftlichen Kontext für Portfolioentscheidungen.
Sunk Costs (Vergangenheitskosten)
Vergangenheitskosten (Sunk Costs) beziehen sich auf bereits ausgegebenes Geld, das bei zukünftigen – auf Effektivität ausgerichteten – Investmententscheidungen ignoriert werden sollte.
Supplier (Lieferant)
Ein Lieferant ist eine interne oder externe Organisation, die Komponenten, Subsysteme oder Dienstleistungen entwickelt und liefert, die den Solution Trains und Agile Release Trains helfen, ihre Kunden:innen Solutions zu liefern.
SWOT Analysis (SWOT-Analyse)
Die SWOT-Analyse ist eine strategische Planungsmethode zur Identifizierung von Stärken, Schwächen, Chancen und Bedrohungen bezogen auf die derzeitige Geschäftssituation als Bestandteil einer SAFe-Portfolio-Vision.
System Architect/Engineer
Ein:e System Architect/Engineer ist verantwortlich für die Definition und Kommunikation einer gemeinsamen, Technologie- und Architekturvision für einen Agile Release Train, um sicherzustellen, dass das in der Entwicklung befindliche System oder die Solution für den vorgesehenen Zweck geeignet ist.
System Demo
Eine System-Demo ist ein wesentliches Ereignis, das eine integrierte Sicht auf die neuen Funktionen der jüngsten Iteration ermöglicht, die von allen Teams im Agile Release Train geliefert wurden. Jede System-Demo gibt Stakeholdern einen objektiven Eindruck über den Fortschritt eines Programminkrements (PI).
System Team
Das System Team ist ein spezialisiertes Agile Team, das beim Aufbau und der Unterstützung der agilen Entwicklungsumgebung hilft. Typischerweise ist hier die Entwicklung und Wartung der Toolchain für die Continuous Delivery Pipeline beinhaltet. Das System Team kann auch die Integration von Lieferungen aus agilen Teams unterstützen, bei Bedarf Ende-zu-Ende-Tests der Solution durchführen und beim Deployment und Release on Demand helfen.
Systems Thinking (Systemisches Denken)
Das systemische Denken verfolgt einen ganzheitlichen Ansatz bei der Lösungsentwicklung, der alle Aspekte eines "Systems" und seiner Umgebung über den gesamten Lebenszyklus (planen, entwickeln, prüfen, ausliefern und betreiben) einbezieht.
T
Team and Technical Agility
Die Kernkompetenz “Team and Technical Agility” beschreibt wesentliche Fähigkeiten und Lean-Agil-Prinzipien und Praktiken, die leistungsstarke Agile Teams und Agile Release Trains nutzen, um qualitativ hochwertige Lösungen für ihre Kunden:innen zu entwickeln.
Team Backlog
Das Team Backlog enthält Stories und Enabler, die aus dem Programm-Backlog abgeleitet werden. Das Team Backlog kann weitere Arbeitselemente enthalten, welche aus einem Teamkontext entstehen, um den Teamanteil des Systems voranzubringen.
Team Kanban
Team-Kanban hilft Teams dabei, Arbeitsabläufe zu visualisieren, WIP-Limit (Work-In-Process-Limit) festzulegen, den Durchsatz zu messen und ihren Prozess und damit den Wertfluss kontinuierlich zu verbessern.
Team Topologies (Team-Topologien)
Team-Topologien definieren auf Modellebene vier klare Ansätze für die Organisation von agilen Teams und ARTs.
Technical Debt (Technische Schulden)
Technische Schulden stehen für die impliziten Kosten und auflaufenden Zinsen zukünftiger Arbeiten, die in der Regel durch die wissentliche oder unwissentliche Wahl einer suboptimalen oder unvollständigen Lösung verursacht werden.
Test-Driven Development (Testgetriebene Entwicklung)
Testgetriebene Entwicklung (Test-Driven Development, TDD) ist eine Herangehensweise und Pratik, die das Erstellen und Ausführen von Tests vor der Implementierung des Codes oder einer Komponente eines Systems beinhaltet.
TOWS Analysis (TOWS-Matrix)
Die TOWS-Matrix wird in Verbindung mit einer SWOT-Analyse verwendet, um strategische Optionen für einen besseren Stand in der Zukunft als Teil einer SAFe-Portfolio-Vision zu identifizieren.
U
U-Curve Optimization (Chargengrößenoptimierung)
Die Chargengrößenoptimierung bestimmt die optimale Chargengröße durch Abwägen von Transaktionskosten und Haltekosten.
Uncommited Objectives (Unverbindliche Zielsetzungen)
Unverbindliche Ziele helfen dabei, die Vorhersagbarkeit der Lieferung von Geschäftswerts zu verbessern, da sie nicht im Commitment des Teams enthalten sind und somit bei der Messung der Programmvorhersagbarkeitskennzahl nicht berücksichtigt werden. Teams können unverbindliche Ziele immer dann nutzen, wenn sie die Erfüllung des Zieles für fraglich erachten.
V
Value (Mehrwert)
Mehrwert (Value) stellt den Nutzen dar, den ein Unternehmen seinen Kunden und Stakeholdern liefert. Er wird in SAFe an verschiedenen Stellen und in unterschiedlichen Zusammenhängen berücksichtigt.
Value Management Office, früher: Agile Program Management Office
Das Agile Program Management Office (APMO) ist eine organisatorische Funktion, die den Lean Portfolio Management Prozess unterstützt und die Förderung der operationalen Excellenz und der Lean Governance als Teil einer Lean Agile Transformation betreibt.
Value Stream (Wertstrom)
Wertströme stellen die Abfolge von Aktivitäten in einer Organisation dar, um einen kontinuierlichen Wertfluss für Kunden:innen zu bieten.
Value Stream Coordination (Koordination von Wertströmen)
Die Koordination von Wertströmen beinhaltet das Management von Abhängigkeiten und die Nutzung von Chancen, die nur durch die Verbindungen zwischen Wertströmen bestehen.
Value Stream Identification (Identifizierung von Wertströmen)
Die Identifizierung von Wertströmen ist eine Aktivität, die Portfolios verwenden, um Entwicklungswertströme und die von ihnen unterstützten operativen Wertströme zu identifizieren.
Value Stream KPIs (Wertstrom-KPIs)
Wertstrom-KPIs (Key Performance Indicators) sind quantifizierbare Messgrößen, die zur Analyse der Leistung eines Wertstroms im Vergleich zu den erwarteten Geschäftsergebnissen verwendet werden.
Value Stream Mapping (Abbildung von Wertströmen)
Die Abbildung von Wertströmen ist ein wesentliches Werkzeug, um den Wertfluss in der Continuous Delivery Pipeline zu verbessern. Es hilft dabei, die nötige Transparenz herzustellen, um zu Verzögerungen führende Engpässe und Problembereiche im Fluss zu identifizieren.
Velocity (Geschwindigkeit)
Die Velocity (Geschwindigkeit) ist gleich der Summe der Punkte für alle abgeschlossenen Stories, die ihre Definition of Done (DoD) erfüllt haben.
Vision
Die Vision ist eine Beschreibung des zukünftigen Zustands der zu entwickelnden Solution. Sie reflektiert die Bedürfnisse von Kunden:innen und Stakeholdern sowie Funktionen und Fähigkeiten, die zur Erfüllung dieser Bedürfnisse beabsichtigt sind.
W
Weighted Shortest Job First (WSJF, gewichteter kürzester Auftrag zuerst)
Weighted Shortest Job First ist ein Priorisierungsmodell, das verwendet wird, um Backlog-Einträge (z. B. Features, Capabilities und Epics) so zu ordnen, dass ein maximaler wirtschaftlicher Nutzen entsteht. In SAFe wird WSJF zur Priorisierung genutzt, in dem Cost of Delay (CoD) durch die Aufgabengröße geteilt wird.
Work in Process, WIP
Work in Process (WIP) steht für teilweise abgeschlossene Arbeit, d. h. Dinge, bei denen noch etwas zu tun ist und die daher noch in Bearbeitung sind. Zu viel WIP verwässert Prioritäten, verursacht häufige Kontextwechsel und erhöht den Overhead.
5
5 Whys, 5W (5 Warums)
Die 5 Warums sind eine bewährte Problemlösungstechnik, mit der im Rahmen von Inspect and Adapt die einem bestimmten Problem zugrunde liegenden Ursache-Wirkungs-Zusammenhänge untersucht werden.
