Das fokussierte Backlog

Das fokussierte Backlog

Transparenz und Effektivität erreichen

Was sind eigentlich die Auswirkungen eines guten Backlogs? Mir fällt da neben den üblichen (Priorität nach Kundennutzen, Stories lassen sich ohne Abhängigkeiten umsetzen etc.) immer eine ein und diese eine ist sehr aussagekräftig: Das Sprint-Planning verläuft zügig, ohne Diskussionen (wer hat es nicht schon erlebt, dass Inhalte, Schätzungen oder Priorisierung von Stories erst im Planning noch einmal durchdiskutiert werden?) und jeder geht mit einem guten Gefühl.

Warum ist das so aussagekräftig?

Ganz einfach: Dem Product Owner und dem Entwicklungsteam sind alle vorgestellten Stories bekannt und transparent. Das Team hat die Stories durchdrungen und geschätzt. Jeder der Anwesenden kennt Nutzen und Inhalt der Story. Und jeder sieht es genau so. Diskussionen finden nur noch in Ausnahmefällen statt. Alles passt zur gemeinsamen Marschrichtung und den vereinbarten Zielen. Das Backlog wird genau darauf fokussiert.

Was muss der Product Owner dafür tun?

In erster Linie heißt es Transparenz im Entwicklungsteam zu schaffen und das für die nächsten 2 Sprints. Das heißt, dass die entsprechenden Stories rechtzeitig besprochen und diskutiert werden. So kann der PO die Stories anders schneiden oder anders priorisieren, um sie dann wieder vorzustellen und schätzen zu lassen. Bewährt hat sich die direkte Einbindung des Entwicklungsteams in Story-Erstellung, Schwerpunkt Definition Abnahmekriterien (z.B. mit Story-Paten).

Natürlich ist es gut, dass das Backlog mit vielen weiteren Einträgen befüllt wird. Aber: Diese müssen noch nicht so detailliert beschrieben sein und auch noch nicht geschätzt sein. Je weiter die Umsetzung der Stories in der Ferne liegt, desto eher sind sie grob, unfertig und unverbindlich (also eher eine Diskussionsgrundlage).

Um Team und Stakeholdern eine Marschrichtung aufzuzeigen und Ziele zu vereinbaren, wird eine Product Roadmap eingesetzt. Diese zeigt Ziele und Features für die nächsten Releases aus einer großen Flughöhe auf und eignet sich somit sehr gut zur gemeinsamen Fokussiereung.

Das Backlog wird von seiner Rolle als Pseudo-Roadmap befreit. Ohne Roadmap kann es schnell passieren, dass Stakeholder das Backlog als Ersatz nehmen. Das fördert die Annahme von Außenstehenden, dass die Umsetzung auch von weit unten stehenden Backlog-Einträgen und deren Reihenfolge verbindlich sind.

Was muss der Scrum Master dafür tun?

Der Scrum Master sorgt für Struktur und Rahmen, um das Backlog zu pflegen. Dazu gehören:

  • Definition einer “Definition of Ready” für Stories mit dem Entwicklungsteam
  • Etablierung eines wöchentlichen Estimation- und/oder Backlog-Refinement-Meetings (hier stellt der PO dem Team die Stories vor, damit sie geschätzt oder im Anschluss rechtzeitig anders geschnitten oder beschrieben werden)
  • Unterstützung des POs beim Einsatz einer Product Roadmap (Methodik, Aufbau, Kommunikation, Pflege)
  • Unterstützung bei der Fokussierung auf die Vorbereitung der nächsten 2 anstehenden Sprints (Überprüfung des Fertigstellungsgrads der Stories, Hinterfragung der Vorbereitung von späteren Features)

Fazit

Das fokussierte Backlog lässt den PO sein Augenmerk auf die Vorbereitung der nächsten 2 Sprints richten. Mit einer Product Roadmap zeigt er trotzdem eine klare langfristige Marschrichtung auf. Chaotische und kräftezehrende Plannings mit unterschiedlichen Sichtweisen werden reduziert – der Übergang von Planning zum Sprint verläuft reibungslos. In Summe werden mit dieser Strukturierung Arbeit und Energie gespart.

Image:
Diesen Artikel teilen:

Einen Kommentar hinterlassen

*

Projektpfad – Der Blog für agile Produktentwicklung - Background

Suche eingeben

Alle Ergebnisse anzeigen