Wissen
Zwei Tage, in denen alle Teams gemeinsam festlegen, was in den nächsten drei Monaten tatsächlich gebaut wird.
Diese Seite erklärt, was ein PI Planning ist, wer daran teilnimmt, wie die beiden Tage ablaufen und woran es in der Praxis scheitert. Sie ist aus der Moderation solcher Veranstaltungen geschrieben, nicht aus dem Lehrbuch — inklusive der Frage, wann sich externe Moderation lohnt und wann nicht.
Ein PI Planning ist die Planungsveranstaltung, in der alle Teams eines Agile Release Train gemeinsam den Arbeitsumfang für das nächste Planning Interval festlegen. Es dauert in der Regel zwei Tage und findet alle rund zwölf Wochen statt, in vielen Organisationen quartalsweise.
Der entscheidende Unterschied zu jeder anderen Planungsrunde: Die Teams planen nicht nacheinander und nicht getrennt, sondern gleichzeitig und im selben Raum. Abhängigkeiten zwischen Teams werden dort sichtbar, wo sie entstehen — und nicht sechs Wochen später im Statusbericht.
Weil im PI Planning der Scope aller Teams für ein Quartal festgelegt wird, werden dort faktisch erhebliche Geschäftsentscheidungen getroffen. Das ist der Grund, warum die Veranstaltung mehr Aufmerksamkeit verdient, als sie in vielen Organisationen bekommt: Sie ist kein Termin im Kalender, sie ist das Nadelöhr der agilen Planung.
PI Planning wird auch Big-Room-Planning oder Quartalsplanung genannt. „PI“ stand ursprünglich für Program Increment; seit SAFe 6.0 heißt der Zeitraum Planning Interval. Die Abkürzung ist geblieben.
Ein Planning Interval ist der Zeitraum, den ein PI Planning plant: in der Regel rund drei Monate, aufgeteilt in mehrere Sprints von je zwei bis vier Wochen. Am Ende des Intervalls beginnt der Zyklus mit dem nächsten PI Planning von vorn.
Bis SAFe 5 hieß dieser Zeitraum Program Increment. Mit SAFe 6.0 wurde er in Planning Interval umbenannt, weil „Increment“ ein Ergebnis beschreibt und nicht die Zeitspanne, um die es hier geht. In vielen Unternehmen sind beide Begriffe weiterhin parallel im Umlauf — gemeint ist dasselbe.
Ein PI Planning bringt alle zusammen, die für die Planung des nächsten Intervalls gebraucht werden. Die Größe schwankt entsprechend: von rund fünfzig Personen bei einem kleinen Train bis zu mehreren hundert bei großen Organisationen.
| Rolle | Aufgabe im PI Planning |
|---|---|
| Die Teams | Planen ihre Arbeit selbst — vollständig anwesend, nicht durch Vertretungen. |
| Product Owner und Product Management | Bringen die Priorisierung mit und beantworten die Fragen, die beim Aufschneiden der Arbeit entstehen. |
| Scrum Master | Moderieren die Arbeit im eigenen Team, halten den Zeitrahmen und tragen Abhängigkeiten nach außen. |
| Release Train Engineer | Führt den Train durch das Intervall — im Planning zugleich Gastgeber und Moderator. |
| Business Owner und Stakeholder | Geben den Geschäftskontext und bewerten am Ende die Pläne. |
| Systemarchitektur und Management | Setzen die technischen Leitplanken und lösen Hindernisse, die kein Team allein auflösen kann. |
Zwei Punkte entscheiden über die Qualität der Runde. Erstens: Wer plant, muss die Arbeit später auch machen — delegierte Planung hält selten bis zum Ende des Intervalls. Zweitens: Der RTE ist an diesen zwei Tagen Gastgeber und Moderator zugleich. Genau diese Doppelbelastung lässt sich auslagern, und ohne entscheidungsbefugte Business Owner im Raum fehlt dem Planning am Ende die Verbindlichkeit.
Wer nicht vor Ort sein kann, wird zugeschaltet. Das funktioniert — aber nur, wenn die Remote-Teilnahme von Anfang an geplant ist und nicht am Morgen des ersten Tages improvisiert wird. Eine Kamera im Raum reicht dafür nicht.
Der Ablauf folgt einem eingespielten Muster: erst der gemeinsame Kontext, dann die Planung in den Teams, dann die Abstimmung zwischen den Teams und zum Abschluss ein gemeinsames Commitment von Teams und Management.
Der Vormittag gehört dem gemeinsamen Bild: Wo steht das Geschäft, was ist die Produktvision, welche technischen Leitplanken gelten, wie wird geplant. Am Nachmittag ziehen sich die Teams zurück und erarbeiten ihren ersten Planentwurf. Der Tag endet mit einer Durchsicht dieser Entwürfe und mit dem Management, das die aufgetauchten Probleme aufnimmt und über Nacht Entscheidungen vorbereitet.
Der zweite Tag beginnt mit den Anpassungen, die sich aus dem Vorabend ergeben haben. Danach planen die Teams weiter, stellen ihre finalen Pläne vor und benennen die Risiken, die sie sehen. Zum Schluss stimmen alle ab, wie zuversichtlich sie den Plan halten. Fällt das Ergebnis zu niedrig aus, wird nachgearbeitet — nicht beschönigt.
| Agendapunkt | Was darin passiert |
|---|---|
| Tag 1 · Business Context | Die Geschäftsseite zeigt, wo das Unternehmen steht und was im kommenden Intervall zählt. |
| Tag 1 · Product / Solution Vision | Product Management stellt die nächsten Prioritäten und die anstehenden Features vor. |
| Tag 1 · Architecture Vision | Die Systemarchitektur benennt die technischen Leitplanken und die Umbauten, die anstehen. |
| Tag 1 · Planning Context | Der Release Train Engineer erklärt den Ablauf: Zeitplan, Kapazitäten, erwartete Ergebnisse. |
| Tag 1 · Team Breakouts | Die Teams planen ihre Arbeit selbst, schätzen ihre Kapazität und benennen Abhängigkeiten. |
| Tag 1 · Draft Plan Review | Jedes Team stellt seinen Entwurf vor — Ziele, Abhängigkeiten und die Risiken, die es sieht. |
| Tag 1 · Management Review & Problem Solving | Das Management nimmt die aufgetauchten Probleme auf und bereitet über Nacht Entscheidungen vor. |
| Tag 2 · Planning Adjustments | Die Entscheidungen des Vorabends werden vorgestellt: geänderter Scope, Prioritäten, Kapazitäten. |
| Tag 2 · Team Breakouts | Zweite Runde: Die Teams arbeiten ihre Pläne auf Basis der Anpassungen fertig. |
| Tag 2 · Final Plan Review | Die finalen Pläne werden vorgestellt und von den Business Ownern bewertet. |
| Tag 2 · ART Risks | Die verbleibenden Risiken werden offen benannt und jeweils einer Person zugeordnet. |
| Tag 2 · Confidence Vote | Alle stimmen ab, wie zuversichtlich sie den gemeinsamen Plan halten. |
| Tag 2 · Plan Rework | Fällt die Abstimmung zu niedrig aus, wird nachgearbeitet — nicht beschönigt. |
| Tag 2 · Planning Retro & Moving Forward | Kurze Retrospektive auf die Veranstaltung, dann die nächsten Schritte für das Intervall. |
Dieselbe Agenda, erweitert um einen optionalen Vortag für Anreise, Team Building oder ein Training, steht auf der Startseite unter Erweiterte PI Planning Agenda.
Wenn ohnehin alle anreisen, ist der Abend vorher die günstigste Gelegenheit für Team Building, ein Training oder eine Firmenfeier, die es sonst nie gibt. Eine Anreise, zwei Ergebnisse — die Reisekosten fallen ohnehin an.
Ein PI Planning wird nicht in den zwei Tagen gewonnen, sondern in den Wochen davor. Was am Veranstaltungstag improvisiert werden muss, kostet Planungszeit, die den Teams dann fehlt.
Geschäftskontext, Produktvision und Priorisierung sind vor dem Planning abgestimmt — nicht Gegenstand des Plannings. Wer den Scope erst im Raum verhandelt, verliert den ersten Tag.
Die Arbeit muss so vorbereitet sein, dass Teams sie in Sprints aufteilen können. Grobe Themen ohne erkennbaren Umfang blockieren die Breakouts.
Vollständige Teams, entscheidungsbefugte Business Owner, verfügbare Architektur. Eine Zusage „falls nichts dazwischenkommt“ ist keine Zusage.
Raum, Technik, Verpflegung, Anreise, Unterkunft und die Remote-Zuschaltung. Das klingt nach Nebensache und entscheidet trotzdem darüber, ob am Nachmittag noch jemand aufnahmefähig ist.
Die Muster wiederholen sich über Organisationen hinweg. Keines davon ist ein Planungsfehler der Teams — alle entstehen davor oder daneben.
Wenn Stakeholder das Planning nutzen, um Prioritäten neu zu diskutieren, planen die Teams gegen ein bewegliches Ziel. Erkennbar daran, dass der erste Tag ohne belastbaren Entwurf endet.
Probleme, die das Management lösen müsste, wandern in eine Liste statt in eine Entscheidung. Erkennbar daran, dass dieselben Punkte im nächsten Planning wieder auftauchen.
Wird niedrige Zuversicht zur Kenntnis genommen statt bearbeitet, lernen alle, dass die Abstimmung folgenlos ist. Danach stimmt niemand mehr ehrlich ab.
Teams planen nebeneinander statt miteinander. Erkennbar daran, dass die Abhängigkeiten erst im Sprint auffallen — dann, wenn sie teuer sind.
Wer gleichzeitig den Train führt, den Ablauf moderiert, die Technik betreut und inhaltlich mitentscheidet, macht nichts davon gut. Das ist die häufigste und die am leichtesten behebbare Ursache.
Zugeschaltete Teilnehmende ohne eigene Moderation, ohne funktionierenden Ton und ohne Zugriff auf dieselben Artefakte sind faktisch nicht Teil der Planung — sie sind Zuschauende.
Nicht jedes PI Planning braucht Moderation von außen. Die ehrliche Antwort hängt davon ab, woran es gerade hakt.
… der Release Train Engineer moderiert und gleichzeitig inhaltlich gebraucht wird. … das erste PI Planning einer Organisation ansteht und niemand Erfahrung mit dem Format hat. … die Logistik den Aufwand treibt, weil hunderte Menschen anreisen, untergebracht und verpflegt werden müssen. … die letzten Plannings inhaltlich in Ordnung waren, aber als anstrengend und ergebnisarm erlebt wurden. … eine neutrale Person nötig ist, weil zwischen Bereichen Konflikte im Raum stehen.
… das Planning gut läuft und der RTE genug Luft hat. Dann kostet externe Moderation Geld und bringt nichts. … das eigentliche Problem vor dem Planning liegt: unklare Priorisierung, ein unvorbereitetes Backlog, fehlende Entscheidungsbefugnis. Moderation macht diese Probleme sichtbar, sie löst sie nicht. … die Organisation noch gar keinen Agile Release Train hat. Dann ist die Frage nicht die Moderation, sondern der Zuschnitt der Teams.
Der zweite Fall ist der häufigere. Wer unsicher ist, in welchem er steckt, klärt das in einem Gespräch schneller als in einem Angebot.
Klassisch zwei Tage. Mit einem vorgeschalteten Tag für Anreise, Team Building oder Training werden daraus drei. Kürzer als zwei Tage funktioniert selten: Der zweite Tag existiert, damit Teams auf die Probleme des ersten reagieren können.
Alle rund zwölf Wochen, in vielen Organisationen im Quartalsrhythmus — jeweils zu Beginn eines neuen Planning Intervals.
So viele, wie zum Train gehören. Häufig zwischen fünfzig und zweihundert Personen; große Organisationen planen auch mit mehreren Trains parallel.
Ja, aber es ist die schwierigere Variante. Remote funktioniert, wenn die Moderation darauf ausgelegt ist, jedes Team eine eigene Moderation hat und alle mit denselben Artefakten arbeiten. Als Sparmaßnahme gedacht, funktioniert es meistens nicht — der Wert der Veranstaltung liegt zu einem großen Teil in den Gesprächen zwischen den Sitzungen.
Nein. Das Format stammt aus SAFe und trägt dessen Vokabular, aber die Grundidee — alle Teams planen gemeinsam für denselben Zeitraum — funktioniert auch in Organisationen, die ein anderes skaliertes Framework nutzen oder gar keines.
Es ist derselbe Zeitraum unter zwei Namen. SAFe 6.0 hat Program Increment in Planning Interval umbenannt. Die Abkürzung PI blieb erhalten, weshalb die Veranstaltung weiterhin PI Planning heißt.
Diese Seite ist aus der Praxis geschrieben: von Oktober 2023 bis Oktober 2024 vierteljährliche PI Plannings für rund 180 Personen der Digital Business Unit der KION AG, dazu die Begleitung agiler Transformationen — aktuell bei einer Bundesbehörde im Rahmen eines IT-Systemhaus-Mandats.
Wer die Moderation, die Vorbereitung oder die gesamte Organisation abgeben möchte, findet die buchbaren Leistungen auf der Startseite unter PI Planning as a Service — von der reinen Moderation über Location bis zur vollständigen Reise- und Verpflegungsorganisation.