FrankSazamaIch habe schon viele PI-Plannings erlebt.
Manche wirkten wie eine Pflichtübung.
Andere wie ein echtes Gemeinschaftserlebnis – mit Energie, Klarheit und echtem Fortschritt.
Und irgendwann habe ich mich gefragt:
💡 Was macht eigentlich den Unterschied aus?
Heute würde ich sagen:
Es ist nicht das Format, es ist die Haltung.
Und die Art, wie wir die Voraussetzungen gestalten.
Der erste Eindruck: Groß, laut, teuer – und voller Potenzial
Wer zum ersten Mal an einem PI-Planning teilnimmt, ist oft beeindruckt:
100 bis 200 Menschen in einem Raum (oder in einem digitalen Raum), sechs Teams, ein Release Train, viele Rollen, noch mehr Erwartungen.
💬 „So viel Aufwand – kann das überhaupt wertvoll sein?“
Ja, kann es.
Aber nur, wenn wir es systematisch vorbereiten, verantwortungsvoll durchführen – und nicht mit einem reinen Meeting-Format verwechseln.
PI-Planning ist nicht:
✔️ detaillierte Sprint-Planung
✔️ reine Kapazitätsabfrage
✔️ eine Management-Präsentation
PI-Planning ist:
👉 ein mittel- bis langfristiges Commitment auf Teamebene – sichtbar, gemeinsam, überprüfbar.
ABER, ein PI-Planning beginnt mit einem Review
Was oft unterschätzt wird:
Ein PI-Planning beginnt nicht mit dem Blick nach vorn – sondern mit dem Blick zurück.
Der erste Teil des Events ist nicht Planung, sondern Demonstration:
🔎 Was wurde erreicht?
📦 Welche Features sind wirklich fertig – im Sinne der Definition of Done?
✅ Wurde geliefert, was versprochen war?
In der System Demo geht es darum, dass alle Beteiligten – Teams, Stakeholder, Führungskräfte – gemeinsam den Status Quo erkennen.
Nicht durch PowerPoints. Sondern durch sichtbare, getestete, funktionierende Ergebnisse.
Das ist der Ausgangspunkt.
Denn: 🧭 Nur wer weiß, wo er steht, kann sinnvoll planen, wohin er geht.
Voraussetzungen, die ein PI-Planning erst richtig wertvoll machen
Ein PI-Planning wird nicht durch die Agenda wertvoll – sondern durch das, was vorher passiert.
Deshalb spreche ich lieber von Voraussetzungen, nicht nur von „Gestaltungselementen“.
Was macht also ein PI-Planning wirklich wertvoll?
1. Ergebnisse, auf die man aufbauen kann
Ein Event zur Planung funktioniert nur, wenn wir vorher sichtbare Ergebnisse haben.
Das heißt:
- Eine System Demo, die nicht nur zeigt, was getan wurde – sondern ob es fertig ist
- Eine gemeinsam getragene Definition of Done
- Die Fähigkeit, das Review nicht als Show, sondern als Faktenlage zu gestalten
2. Eine Definition of Ready, die diesen Namen verdient
Was soll überhaupt geplant werden?
Nur Elemente, die:
- analysiert und verstanden (Inhalt + Erwartung) wurden
- geschätzt wurden
- Abnahmekriterien haben
- und priorisiert sind
gehören in die PI-Planung.
Fehlt eines dieser Elemente, wird das Event zur Klarheitssuche, nicht zur Planung.
3. Ein agiles System auf Train-Ebene
Ein Release Train braucht eigene Strukturen:
- Ein Chief Product Owner, der das große Bild hält und einen klaren, priorisierten Backlog
- Ein Release Train Engineer, der moderiert und Hindernisse löst
- Ein Architektur-, QA- und Design-Support, der auf Train-Level mitdenkt
- Und ein funktionierendes Agile Team of Teams
(mit regelmäßigem Refinement, Planning, Retrospektive auf Train-Ebene) mit synchronisierten Rollen (CPO, RTE, Architekt:in, QA…) das u.a. das Planning vorbereitet, trägt und auswertet, denn das PI-Planning ist kein Soloakt.
4. Klare Backlogs in abgestimmter Granularität
Ohne ein abgestimmtes Backlog auf Team-, Train- und Lösungsebene ist Planung nur Annahme.
Deshalb braucht es:
- klare Backlog-Strukturen mit verbundenen Roadmaps
- sauber definierte Granularitätsstufen (Modul – Funktion – Feature – Capability)
- eine gemeinsame Vorstellung, wann was sinnvoll planbar ist
5. Ein strukturiertes Event mit Systematik und Raum für Zusammenarbeit
Zwei Tage voller Energie, aber auch Struktur:
- Breakouts mit klaren Zielen
- Zeit für Problemlösung
- Management-Feedback
- Iterationsplanung mit Puffer
- Und: Retrospektive – zur Verbesserung des Prozesses selbst
Vom Pull-Prinzip und der Grenze des Machbaren
Ein besonders wirkungsvoller Teil des PI-Planings ist das Bewusstsein für echte Kapazitäten – und das Prinzip des Pull statt Push.
Ich ermutige Teams:
- realistisch zu planen (z. B. mit 75 % Auslastung statt 100 %)
- Risiken zu identifizieren – und Verantwortliche für deren Klärung zu benennen
- Enabler und Lernbedarfe sichtbar zu machen
Denn:
📉 Überlastung produziert kein Ergebnis – sondern Frust und Verschwendung.
📈 Koordination, Ko-Kreation und Klarheit schaffen Fluss.
Visualisierung, Feedbackschleifen und das „Wir“ in der Skalierung
Was ich bei gutem PI-Planning sehe:
- Boards, auf denen Abhängigkeiten sichtbar werden
- Klar verteilte Verantwortung
- Konstruktives Stakeholder-Feedback
- Mut zur Transparenz – auch bei Risiken
Und vor allem:
➡️ Teams, die sich nicht als Einzelkämpfer, sondern als Teil eines kooperativen Ganzen verstehen.
Denn Kooperation ist der Schlüssel.
Das „Wir“ entscheidet, ob der Release Train Fahrt aufnimmt – oder im Tunnel stecken bleibt.
Fazit: PI-Planning ist kein Termin. Es ist ein Muster.
Wenn wir PI-Planning als Teil eines Systems verstehen – eingebettet in definierte Rollen, vorbereitet durch Backlog-Strukturen, getragen von Klarheit und Haltung –
dann wird daraus mehr als ein zweitägiges Meeting.
Es wird zu einem gemeinsamen Kompass, der Orientierung gibt, Fortschritt ermöglicht und Qualität steuerbar macht.
PI-Planning ist dann nicht teuer. Es ist wertvoll.