Verfeinerung des Backlogs (Grooming): Rhythmus, Verantwortlichkeit und die Bedeutung des Begriffs „bereit“

Die Backlog-Verfeinerung – nach wie vor häufig als „Grooming“ bezeichnet – ist die fortlaufende Arbeit, Produkt-Backlog-Elemente vor dem Sprint, in dem sie umgesetzt werden sollen, vorzubereiten: Dabei wird geklärt, was jedes Element bedeutet, zu umfangreiche Elemente werden aufgeteilt, Akzeptanzkriterien hinzugefügt, der Umfang geschätzt und die Elemente nach Priorität geordnet. Es handelt sich dabei weniger um ein einzelnes Meeting als vielmehr um eine Gewohnheit. Und genau darin liegt der feine Unterschied zwischen einer ruhigen Sprintplanung und einer Sprintplanung, die zu einer zweistündigen Auseinandersetzung ausartet.

Handelt es sich um eine Zeremonie oder nicht?

Technisch gesehen nein. Im Scrum Guide wird die Backlog-Verfeinerung nicht als eines der Ereignisse aufgeführt – sie wird dort als fortlaufende Aktivität beschrieben, die nicht mehr als etwa 10 % der Kapazität der Entwickler in Anspruch nehmen sollte. Die Puristen haben also Recht: Es handelt sich nicht um eine Zeremonie.

Und doch trägt Asanas Leitfaden zu agilen Zeremonien den Titel „4 Veranstaltungen + Backlog-Verfeinerung“, und die meisten Arbeitsteams reservieren im Kalender einen festen Termin für die Verfeinerung und führen sie wie jede andere Zeremonie durch. Beide Lager weisen aus unterschiedlichen Blickwinkeln auf dieselbe Wahrheit hin: Die Verfeinerung ist kein formelles Ereignis, aber sie wie eines zu behandeln, ist in der Regel die richtige Entscheidung. Lässt man sie aus, verschwinden die Kosten nicht – sie verlagern sich lediglich in die Sprintplanung, wo sie teurer sind und zu einem ungünstigeren Zeitpunkt anfallen.

Was eine Verfeinerung tatsächlich bewirkt

Durch die Verfeinerung werden rohe Backlog-Elemente – oft nur ein Titel und eine vage Hoffnung – in umsetzbare Elemente umgewandelt. In der Praxis umfasst dies vier Schritte, die kontinuierlich ablaufen:

• Präzisieren Sie dies. Formulieren Sie „das Onboarding verbessern“ so um, dass daraus eine klare Zielsetzung mit Akzeptanzkriterien wird, anhand derer das Team die Umsetzung überprüfen kann.
• Aufteilen. Teilen Sie Aufgaben, die zu umfangreich sind, um sie in einem Sprint abzuschließen, in kleine, für sich genommen wertvolle Teilaufgaben auf. Dies ist eine Kunst für sich – siehe Aufteilen von User Stories.
• Umfang. Einigen Sie sich auf eine gemeinsame Story-Point-Schätzung, in der Regel mithilfe von Planning Poker, damit der relative Aufwand vor der Zusage klar ist.
• Reihenfolge. Halten Sie den Auftragsbestand so sortiert, dass die wertvollsten und am weitesten fortgeschrittenen Aufgaben ganz oben stehen, wo sie bei der Planung als Erstes berücksichtigt werden.

Die Ausgabe ist kein Dokument. Es handelt sich um einen fortlaufenden Puffer mit Elementen, die zur Übernahme bereit sind – in der Regel ein oder zwei Sprints vor dem aktuellen Stand des Teams.

Rhythmus: Wie oft, wie lange

Es gibt zwar keine feste Regel, aber eine sinnvolle Standardvorgehensweise: eine kurze, wiederkehrende Sitzung als Anker, ergänzt durch kontinuierliche kleine Impulse dazwischen.

Bei einem zweiwöchigen Sprint führen die meisten Teams in der Mitte des Sprints eine einzige Refinement-Sitzung durch, die auf etwa eine Stunde begrenzt ist, und ergänzen diese ad hoc, sobald Fragen aufkommen. Wöchentliche Sitzungen funktionieren ebenso gut. Entscheidend ist weniger der genaue Zeitrahmen als vielmehr der Puffer: Das Ziel ist es, stets etwa den Arbeitsumfang eines Sprints an bereits vorbereiteten Aufgaben in der Warteschlange zu haben, damit bei der Planung niemals das Backlog geöffnet wird, ohne dass etwas gefunden wird, zu dem man sich verpflichten kann.

Zwei Fehlerquellen umrahmen das richtige Maß. Ist es zu wenig, wird die Planung zu einer Verfeinerung unter Zeitdruck – das Team klärt und unterteilt die Aufgaben unter Zeitdruck und verpflichtet sich zu Arbeiten, die es kaum versteht. Zu viel davon, und die Verfeinerung schwillt zu einer zweiten Planungssitzung an, in der über Details von Elementen gestritten wird, die möglicherweise nie in einen Sprint gelangen. Halten Sie sich an die Richtlinie des Scrum Guides von etwa 10 % der Kapazität, dann bleibt sie sinnvoll.

Wer leitet die Organisation?

Der Product Owner ist für das Backlog verantwortlich – Priorität, Zweck und das Warum jedes einzelnen Elements liegen in seiner Hand. Die Verfeinerung ist jedoch eine Teamleistung. Die Entwickler sind diejenigen, die die heiklen Fragen stellen, die Komplexität aufdecken, die niemand einkalkuliert hat, und die eigentliche Aufwandsschätzung vornehmen. Ein Product Owner, der die Verfeinerung alleine durchführt, erzeugt Elemente, die für genau eine Person glasklar sind, für alle anderen jedoch voller Überraschungen stecken, sobald die Planung beginnt.

Der Scrum-Master sorgt dafür, dass die Sitzung zeitlich begrenzt bleibt und verhindert, dass sie in eine „Design-by-Committee“-Situation abgleitet. Darüber hinaus gilt: Je weniger Zuschauer, desto besser.

Was „bereit“ bedeutet: Die Definition von „bereit“

Der Sinn der Verfeinerung besteht darin, Elemente bereit zu machen – und „bereit“ verdient ebenso eine Definition wie „fertig“. Eine vereinfachte Definition von „bereit“ ist die Checkliste, die ein Element erfüllen muss, bevor sich das Team bei der Planung darauf festlegt: Es ist verstanden, es ist klein genug, um in einem Sprint fertiggestellt zu werden, es verfügt über Abnahmekriterien, die Abhängigkeiten sind bekannt und es ist geschätzt.

Verfeinerung und Planung sind ein Staffellauf, keine Konkurrenz – die Verfeinerung bereitet die Elemente vor, die Planung legt sich auf sie fest. Falls die Grenze zwischen beiden in Ihrem Team verschwommen erscheint, wird sie in Sprint-Planung vs. Backlog-Verfeinerung klar dargelegt. Um zu erfahren, wo die Verfeinerung im Verhältnis zu den formellen Veranstaltungen angesiedelt ist, lesen Sie Scrum-Veranstaltungen vs. Zeremonien.

Häufig gestellte Fragen

Was versteht man unter Backlog-Verfeinerung?

Die fortlaufende Tätigkeit, Product-Backlog-Elemente für die Bearbeitung vorzubereiten: Klärung der Bedeutung jedes einzelnen Elements, Aufteilung großer Elemente, Hinzufügen von Abnahmekriterien, Einschätzung des Aufwands und Neuordnung nach Priorität. Dies geschieht kontinuierlich während des gesamten Sprints, sodass sich das Team, sobald ein Element die Planungsphase erreicht, ohne Widerstände dazu verpflichten kann.

Ist die Backlog-Verfeinerung eine Scrum-Zeremonie?

Nein – im Scrum Guide wird dies nicht als Veranstaltung aufgeführt. Es handelt sich um eine fortlaufende Aktivität, nicht um ein festes Meeting, und laut Scrum Guide sollte sie nicht mehr als etwa 10 % der Kapazität der Entwickler in Anspruch nehmen. Die meisten Teams widmen ihr jedoch eine wiederkehrende Sitzung und behandeln sie wie eine Zeremonie, da das Auslassen dieser Aktivität die Sprintplanung ins Chaos stürzen würde.

Was ist der Unterschied zwischen Backlog-Grooming und Backlog-Verfeinerung?

Keine – es handelt sich um dieselbe Aktivität. „Grooming“ ist der ursprüngliche Begriff; die Scrum-Community wechselte zu „Refinement“, da „Grooming“ unglückliche Assoziationen hervorgerufen hat. Viele Teams verwenden nach wie vor den Begriff „Grooming“. Die Arbeit ist in beiden Fällen identisch.

Wie oft sollten Sie das Backlog überarbeiten?

Kontinuierlich, mit einer kurzen, regelmäßig stattfindenden Sitzung als Anker – in der Regel einmal pro Woche oder einmal in der Mitte eines Sprints bei einem zweiwöchigen Rhythmus, zeitlich auf etwa eine Stunde begrenzt. Das Ziel ist ein fortlaufender Puffer an bereiten Elementen, der in der Regel ein oder zwei Sprints im Voraus reicht, sodass die Planung stets auf gutes Material zurückgreifen kann.

Wer ist für die Verfeinerung des Backlogs zuständig?

Der Product Owner ist für das Backlog verantwortlich und legt Prioritäten und Ziele fest, doch die Verfeinerung ist eine Teamaufgabe – die Entwickler stellen die Fragen, decken verborgene Komplexitäten auf und nehmen die Aufwandsschätzung vor. Ein Product Owner, der die Verfeinerung allein vornimmt, erstellt Elemente, die nur für eine Person Sinn ergeben und alle anderen bei der Planung überraschen.