SAFe 6 Product Owner / Product Manager: Wertsteuerung im Agile Release Train in Köln

Tag 1: Rollen, Backlogs und Wertsteuerung1. SAFe 6 für Product Owner und Product Manager: Kontext und Rollen

• SAFe im Überblick:  Lean-Agile Mindset, SAFe-Werte (Alignment, Built-in Quality,  Transparency, Program Execution), SAFe-Prinzipien (Economic View, Assume Variability, Build Incrementally). Wie diese Prinzipien die tägliche PO/PM-Arbeit prägen.
• Der Agile Release Train (ART):  5-12 Teams, synchronisiert durch PI Planning, gesteuert durch ein  Programm-Backlog. Der ART als Wertschöpfungsmaschine - und PO/PM als  diejenigen, die bestimmen, welcher Wert geschaffen wird.
• Value Streams:  Jeder ART ist einem Value Stream zugeordnet - dem Weg, auf dem Wert von der Idee bis zum Kunden fließt. Operational Value Streams  (Geschäftsprozesse) vs. Development Value Streams  (Entwicklungsprozesse). PO/PM müssen den Value Stream ihres ART  verstehen.
• Zwei Rollen, klare Abgrenzung:
  • Product Manager (PM): Verantwortlich für das Was  auf Programm-Ebene. Definiert Produktvision und Roadmap, priorisiert  das Programm-Backlog (Features), arbeitet mit Stakeholdern und Kunden,  führt das PI Planning inhaltlich, verantwortet den Business Value.
  • Product Owner (PO): Verantwortlich für das Was  auf Team-Ebene. Übersetzt Features in User Stories, priorisiert das  Team-Backlog, definiert Akzeptanzkriterien, arbeitet täglich mit dem  Entwicklungsteam, nimmt Stories ab.
  • Zusammenarbeit PMPO:  Der PM definiert Features, der PO zerlegt sie in Stories. Der PM  priorisiert auf Programm-Ebene (WSJF), der PO priorisiert auf Team-Ebene (Story-Reihenfolge innerhalb der Iteration). Kein Gegeneinander, sondern Arbeitsteilung auf verschiedenen Ebenen.

• Zusammenarbeit mit dem Lean Portfolio Management:  Wie Portfolio-Epics zu ART-Features werden - der Fluss von Portfolio ->  ART -> Team. Brücke zum GFU-Seminar SAFe Lean Portfolio Management"  (S6717, 3T).
• Praxis-Übung:  Rollen-Klarstellung - Teilnehmende ordnen 15 typische PO/PM-Aufgaben  den richtigen Rollen zu: Wer schreibt die Produktvision? Wer definiert  Akzeptanzkriterien? Wer priorisiert Features? Wer spricht mit dem  Kunden?"

• Epics (Portfolio-Ebene):  Große, strategische Initiativen, die mehrere PIs dauern und hohe  Investitionen erfordern. Lean Business Case: Hypothese, erwarteter Wert, Kosten, MVP. Epics werden vom Portfolio genehmigt und an ARTs  delegiert.
• Features (Programm-Ebene):  Kundensichtbare Funktionalität, die innerhalb eines PI (8-12 Wochen)  lieferbar ist. Feature-Format: Feature: Name. Benefit Hypothesis:  Wir glauben, dass.... Acceptance Criteria: Wann ist das Feature  fertig?." Features werden vom PM priorisiert und vom PO in Stories  zerlegt.
• Stories (Team-Ebene):  Kleinste Einheit im Team-Backlog, innerhalb einer Iteration lieferbar.  User Stories (Nutzerwert) und Enabler Stories (technische Grundlagen,  Infrastruktur, Architektur). Stories sind vertikal geschnitten,  INVEST-konform und mit Akzeptanzkriterien versehen.
• Capabilities (Large Solution):  Zwischen Epics und Features - für Organisationen mit mehreren ARTs, die an einer gemeinsamen Lösung arbeiten. Wird vom Solution Management  priorisiert.
• Enabler Epics, Features und Stories:  Nicht alles liefert direkten Kundenwert - Architektur-Runway,  Infrastruktur, Forschung. Enabler sind keine technischen Schulden",  sondern bewusste Investitionen in die Zukunftsfähigkeit des Systems.
• Praxis-Übung:  Ein vorgegebenes Portfolio-Epic in 3 Features aufschlüsseln, jedes  Feature mit Benefit Hypothesis und Acceptance Criteria versehen. Ein  Feature in 5 User Stories zerlegen (vertikal, INVEST-konform).  Peer-Review: Sind die Stories schätzbar? Liefert jede Wert?

3. Backlog-Management auf zwei Ebenen: Priorisierung und Flow

• Programm-Backlog (PM-Verantwortung):  Alle Features des ART - priorisiert, gepflegt, ready für PI Planning.  Der PM ist der Gatekeeper: welche Features kommen ins nächste PI, welche nicht?
• WSJF: Weighted Shortest Job First:  SAFes Priorisierungsformel: WSJF = Cost of DelayJob Duration. Cost  of Delay = Business Value + Time Criticality + Risk  Reduction/Opportunity Enablement. Features mit dem höchsten WSJF werden  zuerst umgesetzt - nicht die lautesten Stakeholder bestimmen die  Reihenfolge, sondern der ökonomische Wert.
• Team-Backlog (PO-Verantwortung):  Alle Stories des Teams - abgeleitet aus Features, priorisiert für die  aktuelle Iteration. Der PO pflegt das Backlog kontinuierlich:  Refinement, Splitting, Priorisierung, Story-Readiness sicherstellen.
• Backlog Refinement in SAFe:  Nicht nur Stories besprechen", sondern: Features verstehen (PM erklärt den Kontext), Stories ableiten (PO + Team), Akzeptanzkriterien  definieren, Abhängigkeiten identifizieren, Stories schätzen (Story  Points).
• Capacity Allocation:  Wie viel Kapazität fließt in neue Features vs. Maintenance vs. Enabler? Empfehlung: 70/20/10 oder 60/20/20 - abhängig vom Reifegrad des Produkts. Der PM entscheidet über die Allokation, das Team respektiert sie.
• KI-gestützte Priorisierung (NEU in SAFe 6.0):  KI-Tools für WSJF-Schätzung (historische Daten nutzen für  Cost-of-Delay-Prognose), automatisierte Backlog-Analyse (Duplikate,  Inkonsistenzen, verwaiste Stories), KI-gestütztes Refinement  (ChatGPT/Claude generiert Akzeptanzkriterien und Edge Cases).
• Praxis-Übung:  WSJF-Priorisierung für 6 Features durchführen (Business Value, Time  Criticality, Risk Reduction, Job Size schätzen -> WSJF berechnen ->  Reihenfolge bestimmen). Ergebnis mit Bauchgefühl-Priorisierung  vergleichen - wo weichen sie ab?

4. Customer Centricity und Design Thinking in SAFe

• Customer Centricity als SAFe-Prinzip:  Build the right thing, then build it right." Nicht jedes Feature, das  ein Stakeholder fordert, ist das richtige Feature. Kundenwert  validieren, bevor gebaut wird.
• Design Thinking im SAFe-Kontext:  Empathize (Kundenprobleme verstehen), Define (Problemstatement  formulieren), Ideate (Lösungsoptionen generieren), Prototype (Minimum  Viable Product), Test (Validierung). Der PM nutzt Design Thinking zur  Feature Discovery, der PO nutzt es zur Story-Validierung.
• Personas und Customer Journeys:  Wer sind die Nutzer? Was sind ihre Ziele, Schmerzpunkte, Workflows?  Personas als Grundlage für Features und Stories - nicht abstrakte  Benutzer", sondern benannte Archetypen mit konkreten Bedürfnissen.
• KI für Customer Insights (NEU in SAFe 6.0):  KI-gestützte Persona-Entwicklung (aus Kundendaten Personas generieren), automatisierte Analyse von Kundenfeedback (Support-Tickets, Reviews, NPS-Kommentare -> Feature-Kandidaten ableiten), KI als Sparringspartner für Hypothesen-Validierung.
• Praxis-Übung:  Eine Persona für das eigene Produkt erstellen, eine Customer Journey  skizzieren, daraus 2 Feature-Hypothesen ableiten (Benefit Hypothesis +  Validierungskriterien). Optional: ChatGPT/Claude für Persona-Erweiterung nutzen.

Tag 2: PI Planning, Continuous Delivery und Zertifizierung5. PI Planning führen und vorbereiten: Die PO/PM-Perspektive

• Vorbereitung als PM:  Produktvision aktualisieren, Feature-Backlog priorisiert und ready"  machen (Benefit Hypothesis, Acceptance Criteria, WSJF), Business Context vorbereiten (strategische Ziele, Marktveränderungen, Kundenfeedback für das Team übersetzen), Architektur-Vision mit dem System Architect abstimmen.
• Vorbereitung als PO:  Features mit dem Team vorab besprechen (Pre-PI-Planning Refinement),  initiale Story-Ideen sammeln, Team-Kapazität berechnen (verfügbare TageFokus-Faktor), bekannte Abhängigkeiten identifizieren.
• PI Planning Ablauf aus PO/PM-Sicht:  Tag 1: PM präsentiert Business Context und Feature-Priorisierung ->  Teams breaken out, PO moderiert die Team-Breakout-Session (Features ->  Stories -> PI Objectives) -> PM reviewed die Team-Pläne. Tag 2:  Adjustments -> Abhängigkeiten klären (Programm-Board) -> Risiken  identifizieren (ROAM) -> Confidence Vote.
• PI Objectives formulieren:  Committed (verlässlich lieferbar, hoher Business Value) vs. Uncommitted (angestrebt, aber unsicher). Der PM bewertet den Business Value jedes Objectives. PO formuliert die Objectives mit dem Team so, dass sie für den PM und Stakeholder verständlich sind.
• Management Review und Confidence Vote: PO/PM präsentieren die Team-Pläne dem Management. Confidence Vote: unter 3 -> PO/PM müssen den Plan mit dem Team anpassen.
• Praxis-Übung:  PI Planning Simulation aus PO/PM-Perspektive - PM präsentiert Business  Context (3 Min), PO moderiert Team Breakout (Features -> Stories -> PI  Objectives, 15 Min), Abhängigkeiten auf dem Programm-Board markieren,  Confidence Vote.

6. PI Execution: Wert liefern und nachjustieren

• Iteration Planning (PO-Fokus):  PO wählt Stories aus dem Team-Backlog basierend auf den PI Objectives,  Team schätzt und plant Tasks. Iteration Goals formulieren: Was liefern wir am Ende dieser Iteration?"
• Daily Stand-up und Backlog-Pflege (PO-Alltag):  PO beantwortet Fragen zu Stories, klärt Akzeptanzkriterien im Lauf der  Iteration, nimmt fertige Stories ab (Definition of Done), pflegt das  Team-Backlog für die nächste Iteration.
• ART Sync und System Demo (PM-Fokus):  PM verfolgt den Gesamtfortschritt über alle Teams, nimmt an der ART  Sync teil, prüft die System Demo (integriertes Ergebnis aller Teams) -  passt der Gesamtfortschritt zur Produktvision?
• Mid-PI Adjustments:  Was passiert, wenn sich Prioritäten ändern? Features können innerhalb  des PI angepasst werden, aber PI Objectives bleiben stabil.  Scope-Flexibilität auf Story-Ebene: der PO kann Stories austauschen,  solange die Objectives erreichbar bleiben.
• Metriken für PO/PM:  Predictability Measure (geplant vs. geliefert), Feature Cycle Time (wie lange dauert ein Feature von Priorisierung bis Delivery?), Customer Satisfaction, Business Value delivered. SAFe 6.0 betont Flow-Metriken stärker als Velocity.
• Praxis-Übung:  Ein Szenario durchspielen: In der 3. Iteration meldet der wichtigste  Stakeholder eine dringende Änderung. PM und PO entscheiden gemeinsam:  Passt es noch in die PI Objectives? Was fällt raus? Wie kommunizieren  wir das dem Team und dem Stakeholder?

7. Continuous Delivery Pipeline und DevOps für PO/PM

• Continuous Exploration:  Die Arbeit vor dem Backlog - Hypothesen formulieren, Kundenbedürfnisse  erforschen, Features definieren. Der PM ist der Hauptakteur, unterstützt durch Design Thinking, Lean Startup und Customer Feedback.
• Continuous Integration und Continuous Deployment:  Was PO/PM darüber wissen müssen: Schnellere Feedbackzyklen bedeuten  schnellere Validierung von Features. Feature Toggles ermöglichen Dark  Launches" - Features in Produktion bringen, ohne sie für Endnutzer  sichtbar zu machen. Release on Demand: die Entscheidung Wann releasen?" ist eine Produktentscheidung, keine technische.
• Release on Demand (PM-Verantwortung):  Wann ist ein Feature bereit für den Markt? Nicht am PI-Ende, sondern  wenn der Business Value realisierbar ist. Der PM entscheidet über den  Release-Zeitpunkt - basierend auf Marktbedingungen, Kundenfeedback und  Feature-Reife.
• DevOps und Built-in Quality (PO-Verantwortung):  Der PO stellt sicher, dass die Definition of Done Built-in Quality  enthält: Code Review, Tests, keine technischen Schulden. Ohne Qualität  keine Geschwindigkeit - kurzfristige Abkürzungen rächen sich im nächsten PI.

8. KI-Werkzeuge für PO und PM (NEU in SAFe 6.0)

• AI-Empowered Product Management:  SAFe 6.0 integriert KI explizit in die PO/PM-Praxis - nicht als Add-on, sondern als Arbeitswerkzeug. Scaled Agile empfiehlt, KI systematisch in den täglichen PO/PM-Workflow einzubinden.
• KI für Backlog-Priorisierung:  Historische Daten nutzen für WSJF-Komponenten-Schätzung (Business Value und Job Size aus vergangenen Features ableiten), automatisierte  Duplikat-Erkennung im Backlog, KI-gestützte Impact-Analyse (welche  Features korrelieren mit Kundenzufriedenheit?).
• KI für Feature Discovery:  ChatGPT/Claude als Sparringspartner: Analysiere diese 50  Support-Tickets und identifiziere die 5 häufigsten Feature-Anfragen."  Persona-Generierung aus Kundendaten, Wettbewerbsanalyse mit  KI-Unterstützung.
• KI für Story-Qualität:  Automatische Prüfung von User Stories auf INVEST-Kriterien, Generierung von Akzeptanzkriterien und Edge Cases, Konsistenz-Check zwischen Features und Stories.
• KI für Stakeholder-Kommunikation:  Release Notes und PI-Reports mit KI-Unterstützung generieren, Business  Context für PI Planning vorbereiten, Sprint Review-Zusammenfassungen  erstellen.
• SAFe CoPilot:  Salesforces KI-Assistent für SAFe-Praktizierende - Framework-Guidance  in Echtzeit, Best-Practice-Empfehlungen, rollenspezifische  Unterstützung.
• Persönlicher KI-Integrationsplan:  Welche der eigenen täglichen PO/PM-Aufgaben profitieren am meisten von  KI? Wo spart KI Zeit? Wo braucht es weiterhin menschliches Urteil?
• Praxis-Übung:  3 eigene PO/PM-Aufgaben mit KI-Unterstützung durchführen: (1) Backlog  auf Duplikate und Inkonsistenzen prüfen, (2) Akzeptanzkriterien für 2  Stories generieren lassen, (3) eine Feature-Benefit-Hypothesis  formulieren und von KI challengen lassen. Ergebnis bewerten:  Zeitersparnis? Qualitätsgewinn?

9. Praxis-Workshop und PrüfungsvorbereitungPhase 1 - Backlog-Hierarchie aufbauen (20 Min):

• Ein Epic in 3 Features zerlegen (mit Benefit Hypothesis und Acceptance Criteria).
• Ein Feature in 5 Stories aufschlüsseln (INVEST, Akzeptanzkriterien).
• WSJF-Priorisierung für alle Features durchführen.

Phase 2 - PI Planning Simulation (20 Min):

• PM: Business Context präsentieren, Feature-Priorisierung vorstellen.
• PO: Team Breakout moderieren - Stories ableiten, PI Objectives formulieren.
• Abhängigkeiten markieren, ROAM-Risiken identifizieren, Confidence Vote.

Phase 3 - KI-Integration und Rollenaktionsplan (10 Min):

• Persönlichen KI-Integrationsplan erstellen: 3 KI-Werkzeuge für den eigenen PO/PM-Alltag.
• Rollenaktionsplan: Was mache ich in den nächsten 30 Tagen konkret anders?

Phase 4 - Prüfungsvorbereitung (40 Min):

• Überblick:  SAFe 6 POPM-Prüfung - Multiple Choice, 90 Minuten, 77 % Passing Score.
• 15  prüfungstypische Fragen gemeinsam durchgehen: PO vs. PM-Abgrenzung,  WSJF-Berechnung, PI Planning-Ablauf, Backlog-Hierarchie, Continuous  Delivery Pipeline.
• Typische  Fallstricke: Verwechslung PO/PM-Verantwortlichkeiten, falsche  WSJF-Interpretation, Committed vs. Uncommitted Objectives.
• Lernressourcen: SAFe Studio, Trailhead-äquivalente Pfade, SAFe CoPilot für Prüfungsvorbereitung.

LernzieleJede teilnehmende Person verlässt das Seminar mit einem klaren Rollenverständnis (PO vs. PM - Verantwortlichkeiten, Zusammenarbeit, Abgrenzung), der Fähigkeit, Backlogs auf zwei Ebenen zu managen (WSJF-Priorisierung, Epic -> Feature -> Story), der Erfahrung eines simulierten PI Planning aus PO/PM-Perspektive, einem persönlichen KI-Integrationsplan für den PO/PM-Alltag und der Vorbereitung auf die POPM-Zertifizierungsprüfung.Zielgruppen

• Product Owner: Die ihre Rolle im SAFe-Kontext verstehen und auf Team-Ebene Backlogs, Iterationen und Stories verantworten.
• Product Manager: Die auf Programm-Ebene die Produktvision definieren, Features priorisieren und das ART steuern.
• Business-Analysten und Solution Manager: Die zwischen Geschäftsstrategie und Teamarbeit übersetzen.
• Programm- und Portfolio-Manager: Die verstehen möchten, wie Produktentscheidungen in SAFe getroffen und umgesetzt werden.
• Alle, die die SAFe 6 Product Owner/Product Manager (POPM)-Zertifizierung anstreben.

Voraussetzungen:  Keine SAFe-Vorkenntnisse zwingend erforderlich. Grundlegendes  Verständnis von Agile/Scrum (User Stories, Backlog, Sprint) ist  hilfreich. Erfahrung in Produktmanagement, Business-Analyse oder einer  PO-Rolle erleichtert den Zugang.Abgrenzung: Dieses Seminar behandelt die taktische Ebene  der PO/PM-Rollen im ART. Wer die strategische Produktmanagement-Ebene  (Roadmap, Marktanalyse, Pricing) vertiefen möchte, findet SAFe Agile  Product Manager APM" (S2697, 3T). Wer SAFe aus Leadership-Perspektive  kennenlernen möchte, findet Leading SAFe 6" (S2490, 2T). Wer die  Scrum-basierte PO-Rolle außerhalb von SAFe vertiefen möchte, findet  Professional Scrum Product Owner PSPO I" (S1958, 2T).