PI Planning im SAFe: Wenn 100+ Menschen gleichzeitig planen
Das Scaled Agile Framework (SAFe) ist mit 37% Marktanteil das meistgenutzte Framework für agile Skalierung (State of Agile 2024). PI Planning steht im Zentrum dieses Frameworks – es synchronisiert Teams, macht Abhängigkeiten sichtbar und erzeugt ein gemeinsames Commitment auf ART-Ebene.
Was ist PI Planning und warum zwei Tage?
Program Increment (PI) Planning ist ein regelmäßiges, face-to-face Event, bei dem alle Teams eines Agile Release Train gemeinsam Ziele für das nächste Program Increment festlegen, Abhängigkeiten identifizieren und Risiken adressieren. Ein PI umfasst typischerweise 4–6 Sprints, also 8–12 Wochen Arbeit.
Die zwei Tage sind keine Empfehlung, sondern Notwendigkeit. Am ersten Tag entstehen erste Pläne. Über Nacht werden diese reflektiert. Am zweiten Tag werden Pläne angepasst und finalisiert. Dieser Rhythmus ermöglicht:
- Verarbeitung komplexer Informationen
- Informelle Gespräche zwischen den Sessions
- Zeit für Problemlösung bei Abhängigkeitskonflikten
- Echtes Commitment statt überhasteter Zusagen
Der Ablauf: Tag 1 und Tag 2 im Detail
| Zeitblock | Tag 1 | Tag 2 |
|---|---|---|
| 08:00–09:00 | Business Context & Vision | Planning Adjustments |
| 09:00–12:00 | Team Breakouts #1 | Team Breakouts #3 |
| 12:00–13:00 | Mittagspause | Mittagspause |
| 13:00–14:00 | Draft Plan Review | Final Plan Review |
| 14:00–17:00 | Team Breakouts #2 | Management Review & Problem Solving |
| 17:00–18:00 | Management Review | Confidence Vote & Retrospektive |
Tag 1: Vom Big Picture zum Draft Plan
Der erste Tag beginnt mit dem Business Context – Führungskräfte erklären, warum dieses PI wichtig ist und welche strategischen Ziele verfolgt werden. Ohne diesen Kontext planen Teams im Vakuum. Die Vision gibt Orientierung für Priorisierungsentscheidungen.
Nach dem Business Context präsentiert der Product Manager die Roadmap und priorisierte Features. Das ist der Input für die Team-Breakouts. In diesen Breakouts planen die einzelnen Scrum-Teams ihre Sprints, identifizieren Abhängigkeiten und erstellen erste Commitments.
Die Team-Breakouts sind das Herz des PI Plannings. Hier passiert die eigentliche Arbeit. Product Owner und Teams diskutieren Features, zerlegen sie in Stories und schätzen den Aufwand. Am Ende von Tag 1 hat jedes Team einen Draft Plan – noch nicht finalisiert, aber konkret genug für das Review.
Die Program Board: Abhängigkeiten sichtbar machen
Das Program Board ist das zentrale Artefakt des PI Plannings – eine physische oder digitale Visualisierung aller Features, Meilensteine und Abhängigkeiten über alle Sprints des PIs. Rote Fäden zwischen Sticky Notes zeigen Abhängigkeiten zwischen Teams.
Die Macht des Program Boards liegt in der Sichtbarkeit. Wenn 100 Menschen auf dasselbe Board schauen, werden Konflikte offensichtlich. „Team A braucht API von Team B in Sprint 2, aber Team B plant die API für Sprint 3" – solche Konflikte werden sofort adressiert.
In Remote-Settings nutzen Teams digitale Boards wie Miro oder das SAFe-spezifische Tool von Planview. Die Prinzipien bleiben gleich: Alles muss für alle sichtbar sein.
Tag 2: Vom Draft zum Commitment
Am zweiten Tag werden die Draft-Pläne überarbeitet. Teams haben über Nacht nachgedacht, informelle Gespräche geführt und Probleme identifiziert. Die Breakouts am Morgen dienen der Anpassung und Finalisierung.
Das Final Plan Review ist der Moment der Wahrheit. Jedes Team präsentiert seinen Plan, sein Commitment und seine Risiken. Die anderen Teams hören zu, stellen Fragen und validieren Abhängigkeiten. Dieser Prozess dauert – bei 10 Teams mindestens 2–3 Stunden – ist aber unverzichtbar für echte Synchronisation.
Der Confidence Vote: Mehr als Daumen hoch
Am Ende des PI Plannings stimmt jedes Teammitglied über sein Vertrauen in den Plan ab. Die Skala reicht von 1 (kein Vertrauen) bis 5 (volles Vertrauen). Ein Durchschnitt unter 3 bedeutet: Der Plan ist nicht tragfähig und muss überarbeitet werden.
Der Confidence Vote ist kein demokratisches Ritual, sondern ein Risiko-Indikator. Wenn 20% der Teilnehmer mit 1 oder 2 stimmen, gibt es ein Problem – auch wenn der Durchschnitt bei 3,5 liegt. Diese Stimmen müssen gehört werden.
Ich habe PI Plannings erlebt, bei denen der erste Vote bei 2,8 lag. Das Management wollte weitermachen. Der Release Train Engineer bestand auf einer zusätzlichen Problem-Solving-Session. Nach zwei Stunden stieg der Vote auf 3,6. Diese zwei Stunden verhinderten einen gescheiterten PI.
Laut SAFe-Daten erreichen ARTs mit Confidence Votes über 3,5 ihre PI-Objectives in 78% der Fälle, verglichen mit nur 49% bei Votes unter 3,0.
Rollen im PI Planning: Wer macht was?
| Rolle | Hauptaufgabe | Präsenz |
|---|---|---|
| Release Train Engineer | Facilitiert das gesamte Event | Beide Tage, durchgehend |
| Product Management | Vision, Roadmap, Feature-Priorisierung | Beide Tage, durchgehend |
| Business Owner | Business Context, Priorisierungsentscheidungen | Tag 1 Morgen, beide Finalreviews |
| System Architect | Technische Guidance, Architektur-Entscheidungen | Beide Tage, verfügbar |
| Scrum Master | Facilitiert Team-Breakouts | Beide Tage, im Team |
| Product Owner | Feature-Details, Akzeptanzkriterien | Beide Tage, im Team |
| Entwickler | Planung, Schätzung, Commitment | Beide Tage, im Team |
Der Release Train Engineer als Zeremonienmeister
Der RTE orchestriert das gesamte Event – er hält die Timebox, moderiert die Reviews, eskaliert ungelöste Konflikte und sorgt dafür, dass der Confidence Vote ehrlich stattfindet. Ein guter RTE ist der Unterschied zwischen produktivem PI Planning und Chaos.
Der RTE bereitet das Event wochenlang vor: Agenda finalisieren, Raum organisieren, Materialien beschaffen, Pre-Planning mit Product Management durchführen. Während des Events ist er der ruhige Pol, der das Big Picture im Blick behält, während alle anderen in Details versinken.
Raumanforderungen: Logistik für 100+ Menschen
PI Planning vor Ort erfordert einen Raum, der groß genug für alle Teilnehmer ist, plus separate Bereiche für Team-Breakouts. Die Logistik ist komplex und wird häufig unterschätzt.
Raumaufteilung
- Main Room: Alle Teilnehmer für Plenarsessions (Präsentationen, Reviews)
- Breakout-Bereiche: Jedes Team braucht eigenen Bereich mit Tischen, Whiteboards, Flipcharts
- Program Board Area: Zentraler, für alle sichtbarer Bereich für das Program Board
- Informeller Bereich: Kaffee-Ecken für spontane Gespräche
Material-Checkliste
- Sticky Notes in verschiedenen Farben (Tausende davon)
- Marker in ausreichender Menge
- Rotes Garn oder Band für Abhängigkeiten
- Große Papierbögen für Team-Boards
- Beamer und Mikrofone für den Hauptraum
- WLAN mit ausreichender Bandbreite
- Verpflegung (unterschätze nie die Macht guten Kaffees)
Typische Stolperfallen und wie man sie vermeidet
Stolperfalle 1: Unvorbereitetes Product Management
Wenn Features nicht ausreichend beschrieben sind, verbringen Teams die Breakouts mit Requirements-Klärung statt mit Planung. Das verschwendet Zeit und frustriert alle Beteiligten.
Lösung: Pre-PI Planning 2–4 Wochen vorher. Product Management, System Architects und Business Owner klären Features und Architektur-Runway vor dem Event.
Stolperfalle 2: Zu optimistische Pläne
Teams neigen dazu, mehr zu committen als realistisch. Der Druck von Business Ownern verstärkt das.
Lösung: Historische Velocity als Planungsgrundlage nutzen. Teams dürfen nicht über ihre bewiesene Kapazität committen. Der RTE schützt Teams vor unrealistischen Erwartungen.
Stolperfalle 3: Ignorierte Abhängigkeiten
Abhängigkeiten werden identifiziert, aber nicht gelöst. „Das klären wir später" ist der Anfang vom Ende.
Lösung: Ungelöste Abhängigkeiten sind ROAM-Kategorien (Resolved, Owned, Accepted, Mitigated). Jede Abhängigkeit braucht einen Owner und einen Lösungsplan vor Ende des PI Plannings.
Stolperfalle 4: Fehlende Business Owner
Ohne Business Owner fehlen Priorisierungsentscheidungen, wenn Kapazität und Wünsche kollidieren. Teams planen an der Realität vorbei.
Lösung: Business Owner-Teilnahme ist Pflicht, nicht optional. Mindestens ein Business Owner muss für Eskalationen verfügbar sein – durchgehend, nicht nur zu den Präsentationen.
Remote PI Planning: Die neue Normalität
Seit 2020 führen viele Organisationen PI Planning remote oder hybrid durch. Das funktioniert, erfordert aber andere Vorbereitung und intensivere Moderation. Die Energie eines physischen Events lässt sich nicht vollständig replizieren, aber die Ergebnisse können gleichwertig sein.
Technologie-Stack für Remote PI Planning
- Videokonferenz: Zoom, Teams oder Webex mit Breakout-Rooms
- Digitales Board: Miro, Mural oder Lucidspark
- SAFe-spezifisch: Planview (ehemals Leankit), Jira Align, Digital.ai
- Chat: Slack oder Teams für asynchrone Kommunikation
- Zeitmanagement: Sichtbare Timer, die für alle gleich sind
Besonderheiten bei Remote
- Kürzere Sessions: Maximale Konzentration online ist 90 Minuten. Mehr Pausen einplanen.
- Explizitere Kommunikation: Nonverbale Signale fehlen. Facilitatoren müssen aktiver nachfragen.
- Technische Checks: 30 Minuten vor jeder Session für Tech-Support reservieren.
- Energie-Management: Icebreaker, Bewegungspausen, Kameras an.
Eine Studie von Scaled Agile Inc. aus 2024 zeigt: 89% der Remote PI Plannings erreichen vergleichbare Ergebnisse wie Vor-Ort-Events, wenn die Vorbereitung stimmt. Der Schlüssel liegt in der Disziplin.
Nach dem PI Planning: Die ersten Tage
PI Planning ist nicht vorbei, wenn der Confidence Vote abgeschlossen ist. Die ersten Tage nach dem Event entscheiden, ob die Pläne Realität werden. Der RTE und die Scrum Master müssen den Schwung nutzen.
Sofortige Follow-ups
- Program Board digitalisieren: Falls noch nicht geschehen, alle Abhängigkeiten ins Tool übertragen
- Risiken tracken: ROAM-Status täglich updaten
- Erste Sprint Plannings: Innerhalb der ersten Woche, basierend auf PI-Plänen
- Stakeholder-Kommunikation: PI Objectives an alle Interessierten kommunizieren
Metriken: PI-Planning-Erfolg messen
| Metrik | Zielwert | Bedeutung |
|---|---|---|
| Confidence Vote | ≥ 3,5 | Team-Vertrauen in den Plan |
| PI Predictability | ≥ 80% | Anteil erreichter PI Objectives |
| Unresolved Dependencies | 0 am Ende | Alle Abhängigkeiten sind ROAM-kategorisiert |
| Business Value Delivered | Steigend | Wert pro PI |
| Team Satisfaction | ≥ 4/5 | Feedback zum Event selbst |
PI Predictability ist die wichtigste Langzeit-Metrik. ARTs, die ihre Objectives konsistent erreichen, bauen Vertrauen bei Stakeholdern auf – das wichtigste Kapital in agilen Transformationen.
Fazit: PI Planning als Investment in Alignment
PI Planning ist aufwändig. Zwei Tage, 100+ Menschen, erhebliche Kosten. Aber der Return ist enorm: Alignment über Teams hinweg, sichtbare Abhängigkeiten, gemeinsames Commitment.
Organisationen, die PI Planning ernst nehmen, berichten von 40% weniger Koordinationsaufwand während des PIs und 60% höherer Vorhersagbarkeit (SAFe Business Agility Report 2024). Das rechtfertigt jede investierte Stunde.
PI Planning ist kein Meeting. Es ist das Event, das einen ART zum ART macht – eine Gruppe von Teams, die gemeinsam mehr erreichen als die Summe ihrer Teile.
Wie oft findet PI Planning statt?
PI Planning findet zu Beginn jedes Program Increments statt – typischerweise alle 8–12 Wochen. Bei 5 Sprints à 2 Wochen ist das alle 10 Wochen. Manche Organisationen planen quartalsweise.
Was passiert, wenn der Confidence Vote unter 3 liegt?
Ein Vote unter 3 bedeutet: Der Plan ist nicht tragfähig. Das Team muss in eine zusätzliche Problem-Solving-Session. Typische Ursachen: unrealistische Erwartungen, ungelöste Abhängigkeiten, unklare Anforderungen. Erst wenn die Ursachen adressiert sind, wird erneut abgestimmt.
Müssen wirklich alle Teammitglieder teilnehmen?
Ja. PI Planning funktioniert nur, wenn die Menschen, die die Arbeit machen, auch die Planung machen. Vertreter-Modelle („Einer pro Team") untergraben das Commitment. Die Kosten für volle Teilnahme sind niedriger als die Kosten für mangelnde Abstimmung.
Wie bereiten sich Teams auf PI Planning vor?
Teams sollten ihr lokales Backlog refiniert haben. Der Product Owner kennt die priorisierten Features. Die Velocity der letzten PIs ist dokumentiert. Technische Fragen zur Architektur sind vorab geklärt. Pre-PI Planning mit Product Management und System Architects hilft dabei.
Kann PI Planning auch ohne SAFe funktionieren?
Die Grundidee – alle Teams planen gleichzeitig und synchronisieren sich – funktioniert auch außerhalb von SAFe. Die Struktur und Terminologie stammt aus SAFe, aber andere skalierte Frameworks wie LeSS oder Nexus haben ähnliche Konzepte. Das Prinzip ist universell.
Stand: Dezember 2025
Quellen: SAFe 6.0 Framework, Scaled Agile Inc. State of Agile Report 2024, Digital.ai SAFe Implementation Survey 2024 SAFe Business Agility Report 2024
