Rolling Wave Planning im Alltag eines Product Owners
Hinweis: Dieser Artikel ist ein vertiefendes Praxisbeispiel. Die theoretischen Grundlagen findest du im Basis-Artikel Rolling Wave Planning: Realistisch planen, führen und Risiken bewusst nutzen.
Rolling Wave Planning scheitert selten am Verständnis. Es scheitert daran, dass es uns zwingt, Dinge bewusst nicht zu entscheiden, obwohl genau das von uns erwartet wird.
Im Alltag eines Product Owners ist das unbequem. Und genau deshalb ist es so wirksam.
Abbildung: Die drei Planungshorizonte und ihr Fokus: Von strategischer Richtung zu konkreter Lieferung.
Ein konkretes Beispiel macht das greifbar.
Der Produktkontext: Ein Problem, das jeder kennt
Wir entwickeln mehrere Desktop-Programme für Endanwender. Fehler passieren. Regelmäßig.
Die Realität:
- Support-Tickets sind unstrukturiert und schwer vergleichbar
- Entwickler erfahren von kritischen Fehlern oft erst spät
- Priorisierung basiert mehr auf Lautstärke als auf Daten
Irgendwann fällt der Satz:
„Wir brauchen endlich einen Error Tracker.“
Ein klassisches Thema. Und ein idealer Kandidat für Rolling Wave Planning.
Later: Richtung festlegen, ohne Lösungen zu versprechen
Im Later-Horizont geht es nicht um Features. Es geht um Problemräume, Ziele und Risiken.
Bewusst grobe Formulierung
Thema: Transparenter Umgang mit Laufzeitfehlern in unseren Programmen Ziel: Fehler schneller erkennen, priorisieren und systematisch beheben Nicht-Ziel: vollständiges Monitoring oder User-Analytics
Allein diese Abgrenzung ist eine Führungsentscheidung.
Was wir hier explizit nicht entscheiden
- kein Tool
- keine Architektur
- keine Aussage zur Nutzerkommunikation
Und genau hier entsteht Spannung.
Stakeholder fragen:
„Aber könnt ihr wenigstens sagen, was das am Ende kostet?“
Die ehrliche Antwort lautet:
„Noch nicht, ohne uns selbst zu belügen.“
Typische Leitfragen im Later-Horizont
- Welches Risiko entsteht, wenn wir nichts tun?
- Welche Annahmen sind implizit bereits gesetzt?
- Welche Constraints gelten unabhängig von der Lösung?
Beispielhafte Constraints:
- Datenschutz: keine personenbezogenen Daten
- Performance: kein spürbarer Einfluss auf Startzeit
- Support: Auswertung muss ohne Entwickler möglich sein
👉 Ergebnis: Richtung ja, Scheinsicherheit nein
Next: Strukturierte Unschärfe und bewusstes Lernen
Im Next-Horizont wird es konkret, aber noch nicht verbindlich. Hier arbeiten wir mit Reifegraden von Informationen, nicht mit Zusagen.
Hypothesen statt Wahrheiten
- Ein kleiner Teil der Fehler verursacht den Großteil der Supportanfragen
- Aggregierte Stacktraces helfen Entwicklern schneller als Einzelfälle
- Nutzer akzeptieren Fehlerberichte, wenn wir transparent sind
Diese Aussagen sind Hypothesen, keine Fakten.
Die zentrale Entscheidung in dieser Phase
Nicht was wir bauen, sondern:
Welche Annahme wir zuerst riskieren.
Im Beispiel entscheiden wir uns bewusst für einen ersten, begrenzten Schritt:
- Wir sammeln zunächst nur interne Fehlerdaten
- Keine Nutzerkommunikation
- Kein UI
- Kein Opt-in-Flow
Warum?
Weil wir zuerst verstehen müssen:
- ob die Daten überhaupt handhabbar sind
- ob sie echten Mehrwert für Entwicklung und Support liefern
👉 Ergebnis: Lernen vor Lieferung
Wann wird aus Next eigentlich Now?
Rolling Wave Planning ist kein statischer Zustand. Die Wellen bewegen sich.
Ein Thema rückt von Next zu Now, wenn:
- zentrale Annahmen ausreichend validiert sind
- relevante Risiken verstanden wurden
- die verbleibende Unsicherheit bewusst akzeptiert werden kann
Im Error-Tracker-Beispiel ist das der Moment, in dem:
- klar ist, dass die Daten stabil ankommen
- Support und Entwicklung echten Nutzen sehen
- keine kritischen Constraints verletzt werden
Erst dann entsteht echte Lieferfähigkeit.
Now: Verlässlichkeit herstellen, ohne Lernen zu beenden
Im Now-Horizont endet die Offenheit für den Scope, nicht für Erkenntnis. Hier wird geliefert, aber Lernen hört nicht auf.
Klar geschnittener Scope
- Fehler werden lokal gesammelt
- anonymisiert an einen Server übertragen
- nach Fehlertyp und Version aggregiert
Entscheidungen, die jetzt feststehen müssen
- erlaubte Datenfelder
- technische Umsetzung
- Abnahmekriterien
Ebenso wichtig: Was explizit nicht Teil dieses Inkrements ist.
Zum Beispiel:
- kein UI für Endnutzer
- keine automatische Priorisierung
- keine Korrelation mit User-Aktionen
Diese Klarheit schafft Verlässlichkeit. Neue Erkenntnisse aus der Umsetzung fließen jedoch zurück in Next oder Later und beeinflussen dort kommende Entscheidungen.
👉 Ergebnis: Lieferfähigkeit mit aktivem Feedback-Loop
Rolling Wave Planning ist kein Backlog-Refinement
Ein häufiger Einwand lautet:
„Das ist doch einfach ein gut gepflegtes Backlog.“
Der Unterschied ist grundlegend.
Rolling Wave Planning beeinflusst nicht nur die Reihenfolge von Tickets, sondern:
- Planungssicherheit über Zeit
- Erwartungen zu Budget und Timeline
- den bewussten Umgang mit Risiko auf Produkt- und Portfolio-Ebene
Es geht nicht um bessere Tickets. Es geht um bessere Entscheidungen zur richtigen Zeit.
Die Kadenz: Wie Rolling Waves im Alltag leben
Rolling Waves funktionieren nur mit Regelmäßigkeit.
Ein pragmatisches Setup:
- Now: kontinuierlich, sprintnah
- Next: monatlicher Review von Annahmen und Risiken
- Later: quartalsweiser Blick auf Richtung, Ziele und Constraints
Wichtig ist nicht die exakte Frequenz, sondern:
Dass die Wellen aktiv betrachtet und bewusst bewegt werden.
Typische Anti-Patterns, die früh sichtbar werden
- Later enthält bereits implizite Feature-Zusagen
- Next wird als grobes Backlog missverstanden
- Now wird durch ungeplante Erweiterungen destabilisiert
Das sind keine Prozessprobleme. Das sind Entscheidungs- und Führungsprobleme.
Fazit
Rolling Wave Planning ist kein Planungstool. Es ist ein Führungsinstrument.
Es hilft Product Ownern, zwischen:
- Richtung
- Lernen
- Lieferung
klar zu unterscheiden und Verantwortung für Unsicherheit zu übernehmen, statt sie zu kaschieren.
Der Error Tracker ist nur ein Beispiel. Die eigentliche Kompetenz liegt darin, nicht alles zu früh zu entscheiden, auch wenn genau das von uns erwartet wird.
Gute Produktführung ist kein Versuch, Unsicherheit zu beseitigen. Sie ist die Fähigkeit, unter Unsicherheit gute Entscheidungen zu treffen.
