Das Product Backlog Refinement wird im Scrum Guide, den „Scrum-Regeln“, als Hinzufügen von Details, Schätzungen und Struktur zum Product Backlog beschrieben.
Aber während der Scrum Guide auf verschiedene andere Meetings wie das Sprint Planning, die Sprint Review und die Sprint Retrospektive eingeht, sagt er nichts darüber aus, wie das Product Backlog Refinement ablaufen sollte. Es ist Sache des Scrum Teams zu entscheiden, wie und wann dieses Product Backlog Refinement stattfindet.
Product Backlog Refinement zur Erstellung von Schätzungen
Wie bereits erwähnt, geht es beim Product Backlog Refinement darum die User Stories, die der Product Owner in das Product Backlog aufgenommen hat, zu detaillieren.
Indem sie mehr über die User Stories wissen und sie im Detail verstehen, können die Entwickler (früher Development Team genannt) abschätzen, wie groß die User Story ist. Da sie genau wissen, was der Product Owner verlangt und welche Arbeiten dafür erforderlich sind, können die Entwickler genaue Schätzungen abgeben.
Gute Schätzungen sind für den Product Owner und die Entwickler sehr wichtig.
Der Product Owner kann auf der Grundlage aller geschätzten User Stories im Product Backlog ein Release Planning erstellen. Schließlich weiß er, welche User Stories er in die nächste Version aufnehmen will. Auf der Grundlage der Summe der Schätzungen kann er eine solide Vorhersage treffen, wann das Produkt geliefert wird.
Die Entwickler verwenden die Schätzungen, um festzustellen wie viele User Stories sie im nächsten Sprint bearbeiten können.
Product Backlog Refinement hilft dabei Abhängigkeiten zu entdecken
Ein weiterer Zweck des Product Backlog Refinements ist die frühzeitige Aufdeckung von Abhängigkeiten. Das können Abhängigkeiten zwischen Stories sein. Die Entwickler können auch feststellen, dass sie von anderen außerhalb des Teams abhängig sind. Wenn dies frühzeitig erkannt wird, können die Abhängigkeiten beseitigt werden.
Der Product Owner kann z. B. eine User Story so umschreiben, dass die Abhängigkeiten verschwinden.
Im Falle von externen Abhängigkeiten können die externen Personen frühzeitig kontaktiert werden. Anschließend können Vereinbarungen über die von ihnen zu verrichtenden Arbeiten getroffen werden.
Vorbereitung des Product Backlog Refinement Meetings
Ein gutes Product Backlog Refinement Meeting steht und fällt mit einer guten Vorbereitung. Der Product Owner muss eine klare Vorstellung davon haben, welche User Stories für ein Product Backlog Refinement in Frage kommen.
Es ist wichtig die User Stories nicht zu weit im Voraus zu detaillieren. Es kann vorkommen, dass die User Stories nie in einem Sprint enthalten sind. Nur Stories, die im Product Backlog weit genug oben stehen, werden geliefert.
Detaillieren Sie daher nur die User Stories, die in den nächsten 2 oder 3 Sprints verwendet werden sollen.
Als nächstes ist es wichtig, dass die User Stories klar formuliert sind. Der Product Owner muss sicherstellen, dass diese klar genug sind. Außerdem muss es genügend Akzeptanzkriterien pro User Story geben. Dadurch wird den Entwicklern klar, welche Qualitätsanforderungen erfüllt werden müssen.
Das Product Backlog Refinement Meeting
Das Product Backlog Refinement Meeting ist zeitlich genau wie die anderen Meetings in Scrum. Der Scrum Guide geht davon aus, dass 10% der gesamten Sprint Zeit für das Refinement reserviert ist. Bei einem Sprint, an dem in Vollzeit gearbeitet wird, würde die Timebox also maximal 4 Stunden pro Woche betragen.
Das gesamte Scrum Team ist bei dem Product Backlog Refinement Meeting anwesend.
Der Product Owner erklärt den Entwicklern die User Stories, eine nach der anderen. Sie müssen sich ein vollständiges Bild von der Geschichte machen. Die Entwickler müssen wissen, was zu tun ist und welche Qualitätsanforderungen bestehen. Diese werden durch die Definition of Done und die Akzeptanzkriterien gebildet.
Der Product Owner erklärt die Story und die Entwickler geben Feedback. Auf diese Weise kann die User Story bei Bedarf angepasst und präzisiert werden.
Als Nächstes schätzen die Entwickler das Gewicht der User Story, oft durch Planning Poker.
Die Entwickler können das Product Backlog Refinement Meeting auch nutzen, um sich bereits Gedanken darüber zu machen, wie sie die Story aufteilen werden. Die Aufgaben können bereits festgelegt werden. Dies verschafft einen Vorsprung bei dem Sprint Planning, das dadurch effizienter abläuft.
Ein gutes Product Refinement sorgt dafür, dass früh genug klar ist, was getan werden muss. Darüber hinaus ist bekannt, wie diese Geschichten geschätzt werden und aufgeteilt werden können.
Unwägbarkeiten und Abhängigkeiten werden beseitigt, und die Entwickler können ihre Arbeit fortsetzen und sich auf die Bereitstellung von Werten konzentrieren.
