Backlog Refinement

In diesem Artikel erläutere ich wie ich das Refinement interpretiere und wie ich es vom Sprint Planning 1 abgrenze.

Boris Gloger gibt in seinem Video interessante Hintergrundinformationen und erläutert die Entstehungsgeschichte des Backlog Refinement Meetings. Spannend finde ich dabei wie sich der Name über die Zeit verändert hat (Estimation Meeting => Backlog Grooming => Refinement) hat.

Ziel

Mit dem Backlog Refinement soll geklärt werden, ob das, was potentiell im nächsten Sprint umgesetzt werden soll, so weit vorbereitet ist, dass es auch umgesetzt werden kann.

Konkret klärt der Product Owner mit dem Entwicklerteam, ob

• das Sprint Goal sinnvoll ist,
• die User Stories verständlich sind,
• die User Stories anhand einer groben Schätzung in den Sprint passen könnten
• und ob die Priorisierung den besten Business Value liefern kann.

Oder anders formuliert: Der Product Owner stellt sich die die folgenden Fragen:

• Habe ich das Backlog richtig priorisiert?
• Haben die Entwickler ein Grundverständnis davon, was im nächsten Sprint auf sie zukommt?
• Sind die User Stories, von denen ich tatsächlich annehme, dass sie Teil des Sprint Plannings 1 werden, S.M.A.R.T..

Beispiele

Die folgenden zwei Szenarien kennen vermutlich die meisten aus dem Alltag und zeigen, dass ein vorheriges Refinement helfen kann.

Der Product Owner stellt im Sprint Planning 1 eine User Story vor und das Team versteht diese nicht. Es entstehen lange Diskussionen, es werden Zeichnungen am Flipchart erstellt und (Domänen-)Begriffe definiert. Statt im Planning würde im Refinement frühzeitig das Verständnisproblem entdeckt und die User Story vom Entwicklerteam an den Product Owner „zurückgegeben“ werden. Der Product Owner kriegt somit Zeit die Story klarer zu formulieren oder das Feature sogar neu zu schneiden.

Eine User Story kann im Sprint Planning 1 nicht geschätzt werden, weil die Entwickler dafür zunächst technische Fragen klären müssen. Als Ergebnis des Refinements würde das Entwicklerteam den zugehörigen Quellcode nochmal untersuchen oder eine technische Gegebenheit recherchieren. Im eigentlichen Sprint Planning 1 oder einem etwaigen zweiten Refinement stünden dann alle notwendigen Informationen zur Verfügung.

Eine User Story ist deutlich größer und komplexer als der Product Owner dies vermutet hätte. Das Entwicklerteam spiegelt ihm das im Refinement, sodass er den Inhalt im Nachgang in kleinere Stücke schneiden kann.

Durchführung

Wie oft das Refinement innerhalb eines Sprints durchgeführt wird und wer daran teilnimmt, ist Geschmackssache. Nehmt die Leute mit rein, die anwesend sein müssen, um die Fragen zu klären bzw. das Ziel des Refinements zu erreichen. Und wenn der Product Owner sich ein zweites oder drittes Meeting wünscht, weil er sonst das Sprint Planning 1 nicht adäquat vorbereiten kann, dann sollten sich das Team auch Zeit dafür nehmen. Die Zeit wird ansonsten in jedem Fall im Spring Planning 1 benötigt werden (und vermutlich sogar mehr).

Gibt es bei euch ein Refinement Meeting? Wenn ja, wie trennt ihr selbiges vom Planning? Sind bei euch immer alle Entwickler oder sogar Stakeholder dabei? Schreibt es in die Kommentare.

Werbung

Mit Tag(s) versehen: Agile / Lean, Scrum