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

Die Backlog-Verfeinerung, die nach wie vor häufig als „Grooming“ bezeichnet wird, ist die fortlaufende Arbeit, Produkt-Backlog-Elemente für den Sprint vorzubereiten, in dem sie umgesetzt werden sollen: Dabei geht es darum, die Bedeutung jedes einzelnen Elements zu klären, zu umfangreiche Elemente aufzuteilen, Akzeptanzkriterien hinzuzufügen, ihren Umfang abzuschätzen und sie nach Priorität zu ordnen. Es handelt sich dabei weniger um ein einzelnes Meeting als vielmehr um eine Gewohnheit. Und genau darin liegt der subtile 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 Verfeinerung des Backlogs 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 nehmen die Verfeinerung als festen Termin in den Kalender auf 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, doch sie wie ein solches zu behandeln, ist in der Regel die richtige Entscheidung. Lässt man sie aus, verschwinden die Kosten nicht einfach. Sie verlagern sich lediglich in die Sprintplanung, wo sie teurer und zeitlich ungünstiger sind.

Was eine Verfeinerung tatsächlich bewirkt

Durch die Verfeinerung werden rohe Backlog-Elemente (oftmals 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 „die Einarbeitung 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 Teile 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 bekannt ist.
• Reihenfolge. Halten Sie den Auftragsbestand so sortiert, dass die wertvollsten und am weitesten fortgeschrittenen Aufgaben ganz oben stehen, wo sie bei der Planung zuerst 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 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 Arbeitsaufwand eines Sprints an vorbereiteten Aufgaben in der Warteschlange zu haben, damit bei der Planung niemals das Backlog geöffnet wird, ohne dass etwas gefunden wird, zu dessen Umsetzung 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. Das ist die Verfeinerungsseite der Zeremonienüberlastung, einer Sitzungszeit, die keinen Mehrwert bringt. Halten Sie sich an die Richtlinie des Scrum Guides von etwa 10 % der Kapazität, dann bleibt sie nützlich.

Wer leitet das Unternehmen?

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 es, die die heiklen Fragen stellen, die Komplexität aufdecken, die niemand einkalkuliert hat, und die eigentliche Schätzung vornehmen. Ein Produktverantwortlicher, der die Verfeinerung allein vornimmt, 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 im Zeitrahmen bleibt und verhindert, dass sie in eine Art „Design-by-Committee“ 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 dazu verpflichtet: 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 Rivalität. Bei der Verfeinerung werden Elemente vorbereitet, bei der Planung werden diese festgeschrieben. Falls die Grenze zwischen beiden in Ihrem Team unklar erscheint, wird sie in Sprint-Planung vs. Backlog-Verfeinerung deutlich dargestellt. Um zu erfahren, wo die Verfeinerung im Verhältnis zu den formalen Veranstaltungen angesiedelt ist, lesen Sie bitte Scrum-Veranstaltungen vs. Zeremonien.

Häufig gestellte Fragen

Was versteht man unter der Verfeinerung des Backlogs?

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 Verfeinerung des Backlogs eine Scrum-Zeremonie?

Nein. Im Scrum Guide wird dies nicht als Veranstaltung aufgeführt. Es handelt sich um eine fortlaufende Aktivität und 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 richten jedoch eine wiederkehrende Sitzung dafür ein und behandeln sie wie eine Zeremonie, da ein Auslassen dieser Sitzung 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 geweckt hatte. Viele Teams verwenden nach wie vor den Begriff „Grooming“. Die Arbeit ist in beiden Fällen identisch.

Wie oft sollten Sie das Backlog verfeinern?

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 aus fertiggestellten 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 Zielsetzungen 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.