Backlog Refinement für Dummies ;)

Das Backlog ist das zentrale Steuerungsinstrument in agilen Projekten, insbesondere im Scrum-Umfeld. Es dient dazu, alle Anforderungen an ein Produkt strukturiert und priorisiert zu sammeln. Doch wie behält man bei der Vielzahl an Einträgen den Überblick und stellt sicher, dass das Team immer an den wichtigsten Aufgaben arbeitet? Hier kommt das Backlog Refinement ins Spiel. Erfahre, wie man das Backlog kontinuierlich optimieren und welche Best Practices dabei helfen, den Fokus nicht zu verlieren.

Was ist ein Backlog?

Das Backlog ist eine priorisierte Liste von Anforderungen für ein (Software) Produkt. Bei den Anforderungen spricht man im Scrum Jargon von Product Backlog Items (PBIs). Im Rest dieses Blogs werde ich also von PBIs sprechen.

Was ist Backlog Refinement?

Backlog Refinement ist das kontinuierliche schärfen und priorisieren von den PBIs im Backlog. Dabei werden insbesondere die obersten PBIs (höchste Priorität) in den Zustand der Projekt «Definition of Ready» gebracht. Die “Definition of Ready” beschreibt die Metriken, wann ein PBI für die Implementation bereit ist.

Wieso Backlog Refinement?

Die Anforderungen und Prioritäten ändern sich laufend während eines Projektes.

Du fragst Dich jetzt vielleicht, wieso diese sich überhaupt ändern können? Da gibt es viele Gründe:

• der Markt verändert sich

• neue technische Erkenntnisse/Herausforderungen tauchen auf

• Stakeholder nehmen Einfluss und/oder ändern ihre Meinung

• nach einer Demo sieht der Product Owner neues Potential für weitere Features

• …

Das Backlog versucht all diesen Änderungen gerecht zu werden und soweit möglich abzubilden.

Wie mache ich das zielführend?

• Priorisiere gemäss Return-On-Investment (ROI), d.h. der grösste Nutzen für das Produkt. Dies kann am Besten mit folgenden Werkzeugen eruiert werden

  • Story Mapping

  • Red Routes Analyse

  • Preplanning Poker

• Konzentriere Dich vor allem auf die PBIs, welche im nächsten und übernächsten Sprint umgesetzt werden sollen

• Beschreibe das WAS und nicht das WIE in den PBIs

• Überprüfe neue und existierende Anforderungen laufend mit der Produkt Vision und dem Produktziel

• Führe das Refinement regelmässig durch. Am Besten ein fixer, wöchentlicher Termin mit dem PO (falls es keine Updates gibt, ist der Termin schnell abgesagt)

• Schätze den Aufwand für jedes PBI. Eine schlechte Schätzung ist besser als keine Schätzung.

• PBIs dürfen auch gesplittet oder zusammen geführt werden

Pro Tipp: Sobald neue Erkenntnisse (Business oder Technischer Natur) über eine Anforderung bekannt werden, sollen diese ins Backlog eingepflegt werden. Damit verhindert man für alle Team Members einen «Brain Overload».

Das Backlog soll lebendig sein und die Realität abbilden!

Welche Stolpersteine gibt es?

• Alle Stories im Backlog bis ins letzte Detail spezifizieren → Wir sind wieder bei Wasserfall angelangt, Yay!

• Lange Diskussionen über Stories, welche erst im nächsten Release (oder vielleicht gar nicht) umgesetzt werden sollen

• Viel Zeit in das WIE (umsetzen) eines PBI investieren. Überlasse dies den Experten im Team!

• Führe alle Arbeiten im Backlog, also auch Bugs, Retro Action Items und andere (versteckte) Arbeiten