Was ist eigentlich das Backlog Grooming?

Bloß nicht zu viel im Voraus planen und trotzdem möglichst kontinuierlich am Produkt arbeiten können: wie geht das zusammen? In Scrum passiert das sogenannte Refinement kontinuierlich oder in den optionalen Grooming-Meetings. Was es damit auf sich hat und wieso das Meeting häufig Sinn macht – darum geht es in diesem Artikel.

Was ist eigentlich das Backlog Grooming?

In einer agilen Vorgehensweise versuchen wir unnötige Arbeit zu vermeiden und bedienen uns dafür manchmal eines Tricks: Aufgaben so lange aufzuschieben bis klar ist, ob sie überhaupt erledigt werden müssen oder sich womöglich von selbst erledigt haben.

Dementsprechend wird auch das Product Backlog als lebendes Dokument verstanden, das nicht up-front sondern nach und nach entsteht und verfeinert wird.

Der Lebenszyklus einer Anforderung

In der Praxis bedeutet das, dass eine Produktanforderung ihren Lebenszyklus als einzelner Satz (zum Beispiel als User Story) auf einer Karte starten kann und bis zur letztlichen Abarbeitung nach und nach um mehr Details angereichert wird.

Oder aber sie wird gestrichen – wenn sich im weiteren Verlauf beispielsweise rausstellt, dass ein Feature doch nicht umgesetzt werden soll.

Auf diese Weise kann der Planungsaufwand gering gehalten werden, weil die Details (zumindest im Idealfall) nur für Anforderungen ausgearbeitet werden müssen, die tatsächlich umgesetzt werden sollen. Andererseits mach das eine Pflege des Product Backlogs unerlässlich: die Diskussionen zwischen Stakeholdern und den Teammitgliedern müssen geführt, Akzeptanzkriterien und die Details ausgearbeitet und mit den Marktbedingungen beziehungsweise dem Feedback der Kunden abgeglichen werden.

Das Ziel: Am Anfang eines Sprints sollen genügend Backlog-Items zur Verfügung stehen, dass sie vom Team mit in den Sprint aufgenommen werden könnten.

Backlog Refinement: kontinuierlicher Vorgang oder regelmäßiges Meeting

Das Scrum-Framework schreibt nicht vor, wie das Backlog-Grooming oder Backlog-Refinement zu erfolgen hat und dementsprechend ist ein Meeting fürs Refinement auch kein Pflicht-Event.

Das Refinement selbst ist aber sehr wichtig – damit der Ablauf nicht ins Stocken gerät, weil dem Team die Aufgaben ausgehen. Auch wenn diese Aufgabe zum Requirements Engineering gehört und dies hauptsächlich in der Verantwortung des Product Owners liegt, ist das Mitwirken des Teams erforderlich. Denn das Team muss letztlich entscheiden, wann eine Anforderung ausreichend refined wurde, um in einen Sprint aufgenommen werden zu können.

Prinzipiell wäre es also noch „Scrum by the book“, wenn das Refinement nebenläufig zum regulären Doing stattfindet, aber für viele Teams dürfte sich wohl ein regelmäßiges Grooming-Meeting als die sinnvollere Variante herauskristallisieren.

Was genau im Refinement passiert

Beim Refinement geht es darum das Product Backlog zu hegen und zu pflegen und bei Bedarf auch zurecht zu stutzen. So gehören beispielsweise die folgenden Aktivitäten zu diesem Vorgehen:

• Bestehende Product Backlog Items / User Stories (PBIs) um neue Informationen ergänzen, Rückfragen der Teammitglieder ermitteln
• Alte Product Backlog Items (PBIs) entfernen, wenn sie nicht länger relevant sind
• Neue PBIs aufnehmen, wenn das beispielsweise aufgrund neuer Erkenntnisse sinnvoll erscheint
• Anpassung der (relativen) Prioritäten
• Items mit Schätzungen versehen oder die Schätzung aufgrund von neuen Erkenntnissen anpassen
• User Stories aufsplitten, wenn sie hohe Priorität haben und zu groß für eine Iteration sind

Dabei wird im Refinement immer für den nächsten Sprint im Voraus geplant, was den Vorteil hat, dass das Sprint Planning einfacher wird. Denn wichtige Fragen können schon im Vorfeld geklärt und Unklarheiten ausgeräumt werden können.

Warum die Meeting-Variante dafür häufig Sinn macht

Man kann sich leicht vorstellen, dass es sich beim Refinement um einen kommunikationsintensiven Vorgang handelt, der unter Umständen auch Kommunikation mit den Stakeholdern umfasst. In Teams, die kein Meeting fürs Backlog-Grooming machen, muss diese Kommunikation parallel zu allen anderen Aufgaben stattfinden.

Nun ist das ja eine ganz andere Art von Arbeit, die mit dem aktuellen Sprint-Ziel wenig gemein hat, Kontextwechsel mit sich bringt und gerade uns Techies jetzt auch nicht unbedingt hinter dem Ofen hervor lockt. Dementsprechend hoch ist die Wahrscheinlichkeit, dass das Prozedere eher halbherzig erfolgt, insgesamt mehr Zeit als nötig in Anspruch nimmt oder sogar Fragen offen lässt, die dann erst in der Sprint-Planung geklärt werden können. Ein fokussiertes, durch den Product Owner hoffentlich gut vorbereitetes und moderiertes Grooming-Meeting kann da die bessere Alternative sein. Letztlich auch weil Face-to-Face-Kommunikation oft die effektivere Kommunikationsform ist.

Der Scrum-Guide sieht fürs Refinement übrigens bis zu 10% der Teamkapazität vor, also einen ganzen Tag bei zweiwöchigen Sprints. Klingt viel – und ist es vermutlich auch.

Andererseits sollte das (zumindest nach einiger Zeit) ein Maximalwert sein und diese Arbeit fiele vermutlich so oder so an: dann aber eben mit durch Kontextwechsel erhöhten Aufwänden. Im Gegenzug kann das Refinement den tatsächlichen Zeitaufwand für andere Events verringern (beispielsweise die erwähnte Sprint-Planung) und dafür sorgen, dass die Zeit im Sprint effizienter genutzt werden kann.

Last but not least kann ein engagierter Product Owner natürlich auch dazu beitragen, den Aufwand durch sorgfältiges Anforderungsmanagement gering zu halten.

Am Ende des Tages muss jedes Team selbst entscheiden, ob es sich für Refinement Meetings entscheidet und wie es sie durchführt. Wenn es sich aber dagegen entscheidet und dadurch im Sprint immer wieder in Planungen verwickelt wird, sollte das niemanden wundern.

Am Refinement selbst führt dagegen ohne „Big planning upfront“ kein Weg vorbei.