Das Backlog Refinement

Backlog Refinement
Von Sebastian Schneider // 03.03.2017 // 0 Kommentare

Das Backlog Refinement ist ein sehr wichtige Tätigkeit in Scrum. Dadurch versetzt sich das Scrum Team in die Lage, das Backlog (mit allen Anforderungen) kontinuierlich aufzubereiten und ein gemeinsames Verständnis über die enthaltenen Product Backlog Items zu bekommen. Alles was das Product Backlog Refinement verlassen hat und von allen verstanden ist, kann im einer Sprint Planning betrachtet werden.

Das Product Backlog Refinement im Scrum (Refinement Meeting)

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. Früher wurde sie als Grooming oder Backlog Grooming bezeichnet. Ziel dieser Aktivität ist es, dass Anforderungen aus dem Product Backlog eine gewisse Reife erlangen, um in der Sprint Planung für einen Sprint geplant werden zu können. Die Entwickler und der Product Owner haben in diesem Backlog Refinement die Möglichkeit das Verständnis zu schärfen: sie detaillieren Anforderung, schätzen und schneiden diese so, dass sie sinnvoll in einen Sprint bearbeitet werden können. Identisch kannst du das auch für EPICs gehen. Ebenso findet oft eine Sortierung oder Priorisierung statt. Somit geht es immer um die Pflege und Weiterentwicklung des Product Backlogs.

Das Backlog Refinement im Scrum Guide

Scrum Guide

Product-Backlog-Einträge, die durch das Scrum Team innerhalb eines Sprints abgeschlossen (Done) werden können, gelten als bereit für die Auswahl in einem Sprint-Planning-Event. Diesen Transparenzgrad erlangen sie in der Regel durch Refinement-Aktivitäten. Das Refinement des Product Backlogs ist der Vorgang, durch den Product-Backlog-Einträge in kleinere, präzisere Elemente zerlegt und weiter definiert werden. Dies ist eine kontinuierliche Aktivität, wodurch weitere Details wie Beschreibung, Reihenfolge und Größe ergänzt werden. Die Attribute variieren oft je nach Arbeitsumfeld.

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 (PBI) 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 musst du beachten, dass eine Definition of Ready nicht zu einem sequentiellen Vorgehen führt und du dir unnötige Schwierigkeiten und weitere überflüssige Arbeitsschritte einhandelst. Details findest du in meinem Artikel, warum wir keine Defintion of Ready benötigen.

Im Folgenden findest du die notwendigen Schritte für das Backlog Refinement:

  • Diskussion und Vorstellung der PBIs durch den Product Owner. Er muss die Anforderungen (also das "was" will der Kunde) 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 schärft der Product Owner das Verständnis über die Product Backlog Items. Er hält der mit Akzeptanzkriterien fest, wann für ihn die Anforderung erfüllt ist. Dafür verwendet er typischerweise Ausdrücke, die ein Erlebnis oder eine erlebbare Aktion beschreiben.
  • Schneiden von PBIs. 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 wertvolle 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 und lässt Freiheiten. Es bleibt dir überlassen eine angemessene Lösung dafür zu finden. Ein Ablauf könnte wie folgt aussehen.

Vorbereitung

  • Einigung auf einen Termin. Bevor du das eigentlich Backlog Refinement Meeting startest, benötigst du natürlich den Termin. Diesen stimmen das Entwicklungsteam und der Product Owner gemeinsam ab. Dieser Termin kann auch eine spontane Session sein. Da ein Refinement eine entwicklungsbegleitende Tätigkeit ist, kann diese auch einfach zur richtigen Zeit stattfinden.
  • Wer lädt ein? Nicht jedes neue Team macht sich gleich an die Arbeit, wenn es Unklarheiten gibt. Es lohnt sich zu überlegen, wer "Meeting-Host" ist. 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 dir auch schon beim Sprint Review macht, bietet sich dieser Termin ggf. auch an.

Durchführung

Der Ablauf im Termin selbst 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 Product Backlog Item festgehalten. Es kann bei dieser Diskussion auch herauskommen, dass zu wenig Informationen vorliegen oder noch weitere Akzeptanzkriterien nötig sind.
  • 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.
  • 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.
  • 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.

Meisten kristallisieren sich zwei unterschiedliche Arten heraus:

  1. Wie oben beschrieben, existieren die Einträge bereits und sind im Backlog geführt
  2. Es gibt nur ein vages Thema und die Aufgabe des Product Owners ist es hier gemeinsam mit den Entwickler überhaupt erstmal zu gültigen PBI zu kommen.

Nachbereitung

Optimalerweise konnten alle Fragen und Anmerkungen direkt im Termin 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.

3 Tipps für das Refinement

Aus meiner Sicht, sind die folgenden Punkt immer wieder wichtig. Wenn Probleme in der Aktivität der Verfeinerung feststellst, dann oft genau in den folgenden Hinweisen:

  • Achte darauf, dass ausreichend Zeit für das Verfeinern vorgesehen ist. Unterschätze nicht die Zeit, die es benötigt, um Anforderungen "fertig zur Bearbeitung" zu bekommen.
  • Stelle sicher, dass eine klare Definition of Done existiert. Existiert diese nicht, wird viel zwischen Akzeptanzkriterien und der Defintion of Done hin und herspringen. Dabei machen Sie sehr wahrscheinlich redundante Kommunikation, die überflüssig sein kann. Zudem kann das Entwicklungsteam schlechter schätzen, wenn nicht klar ist, was fertig bedeutet.
  • Frage immer aktiv nach, ob die Product Backlog Items beim Entwicklungsteam auch wirklich verstanden sind. Hast du reife Teams, die die Scrum Werte schon verinnerlicht haben, braucht es diese Nachfrage weniger. Ansonsten gilt gerade für den Scrum Master: Augen auf, die richtigen Fragen stellen und zudem Augenmerkt auf die richtigen Teilnehmer legen.

Meine Erfahrungen zum Backlog Refinement

Im folgenden findest du 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 durchzuführen, um das "initiale Backlog" auf einen guten Stand zu bringen. Das musst du 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 Produkte geben, für die das Backlog Refinement nur minimale Zeit in Anspruch nimmt. Plane es aber trotzdem. Wenn du beginnst, orientiere dich bitte immer an der 10%-Regel. Das hilft effizient zu bleiben.
  • 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. Zusätzliche spontane Session werden meistens trotzdem benötigt.
  • Können die Product Backlog Items im Refinement innerhalb von ca. 20 Minuten besprochen werden, dass das "was" klar ist? 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. Bedenke, es kostet dich immer Kapazität innerhalb des Sprints!

Backlog Refinement nach der 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 du zwei Termine machst, 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]

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt.

Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben.

Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen.

Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

>