© 2021 Scaled Agile, Inc. All rights reserved.

Evolving the Scaled Agile Framework:

Update to SAFe 5

Guidance for organizing around value, DevSecOps, and agility for business teams

Learn more

Clear explanations and actionable guidance

SAFe Distilled 5.0

SAVE 35% WITH CODE SCALEDAGILE

ORDER NOW

SAFe Glossary

The SAFe glossary is a set of definitions for all SAFe Big Picture elements.  The extended glossary provides definitions for additional terms used in the Framework. Some are unique to SAFe (e.g., PO Sync), while others are common in Lean-Agile development (e.g., MVP). They are provided here for clarity in their meaning in the context of SAFe. All extended glossary terms appear in the English configuration and will appear in other language configurations once translated.

Author

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

    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.

  • Agile Release Train (ART)

    Ein Agile Release Train (ART) ist ein auf längere Zeit ausgelegtes Team aus mehreren agilen Teams (Agile Teams), welches im Zusammenspiel untereinander und mit anderen Stakeholdern eine oder mehrere Lösungen inkrementell 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 cross-funktionale Gruppe von 5-11 Personen, welche in kurzen Zeitintervallen (Iterationen) kontinuierlich und inkrementell 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, so dass die Möglichkeit besteht, Implementierungsansätze zu steuern, ohne dass es zu Verzögerungen kommt.

  • Architectural Runway

    Eine Architectural Runway besteht aus vorhandenem Code, Komponenten und technischer Infrastruktur, die ohne intensive Überarbeitung und Verzögerung für die zeitnahe Umsetzung von Features notwendig sind.

  • ART Sync

    Der ART Sync ist ein Event des Agile Release Trains, das den Product Owner (PO) 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 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, welche durch die Entwicklung, den Support und den 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 Arbeitsvorrates (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, welche essentielle Daten auf einen Blick erfasst und kommuniziert (z. B. Burndown-Charts, Programmboard, Build-Status-Tafeln).

  • Built-In Quality (Integrierte Qualität)

    Integrierte Qualitäts-Praktiken stellen sicher, dass jedes Element der Solution über die gesamte Entwicklung hinweg bei jedem Inkrement 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 Fortschirtt 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 Agenda-Punkt der PI Planung, welcher 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 Feature, Enablern und technischer Schuld auszubalancieren und Kapazitäten für das kommende Programminkrement (PI) zu allokieren.

  • Committed PI Objectives (verpflichtende PI Ziele)

    Die verpflichtenden PI Ziele sind eine Reihe von SMART-formulierten Zielen, die von jedem Team erstellt werden, wobei der Geschä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 hochqualitative Systeme in der Anwendung von Lean-Agile Entwicklungsmethoden zu bauen.

  • Confindence 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 Release on Demand vorbereitet zu haben.

  • Continuous Exploration (CE)

    Continuous Exploration des Marktes und der Kundenbedarfe ist Treiber für Innovationen und unterstützt die gemeinsame Ausrichtung zu dem “Was” als Lösung verfolgt und gebaut werden sollte. Diese Bedarfe 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 auf 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

    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 für ein Wertinkrement und schafft ein gemeinsames Verständnis darüber, welche Arbeit als Teil eines Inkrements 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-Webseite.

  • DevOps

    DevOps 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, welche 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, 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 die Architectural Runway.

  • Enterprise Solution Delivery

    Die Kernkompetenz “Enterprise Solution Delivery” beschreibt, wie Lean-Agile Prinzipien und Handlungsweisen auf die Spezifikation, die Entwicklung, die Bereitstellung, den Betrieb von großen und anspruchsvollen Softwareanwendungen, Netzwerke und cyber-physikalische Systeme angewendet werden.

  • 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.

  • Epics

    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.

  • 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. Features sind 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 an allem arbeiten können, an was sie wollen, mit wem sie es 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 Zeitabschnitt fester Dauer, 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)

    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 Entwicklungsfortschritt 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 cyber-physischer 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-Theorembeschreibt 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 Change Management)

    Organisatorisches Change Management 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.

  • 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ässiges 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 (Programm-Backlog)

    Das Programm-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 (Programm-Board)

    Das Programm-Board zeigt die Feature-Liefertermine des PI, Feature-Abhängigkeiten zwischen den Teams und relevante Meilensteine.

  • Program Increment, PI (Programminkrement)

    Ein Programminkrement (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).

  • Program Increment (PI) Planning (Programminkrementplanung (PI))

    Programminkrementplanung ist ein kadenzbasiertes Event und gibt den Herzschlag eines Agile Release Train (ART) vor, welches idealerweise als Präsenzveranstaltung organisiert wird. Hier richten sich die Teams im ART auf eine gemeinsame Mission und Vision aus.

  • Program Kanban (Programm-Kanban)

    Die Programm- & Solution-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.

  • Program Predictability Measure (Programmvorhersagbarkeitskennzahl)

    Die Programmvorhersagbarkeitskennzahl fasst die geplanten gegenüber den tatsächlichen Geschäftswerte für alle Teams des ART zusammen und ist ein wichtiger Indikator für die Leistung und Zuverlässigkeit des ART.

  • Program Risiks (Programmrisiken)

    Programmrisiken werden von den Teams während der PI Planung identifiziert und stellen Risiken und Hindernisse dar, die die Zielerreichung, beeinträchtigen könnten.

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 Planungshorizontes.

  • 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 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 Program Consultants (SPCs)

    Zertifizierte SAFe Program 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.

  • Scrum Master

    Scrum Master sind Servant Leader (dienende Führungskräfte) und Coaches eines Agile Teams. Sie unterstützen das Team in Scrum, Extreme Programming (XP), Kanban und SAFe zu trainieren und sorgen dafür, dass dem vereinbarten agilen Prozess gefolgt wird. Sie helfen auch bei der Beseitigung von Impediments (Hindernissen) und fördern eine Umgebung für Hochleistungs-Teams, kontinuierlichen Durchsatz und treiben unermüdlich Verbesserungen voran.

  • Scrum of Scrums

    Das Scrum of Scrums (SoS) ist ein Event innerhalb eines ARTs, welches den ART dabei unterstützt, Abhängigkeiten zu koordinieren und Transparenz über Fortschritte und Hindernisse zu schaffen.

  • ScrumXP

    ScrumXP ist ein leichtgewichtiger Prozess zur Wertschöpfung für cross-funktionale, 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 Train (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/Engineer

    Ein:e Solution Architect/Engineer 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 Backlog

    Das Solution 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 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, welche die Kundenbedürfnisse fortwährend erfüllen.

  • Solution Train

    Der Solution Train ist das organisatorische Konstrukt zur Erstellung großer und komplexer Solutions, welche 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 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), welche 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, welche 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) bezieht sich auf bereits ausgegebenes Geld, welches bei zukünftigen - auf Effektivität ausgerichtete - 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

    Die System-Demo ist ein wesentliches Ereignis, welches 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, welches 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, welcher 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, welche 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 Stream Coordination (Koordination von Wertströmen)

    Die Koordination von Wertströmen beinhaltet das Management von Abhängigkeiten und die Nutzung von Chancen, welche 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, welche 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.

  • Value Streams (Wertströme)

    Wertströme stellen die Abfolge von Aktivitäten in einer Organisation dar, um einen kontinuierlichen Wertfluss für Kunden:innen zu bieten.

  • 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)

    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 (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.

© 2021 Scaled Agile, Inc. All rights reserved.