So verbessern Sie Ihr Backlog Refinement

​Das Backlog Refinement ist ein sehr wichtige Tätigkeit in Scrum. Durch das Backlog Refinement versetzt sich das Scrum Team in die Lage, das Backlog kontinuierlich aufzubereiten und ein gemeinsames Verständnis über die enthaltenen Product Backlog Items zu bekommen.

​Das Backlog Refinement

Backlog Refinement Toolbox

​Das Backlog Refinement in Scrum ist eine sehr wichtige entwicklungsbegleitende Tätigkeit, die im Scrum Guide mit etwa 10% der Entwicklungskapazität des Team berechnet wird. Ziel dieser Aktivität ist es, dass Anforderungen aus dem Product Backlog eine gewisse Reife erlangen, um in der Sprint Planung sinnvoll ​vollzogen werden zu können. Das Entwicklungsteam und der Product Owner haben ​in diesem Backlog Refinement die Möglichkeit das Verständnis zu schärfen: sie detallieren Anforderung, schätzen und schneiden diese.

Das Backlog Refinement im Scrum Guide

Scrum Guide

​Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner's discretion.

​Das Ziel für das Backlog Refinement

​Das Backlog Refinement hat das Ziel, die Anforderungen die sich im Product Backlog befinden, so weit aufzubereiten, dass diese in die Sprint Planung gelangen können. Diese Anforderungen werden Product Backlog Items genannt. Damit das geschehen kann, sind in der Regel die folgenden Schritte nötig

​Häufig spricht man auch von der sogenannten Definition of Ready. Dabei müssen Sie ​beachten, dass diese nicht zu einem sequentiellen Vorgehen führt und Sie sich unnötige Schwierigkeiten einhandeln. Details finden Sie in meinem Artikel, warum wir keine Defintion of Ready benötigen.

​Im Folgenden finden Sie die notwendigen Schritte für das Backlog Refinement:

  • Diskussion und Vorstellung der Product Backlog Items durch den Product Owner. Er muss die Anforderungen vom Kunden verstanden haben und kann diese dem Team vorstellen und Fragen dazu beantworten.
  • Festlegen von Akzeptanzkriterien. Durch die Diskussion mit Kunden und dem Entwicklungsteam hält der Product Owner mit Akzeptanzkriterien fest, wann für ihn die Anforderung erfüllt ist.
  • ​Schneiden von Product Backlog Items. Die Einträge, die sich im Product Backlog befinden benötigen die richtige Größe. Sie müssen nämlich in einen Sprint passen. Je kleiner Einträge sind, desto besser.
  • Schätzen der Einträge. Alle Einträge im Product Backlog sollten geschätzt sein. Das Entwicklungsteam schätzt die Einträge, der Product Owner schätzt nicht mit.

Ablauf des Backlog Refinements

​Zum Ablauf direkt sagt der Scrum Guide nicht viel aus, es bleibt Ihnen überlassen eine angemessene Lösung dafür zu finden. Eine Möglichkeit für den Ablauf im Backlog Refinement könnte so aussehen.

Voraussetzungen für die Durchführung

  • ​Einigung auf einen Termin. Bevor Sie das eigentlich Backlog Refinement starten können, benötigen Sie natürlich den Termin. Diesen stimmen das Entwicklungsteam und der Product Owner gemeinsam ab.
  • ​​Wer lädt ein? Nicht jedes neue Team macht sich gleich an die Arbeit, wenn es Unklarheiten gibt, lohnt es sich zu überlegen, wer "Meeting-Host" wird. Dabei bietet sich der Scrum Master an, wenn er alle anderen Termine auch verwaltet. Damit liegen dann alle Termine in einer Hand. Durch den Product Owner kann eine gewisse Wichtigkeit ausgedrückt werden, wenn er zu diesem Event einläd. Wenn er das bei Ihnen auch schon beim Sprint Review macht, bietet sich dieser Termin ggf. auch an.

Das Refinement im Ablauf

​Der Ablauf im Backlog Refinement ist eine Schleife über alle Product Backlog Items, bis die Zeit um ist oder bis kein Diskussionsbedarf mehr über weitere Anforderungen herrscht.

  • ​​Vorstellung des Product Backlog Items. ​Der Product Owner stellt das entsprechende Product Backlog Item vor. Dazu liest er es in der Regel vor und erklärt dem Entwicklungsteam, was damit gemeint ist. Im Vorfeld kann der Product Owner schon Akzeptanzkriterien eingefügt haben.
  • ​​​Fragen des Entwicklungsteam​. ​Nach der Vorstellung fragt das Entwicklungsteam den Product Owner zu diesem Product Backlog Item. Das Ergebnis dieser Diskussion wird im PBI festgehalten. Es kann bei dieser Diskussion auch herauskommen, dass zu wenig Informationen vorliegen oder noch weitere Akzeptanzkriterien nötig sind.
  • check-circle
    Aktualisierung / Hinzufügen von Akzeptanzkriterien. Durch die Diskussion und das Lernen entstehen oft neue Erkenntnisse, die sich in Form von ​neuen bzw. erweiterten Akzeptanzkriterien ausdrücken lassen.
  • check-circle
    Schneiden von PBIs. Das Team versucht möglichst kleine Anforderungen zu behandeln. Mindestens muss so eine Anforderung in den Sprint passen. Deshalb müssen zu große Einträge weiter geschnitten (verkleinert) werden.
  • check-circle
    Schätzen von Einträgen. Die eben erstellten oder besprochenen Product Backlog Einträge werden geschätzt. Am besten in einer Art und Weise, die dem agilen Schätzen naheliegt.

​Nach dem Refinement

​Optimalerweise konnten alle Fragen und Anmerkungen direkt im Backlog Refinement geklärt werden. Durchaus wird eine Frage im Nachgang noch geklärt, vielleicht nicht mehr zwischen allen. Diese Informationen müssen dann selbstständig und gewissenhaft durch die entsprechenden Personen im Product Backlog aufgenommen werden.

Die wichtigen Punkte für das Backlog Refinement

​Aus meiner Sicht, sind die folgenden Punkt immer wieder wichtig. Wenn Probleme im Backlog Refinement auftreten, dann oft genau in den folgenden Hinweisen.

  • ​Achten Sie darauf, dass Sie ausreichend Zeit für das Backlog Refinement besitzen. Unterschätzen Sie nicht die Zeit, die es benötigt, um Anforderungen "fertig" zu bekommen.
  • ​Stellen Sie sicher, dass eine klare Definition of Done existiert. Existiert diese nicht, werden Sie viel zwischen Akzeptanzkriterien und der Defintion of Done hin und herspringen. Dabei machen Sie sehr wahrscheinlich redundante Kommunikation, die überflüssig sein kann.
  • ​Fragen Sie immer aktiv nach, ob die Product Backlog Items beim Entwicklungsteam auch wirklich verstanden sind. Haben Sie reife Teams, die die Scrum Werte schon verinnerlicht haben, werden Sie diesen Punkt kaum benötigen. Ansonsten ​Augen auf und zudem prüfen, ob die richtigen Personen anwesend sind.

​Meine Erfahrungen zum Backlog Refinement

​Im folgenden finden Sie noch einige Erfahrungspunkte zum Backlog Refinement von mir aus der Praxis:

  • ​Bevor der erste Sprint startet, finde ich es als hilfreich mit dem Entwicklungsteam und dem Product Owner ein bis ​zwei Refinements zu machen, um das initiale Backlog auf einen guten Stand zu bringen. Das müssen Sie nicht tun, es hilft in meinen Augen aber sehr, dass die nachfolgenden Events in Scrum schnell und gut durchgeführt werden können, da die Basis der Anforderungen auf einem guten Stand ist.
  • ​Es kann Projekte geben, in denen das Backlog Refinement nur minimale Zeit in Anspruch nimmt. Planen Sie es aber trotzdem. Wenn Sie beginnen orientieren Sie sich bitte immer an der 10%-Regel aus dem Scrum Guide.
  • ​Ich nutze eine klare Vereinbarungen (wie ein Team Charter) zwischen Team und Product Owner: das Backlog Refinement ist - wie die anderen Events auch - ein fester Termin mit Agenda, um das Thema der Komplexität zu verringern und einen Rahmen zu schaffen.
  • check-circle
    ​​Können die Product Backlog Items im Refinement innerhalb von 20 Minuten besprochen werden? Wenn nein, dann sind sie in der Regel zu groß oder benötigen noch weitere Verfeinerungen. Auch das ist sehr abhängig vom Kontext, stellt für mich aber einen Wert bei der Analyse von neuen Teams dar.

​Zeitpunkt für das Backlog Refinement

Das Backlog Refinement ist eine entwicklungsbegleitende T​ätigkeit und hat keinen festen Platz, wie ein Event in Scrum. Schauen wir uns einmal die M​öglichkeiten an, wo und wie das Backlog Refinement am besten untergebracht werden kann.

Keine Zeit zwischen zwei Sprints

​Grundsätzlich findet das Backlog Refinement innerhalb des Sprints statt. Es gibt keine Zeit zwischen zwei Sprints. Bedenken Sie also hier, es kostet Sie Kapazität innerhalb des Sprints!

Backlog Refinement ​nach de​r ​Planung und vor dem Review

​Meistens liegen die Sprintwechsel in Organisationen so, dass nach ein paar Tagen, üblicherweise nach etwa der Hälfte des Sprints ein Refinement stattfindet. Wenn Sie zwei Termine machen, findet das Refinement üblicherweise nicht in den ersten Stunden nach der Sprint Planung statt und auch nicht in den letzten Stunden vor dem Sprint Review.

​Vorlage für die Einladung

​Vorlage


Liebes ​Team,

ich m​öchte euch hiermit zu unserem Backlog Refinement einladen. In diesem Regeltermin k​ümmern wir uns um die Reife der Eintr​äge im Backlog.

Datum & Zeit:

  • xx.xx.xxxx (ggf. auch Serientermin), um xx.xxUhr

Ziel:

  • Verfeinerung der Product Backlog Items und Schaffen eines gemeinsames Verst​ändnis ​über Anforderungen

Agenda:

  1. Vorstellung neuer oder wichtiger Product Backlog Items (PBIs) durch den Product Owner
  2. Fragen zu dem PBI durch das Entwicklungsteam
  3. Verfeinerung des PBI durch ​Überpr​üfung und ggf. Erweiterung der Akzeptanzkriterien
  4. ​Überpr​üfung auf die richtige Gr​öße: kann das PBI im Sprint umgesetzt werden? Wenn nicht, wie schneider wir diese Anforderung?
  5. Sch​ätzen der Anforderungen

Vielen Dank im Voraus f​ür eure Teilnahe und Engagement,

[Scrum Master oder Product Owner]

Leave a Reply 0 comments

Leave a Reply:







>
close

Der neue Online Scrum Kurs!

Der Online Scrum Kurs