--- title: Rolling Wave Planning im Alltag eines Product Owners author: Lars Decker date: 2026-01-25 updated: 2026-01-25 description: Praxisbeispiel für Rolling Wave Planning im PO-Alltag: Mit Error-Tracker, Planungshorizonten und bewusstem Umgang mit Unsicherheit. tags: rolling wave planning, product owner, praxisbeispiel, entscheidungsfindung, agile planung canonical: https://lars-decker.eu/blog/rolling-wave-planning-praxis --- # 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](/blog/rolling-wave-planning)**. 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. Rolling Wave Planning Phasen: Später, Nächstes, Jetzt - Von Hypothesen zu Ergebnissen _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**.