Aktuell überarbeite ich meine Webseite umfassend. Daher können einige Links ins Leere führen, Texte unvollständig sein und es kann an manchen Stellen noch zu Problemen kommen. Ich werde diesen Hinweis entfernen, sobald die Seite vollständig aktualisiert ist. Bis dahin bitte ich um etwas Geduld. Schaue auch unter den letzten Updates nach, wenn du etwas bestimmtes suchst.
Das Product 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 angegeben wurde. Mittlerweile fehlt diese Angabe, ich finde sie als erste Idee aber nach wie vor sehr wertvoll. 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
Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
Quelle: https://scrumguides.org/scrum-guide.html#product-backlog
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.
Ablauf des 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. Meistens leiten sich darauf zwei unterschiedliche Arten ab.
Product Backlog Items verfeinern
Exploration für neue Backlog Items
Vergleich von DoE, DoR und DoD
Im Zuge des Backlog Refinements gibt es oft die folgenden drei Begriffe, die ich hier kurz erklären möchte.
Header | Definition of Entry | Definition of Ready | Definition of Done |
|---|---|---|---|
Kennt es der Scrum Guide? | nein | nein | ja |
Definition | Liste von Kriterien, bevor ein Product Backlog Item in der Product Backlog aufgenommen wird | Liste von Kriterien, bevor ein Product Backlog Item in das Sprint Planning gelangen kann | Liste von Kriterien, bevor ein Product Backlog Item als fertig angesehen werden kann |
Gefahren |
Erfahrungen
Je kleiner die Teams sind und wenn du reife Organisationen hast, die ein klaren Ziel haben und bei denen auch die Poduktentwicklung sehr fokussiert abläuft, findest du selten DoE und DoR.
Bei größeren Unternehmen und Konzernen sind sie hingegen oft anzutreffen.
Was und Wie
Damit ein Refinement funktioniert und nicht im Sinne einer Spezifikation schreiben verwendet wird, ist es wichtig das Was vom Wie zu trennen. In Scrum ist die Aufteilung von dem Was und dem Wie klar geregelt: Der Product Owner ist für das Was zuständig, die Experten (also die Entwickler) für das Wie. Und wir gehen immer davon aus, dass die Entwickler in der Lage sind und befähigt, das Wie umzusetzen.
Halten wir aber auch fest, dass dieses - gerade bei größeren Unternehmen - so nicht oder nur teilweise existiert. Es ist klare Führungsaufgabe von C-Level Personen dieses Umfeld zu schaffen.
Finde dein richtiges Verhältnis
Der Scrum Guide sagt dir nicht, wie genau du Product Backlog Items zu schreiben hast. Sehr viele versuchen sich an den sogenannten User Stories. Eine sehr etablierte und gut funktionierende agile Praktik.
Wenn in deinem Kontext dieses Format alleine nicht ausreicht, bist du natürlich frei in der Gestaltung. Nichtsdestotrotz musst du darauf achten, nicht in das Schreiben von Spezifikationen abzudriften.
100% Wie bedeutet Spezifikationen zu schreiben
Du musst dir bewusst sein, dass Product Backlog Items nicht komplett im Vorfeld ausgeschrieben werden. Das kann nie Ziel in Scrum sein. Wenn du das wirklich brauchst, ist die Frage ob dein Umfeld komplex ist und du Scrum überhaupt brauchst.
Refinement, Spike, Exploration, Konzeption & Implementierung
Wenn du aus einem Konzern kommst oder aus einem größeres Unternehmen stammst, dann finden sich oft die obigen Bezeichnungen in deinem Kontext. Damit du diese einsortieren kannst, möchte ich dir hier noch mal einen Einblick in die Interpretation geben. Es ist entscheidend, dass du das Verständnis für dich klar hast.
Ich möchte hier keine Partei ergreifen und grundsätzlich die Vorgehen nicht bewerten. Du musst nur verstehen, dass manche schlicht nichts mit Scrum zu tun haben und kontraproduktiv sind. In anderen Kontexten können diese durchaus sinnvoll sein.
Header | Refinement | Spike | Exploration | Konzeption |
|---|---|---|---|---|
Teilnehmer | ||||
Dauer | ||||
Zweck | ||||
Grober Ablauf | ||||
Bezug zum Backlog | ||||
Ergebnisse | ||||
Bezug zu Scrum | ||||
Gefahr bei Anwendung in Scrum |
Erfahrungswerte
In wenig reifen Organisationen oder auch Unternehmen, die gar kein 100% Scrum implementieren wollen, finden sich öfters Exploration, Konzeption & Umsetzung als Phasen innerhalb von Sprints. Auf die Probleme möchte hier kurz eingehen.
Gefahren fehlenden Refinements
Egal wie du es drehen willst: Die Zeit, die du hier nicht investierst, die holt dich an anderen Stellen immer wieder ein.