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 vor dem Sprint, in dem sie umgesetzt werden sollen, vorzubereiten: Dabei geht es darum, die Bedeutung jedes einzelnen Elements zu klären, zu große 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 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, doch sie wie eines 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 Planung des Sprints, 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 erfolgt dies in vier Schritten, die kontinuierlich ablaufen:

• Präzisieren Sie dies. Formulieren Sie „das Onboarding verbessern“ so um, dass eine klare Absicht und Akzeptanzkriterien zum Ausdruck kommen, anhand derer das Team die Umsetzung überprüfen kann.
• Aufteilung. 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 „Aufteilung von User Stories“.
• Umfang. Einigen Sie sich auf eine gemeinsame Schätzung in Story-Points, 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 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: Ihr Ziel ist es, stets etwa den Arbeitsumfang eines Sprints an fertigen 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 unter Zeitdruck und verpflichtet sich zu einer Arbeit, 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 – Sitzungszeit, die keinen Nutzen bringt. Halten Sie sich an die Richtlinie des Scrum Guides von etwa 10 % der Kapazität, dann bleibt sie nützlich.

Wer leitet die Einrichtung?

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 tatsächliche Aufwandsschätzung vornehmen. Ein Product Owner, der die Verfeinerung allein durchführt, erzeugt Elemente, die für genau eine Person glasklar sind, für alle anderen jedoch voller Überraschungen, sobald die Planung beginnt.

Der Scrum-Master sorgt dafür, dass die Sitzung im Zeitrahmen 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 einfache 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 Akzeptanzkriterien, die Abhängigkeiten sind bekannt und es ist geschätzt.

Verfeinerung und Planung sind ein Staffellauf, keine Konkurrenz. Bei der Verfeinerung werden Elemente vorbereitet, bei der Planung werden diese festgeschrieben. Sollte die Grenze zwischen beiden in Ihrem Team unklar erscheinen, wird sie durch den Vergleich von Sprintplanung und Backlog-Verfeinerung deutlich gemacht. Um zu erfahren, wo die Verfeinerung im Verhältnis zu den formellen Veranstaltungen angesiedelt ist, lesen Sie bitte den Abschnitt „Scrum-Veranstaltungen vs. Zeremonien“.

Häufig gestellte Fragen

Was versteht man unter Backlog-Verfeinerung?

Der fortlaufende Prozess, Produkt-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 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 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 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 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 für eine Person Sinn ergeben, alle anderen bei der Planung jedoch überraschen.