PI Planning online durchführen: was in verteilten Sessions wirklich funktioniert

Zwei Tage, ein Raum, alle Teams an der Wand – so war PI Planning gedacht. Für die meisten ARTs ist das seit Jahren nicht mehr die Realität. Teams sitzen in drei Städten, ein Team sitzt beim Dienstleister, zwei Leute sind im Homeoffice. Verteiltes PI Planning ist der Normalfall geworden, nicht die Ausnahme.

Die meisten Ratschläge dazu bleiben aber an der Oberfläche: „Nehmt Miro" oder allgemeine Remote-Meeting-Tipps, die auch für jedes andere Videocall gelten. Die interessantere Frage ist eine andere – was genau geht verloren, wenn der ART nicht in einem Raum sitzt, und womit lässt sich das ersetzen?

Was sich remote wirklich ändert

Drei Dinge verändern sich substanziell – der Rest ist Logistik.

Die Flurgespräche fallen weg. Im Präsenz-Planning entstehen die wertvollsten Erkenntnisse in den Pausen: Jemand geht an einem fremden Team-Board vorbei, sieht ein Feature und sagt „Moment, das braucht doch unsere API". Diese zufälligen Entdeckungen sind kein Nebenprodukt der Ceremony, sie sind ein zentraler Teil davon. Remote passieren sie schlicht nicht mehr. Abhängigkeiten, die sich früher von selbst zeigten, müssen jetzt aktiv gesucht werden.

Die Aufmerksamkeitsspanne halbiert sich. Acht Stunden Videocall sind nicht dasselbe wie acht Stunden in einem Raum. Nach etwa drei Stunden sinkt die Beteiligung messbar – Kameras gehen aus, parallel wird E-Mail gelesen, und die Stillen werden noch stiller. Wer die Präsenz-Agenda unverändert in Zoom überträgt, plant die zweite Hälfte jedes Tages mit halber Mannschaft.

Das Artefakt wird wichtiger als die Diskussion. Im Raum kann man auf ein Board zeigen. Remote existiert der Plan nur, soweit er sichtbar gemacht ist. Ein Foto einer Whiteboard-Wand hilft niemandem, der in der Session nicht dabei war – und schon gar nicht drei Wochen später, wenn sich die Hälfte der Annahmen geändert hat.

Die Vorbereitung entscheidet mehr als die Moderation

Bei verteiltem Planning verschiebt sich das Gewicht deutlich nach vorne. Was im Raum noch spontan geklärt werden konnte, muss remote vorher stehen – sonst verbrennt ihr die knappe gemeinsame Zeit mit Aufräumarbeiten.

Der Ablauf: kürzer, öfter, strikter

Das Muster, das sich in verteilten ARTs am häufigsten bewährt, ist nicht „zwei Tage online" – es ist vier Halbtage statt zwei Ganztage. Vormittags planen, nachmittags arbeiten die Teams in ihren normalen Zeitzonen weiter. Das kostet zwei Kalendertage mehr und rettet die Qualität der zweiten Hälfte.

Was dabei konkret hilft:

• Feste Timeboxes, hart moderiert. Remote ist Überziehen teurer als im Raum, weil die Ermüdung schneller kommt. Ein Timer, der sichtbar läuft, wirkt erstaunlich gut.
• Team-Breakouts in eigenen Calls, mit fester Rückkehrzeit. Nicht „meldet euch, wenn ihr fertig seid" – ein Zeitpunkt, zu dem alle wieder da sind.
• Explizite Abhängigkeitsrunden. Der wichtigste Unterschied zum Präsenz-Planning: Jedes Team stellt sein Draft-Plan-Ergebnis kurz vor und benennt aktiv, was es von wem braucht. Verlasst euch nicht darauf, dass Abhängigkeiten von selbst auftauchen – remote tun sie das nicht.
• Eine Person führt das Gesamtbild. Jemand pflegt während der Session den Programmplan an einer Stelle, die alle sehen. Sonst existieren am Ende sechs Team-Pläne und kein PI-Plan.
• Ein Backchannel für Zwischenrufe. Ein Chat-Kanal, in dem „unser Feature hängt an eurem" jederzeit gesagt werden kann, ohne den Redefluss zu unterbrechen. Das ist der nächstbeste Ersatz für das Flurgespräch.

Werkzeuge – und wo sie aufhören zu helfen

Whiteboard-Tools wie Miro oder Mural bilden die Ceremony gut ab: Sticky Notes, Abhängigkeitsfäden, alle arbeiten gleichzeitig. Für die zwei Tage selbst sind sie eine vernünftige Wahl, und die meisten verteilten ARTs nutzen sie zu Recht.

Ihre Schwäche beginnt danach. Ein Whiteboard kennt eure Kapazitäten nicht, rechnet nichts nach und hat keine Verbindung zu euren Jira-Daten. Verschiebt sich ein Feature um zwei Sprints, sagt euch niemand, welche Sprints dadurch überlaufen – ihr müsst es selbst nachhalten. Und weil das mühsam ist, passiert es meistens nicht: Der Plan bleibt in dem Zustand, in dem die Session endete, und veraltet ab Tag drei.

Genau hier trennt sich das Werkzeug für die Ceremony vom Werkzeug für den Plan. Für die Ceremony braucht ihr eine gemeinsame Fläche. Für den Plan braucht ihr etwas, das Kapazitäten kennt, Abhängigkeiten abbildet und sich aktualisieren lässt, ohne dass jemand 40 Sticky Notes von Hand verschiebt. Welche Optionen es dafür gibt, haben wir im Vergleich der Advanced-Roadmaps-Alternativen aufgeschrieben.

Nach dem Planning: der Plan muss die Session überleben

Das ist der Punkt, an dem verteiltes PI Planning am häufigsten scheitert – und er hat nichts mehr mit der Ceremony zu tun.

Im Präsenz-Setup hängt das Program Board an einer Wand, an der jeden Tag Leute vorbeilaufen. Remote gibt es diese Wand nicht. Wenn der Plan als Screenshot in einem Confluence-Artikel endet, schaut ihn nach der ersten Woche niemand mehr an, und beim nächsten PI Planning startet ihr wieder bei null.

Was dagegen hilft, ist unspektakulär: Der Plan muss ein Format haben, das sich ändern lässt und teilbar bleibt. Wenn im Sprint Review klar wird, dass ein Feature zwei Sprints später landet, sollte die Anpassung Minuten dauern und die Folgen für die anderen Teams sichtbar machen – nicht eine halbe Stunde Handarbeit in einer Tabelle kosten.

Fazit

Verteiltes PI Planning funktioniert – aber nicht, indem man die Präsenz-Agenda in ein Videotool kopiert. Die drei Hebel, die den Unterschied machen, sind: die Vorbereitung nach vorne ziehen, damit die gemeinsame Zeit fürs Planen bleibt; die Tage kürzen und Abhängigkeiten aktiv abfragen, statt auf ihre spontane Entdeckung zu hoffen; und einen Plan erzeugen, der die Session überlebt.

Das Werkzeug für die Ceremony und das Werkzeug für den Plan dürfen dabei ruhig verschiedene sein. Nur sollte man sich nicht darauf verlassen, dass ein Whiteboard beides leistet.