Backlog Refinement

Das Ziel beim Backlog Refinement

Das Ziel beim Backlog Refinement ist es, die höher priorisierten Items im Backlog so vorzubereiten, dass sie sich gut für das Sprint Planning nutzen lassen. Dies führt in der Folge zur Verkürzung von Planungsmeetings bei gleichzeitiger Berücksichtigung aktueller Informationen.

Laut aktuellen Scrum Guide ist der Product Owner für das Product Backlog verantwortlich, als Konsequenz daraus ist er auch für das Refinement verantwortlich, selbst wenn er die Aufgabe delegiert und/oder Entwickler aktiv bei der Verfeinerung mitwirken.

Das Backlog Refinement im Scrum Guide

Das Backlog Refinement ist kein Event in Scrum wie bspw. das Daily Scrum oder das Sprint Planning, allerdings empfiehlt es sich, es als regelmäßige Aktivität oder Aufgaben durchzuführen. Der Scrum Guide 2017 formulierte es wie folgt:

„Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion”.

Der Scrum Guide 2020 verzichtet sowohl auf eine solch umfassende Beschreibung als auch auf eine Empfehlung bzgl. maximalem Aufwand. Tatsächlich wird das Refinement nur ein einziges Mal erwähnt: „Das Refinement des Product Backlogs ist der Vorgang, durch den Product‐Backlog‐Einträge in kleinere, präzisere Elemente zerlegt und weiter definiert werden. Dies ist eine kontinuierliche Aktivität, wodurch weitere Details wie Beschreibung, Reihenfolge und Größe ergänzt werden. Die Attribute variieren oft je nach Arbeitsumfeld“.

Unabhängig von den Unterschieden der verschiedenen Scrum Guide Versionen, geht es in der Praxis beim Backlog Refinement bzw. der Backlog Estimation um folgende Aspekte:

• Kontinuierlicher Prozess mit Product Owner und Entwicklungsteam
• Detaillierung des Product Backlogs also bspw. auch die Aufteilung eines Items in mehrere
• Schätzung der Backlog Items und Anpassung bestehender Schätzungen
• Reihenfolge der Backlog Items und Anpassung bestehender Prioritäten
• Löschen von Items, wenn sie obsolet werden
• Begutachtung und Überarbeitung der Backlog Items inklusive Aufnahme neuer Items
• Aufwandsbegrenzung auf nicht mehr als 10% der Gesamtkapazität des Entwicklungsteams
• Rechte des Product Owners, jederzeit Informationen zu aktualisieren

Best Practices beim Backlog Refinement

Best Practices beim Backlog Refinement umfassen eine Reihe von bewährten Ansätzen, um diese wichtige Tätigkeit effektiv zu gestalten. Obwohl der Scrum Guide die Verantwortung für das Backlog Refinement dem Product Owner zuschreibt und die Entwickler in der Mitwirkung sieht, ist es dennoch empfehlenswert, den Scrum Master in diesen Prozess einzubinden. Seine Rolle besteht unter anderem darin, steuernd einzugreifen, wenn Diskussionen länger dauern als vorgesehen. Hier bietet es sich an, Diskussionen pro User Story zeitlich zu begrenzen.

Eine gute Grundlage für die Definition hochwertiger User Storys ist der INVEST Ansatz von William Wake. Für die Pflege der Backlog Items eignet sich der DEEP Ansatz von Roman Pichler. Um den Überblick zu behalten und die Storys für das Team sichtbar zu machen, hat sich die Arbeit mit User Story Maps bewährt, beispielsweise durch die Visualisierung an einer Wand. Dies erleichtert die gemeinsame Erörterung von Akzeptanzkriterien und die Sicherstellung der Vollständigkeit der User Storys, die in naher Zukunft umgesetzt werden sollen.

Ein weiterer zentraler Punkt ist die gemeinsame Schätzung der Storys, beispielsweise mithilfe von Story Points, um deren Komplexität zu bewerten. Diskrepanzen in den Schätzungen können auf unterschiedliches Verständnis oder alternative Realisierungsansätze hinweisen. In solchen Fällen kann eine erneute Schätzung oder die vorherige Definition von Technical Storys oder Spike Storys hilfreich sein.

Im agilen Kontext ist die Verwendung von Timeboxes ein gängiges Mittel, um Projekten, Vorgängen und Aktivitäten klare zeitliche Grenzen zu setzen. Dabei ist es wichtig, die Dauer einer Timebox sinnvoll festzulegen. Beim Backlog Refinement jedoch steht die Aktualität der Backlog Items an oberster Stelle, da sie erheblichen Einfluss auf die weitere Entwicklung hat. Deshalb sollte diese Tätigkeit nicht abrupt beendet werden, nur weil die festgelegte Zeit abgelaufen ist. Der Fokus liegt darauf, die Qualität und Relevanz der Backlog Items sicherzustellen, um den weiteren Entwicklungsprozess optimal zu unterstützen.

Vorteile beim Backlog Refinement

Das Backlog Refinement bietet verschiedene Vorteile:

• Der Product Owner erhält Unterstützung bei der Pflege und Weiterentwicklung des Backlogs.
• Das Verständnis um Zusammenhänge und Prioritäten im Team steigt.
• Das Backlog spiegelt spätestens nach dem nächsten Refinement Meeting wieder den aktuellen Kenntnisstand wider.
• Unklarheiten lassen sich ansprechen und beseitigen.
• Aufwände im Sprint Planning werden reduziert, denn dort gilt es nicht mehr das „was“ sondern das „wie“ zu besprechen.
• Die Stimmung im Team wird durch die Zusammenarbeit gefördert, zumal unnötige Arbeiten bspw. durch die Entwicklung von inzwischen irrelevanten User Storys vermieden werden.

Tipps für das Backlog Refinement

Unternehmen stehen vor der Herausforderung, Backlog Refinements effizient zu planen und durchzuführen. Hierfür gibt es verschiedene Tipps:

• Die Vorbereitung ist Aufgabe des Product Owners. Idealerweise sind die demnächst anstehenden User Storys bereits periodisiert, denn dies spart allen Beteiligten viel Zeit. Der Product Owner muss das Meeting gut vorbereiten. Die wichtigen anstehenden Stories des Backlogs müssen priorisiert, klar verständlich und detailliert genug beschrieben sein (idealerweise nach dem INVEST-Ansatz und dem DEEP Ansatz).
• Es empfiehlt sich, Akzeptanzkriterien gemeinsam im Team zu definieren, denn dies führt zu einem besseren, gemeinsamen Verständnis der Beteiligten. Alternativ könnten die Kriterien auch nur vom Product Owner definiert werden; so liese sich zwar der Aufwand reduzieren, aber Verständnislücken könnten unter Umständen unentdeckt bleiben.
• Der Fokus im Backlog Refinement liegt nicht in der Aufwandsschätzung, sie ist lediglich ein Bestandteil von mehreren wie bspw. die Aufnahme von neuen User Storys, die Eliminierung von vorhandenen Items oder das Splitten von einzelnen User Storys.
• Häufig liest man von wöchentlichen Backlog Refinement, doch eine solche Frequenz macht nicht für jede Organisation Sinn. Besser wäre hier eine Orientierung an den eigenen Möglichkeiten und Vorstellungen. Dauert ein Sprint bspw. 4 Wochen, könnte es sinnvoll sein, alle 2 Wochen ein entsprechendes Meeting durchzuführen. Unabhängig von der Frequenz muss das Backlog Refinement natürlich immer vor dem nächsten Sprint Planning durchgeführt werden.
• Definieren Sie eine feste Dauer und nutzen Sie Ihren Scrum Master, denn er kann auf die Einhaltung der vereinbarten Regeln achten und sorgt so bspw. dafür, dass Meetings und Diskussionen in den Meetings nicht zu viel Zeit beanspruchen. Dauert das Backlog Refinement länger als ursprünglich geplant, ist es meist besser, einen neuen Termin zu vereinbaren.
• Für viele Unternehmen ist Traceability und Revisionssicherheit beim Arbeiten mit User Storys wichtig. Hier gibt es verschiedene Lösungen von Softwareherstellern, die Ihnen beim Digitalisieren bzw. der digitalen Nachbereitung Ihrer Ergebnisse helfen können. Es ist Geschmacksache, ob Sie den gesamten Prozess von Anfang an Digitalisieren oder mit haptischen User Storys und Story Mapping arbeiten wollen.

Impuls zum Diskutieren:

Wie oft sollte das Backlog Refinement durchgeführt werden?

Hinweise:

* Das im deutschsprachigen Raum häufig gebräuchliche „Backlog Grooming“ oder „Scrum Grooming“ wird im englischsprachigen Raum nicht mehr verwendet. Bis vor ca. 20 Jahren wurde Grooming als Pflege verstanden, mit dem bspw. Pferde oder Hunde sehr sorgsam gekämmt wurden. Seither hat sich die Bedeutung verschoben und Grooming wird verknüpft mit dem Gedanken an Erwachsene, die sich an Kinder heranmachen. Wir verwenden daher bewusst Backlog Refinement.

Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für weitere Tipps aus der Praxis interessieren, dann testen Sie unseren wöchentlichen Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter!

Hier finden Sie einen interessanten Podcast zum Backlog Refinement.

Eine Empfehlung zum praktischen Umgang mit Backlogs finden Sie im Beitrag: Boost your Backlog.

Hier finden Sie ergänzende Informationen aus unserer Rubrik Wissen kompakt:

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.