.st0{fill:#FFFFFF;}

Scrum Guide

Das Backlog Refinement

 März 3, 2017

von  Sebastian Schneider

Share0
Tweet0
Share0

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. Alles was das Product Backlog Refinement verlassen hat und von allen verstanden ist, kann in einer Sprint Planung betrachtet werden.

Inhaltsverzeichnis
1
Das Backlog Refinement
1.1
Das Backlog Refinement im Scrum Guide
1.2
Das Ziel für das Backlog Refinement
1.3
Ablauf des Backlog Refinements
1.3.1
Voraussetzungen für die Durchführung
1.3.2
Das Refinement im Ablauf
1.3.3
Nach dem Refinement
2
Die wichtigen Punkte für das Backlog Refinement
2.1
Meine Erfahrungen zum Backlog Refinement
2.2
Backlog Refinement im Jira richtig durchführen
3
Zeitpunkt für das Backlog Refinement
3.1
Keine Zeit zwischen zwei Sprints
3.2
Backlog Refinement nach der Planung und vor dem Review
4
Vorlage für die Einladung

Das Backlog Refinement

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 für einen Sprint geplant 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 so, dass sie sinnvoll in einen Sprint bearbeitet werden können.

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 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 Product Backlog Items 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 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 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. 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 du das eigentlich Backlog Refinement starten kannst, 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 eine Backlog 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.

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 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.

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.

  • Achte darauf, dass ausreichend Zeit für das Backlog Refinement 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 Projekte geben, in denen das Backlog Refinement nur minimale Zeit in Anspruch nimmt. Plane es aber trotzdem. Wenn du beginnst, orientiere dich 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. 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.

Backlog Refinement im Jira richtig durchführen

Wenn du auch das Tool Jira von Atlassian nutzt, dann kannst du das Refinement mit allen Punkten, die hier genannt sind, durchführen. Wenn du noch einen Tipp für das Marieren und Finden von relevanten Product Backlog Items suchst, dann schaue dir gerne noch mein YouTube Video dazu an!

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

Author Image

Ein paar Worte über den Autor

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.

Sebastian Schneider CSP-PO
Sebastian Schneider CSP
{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Hole dir auch den kostenlosen Online Scrum Kurs

Hier gehts lang!
>