Backlog Refinement: So pflegen Sie Ihren Product Backlog

Backlog Refinement (früher "Backlog Grooming" genannt) ist die wiederkehrende Praxis, die verhindert, dass Ihr Product Backlog zu einem Friedhof vager, veralteter und ungeschätzter Arbeit wird. Gut durchgeführt bedeutet es, dass Ihr Team in jedes Sprint-Planning-Meeting geht und bereits weiß, was die wichtigsten Einträge bedeuten, wie groß sie sind und warum sie wichtig sind.

Was ist Backlog Refinement?

Backlog Refinement ist der fortlaufende Prozess des Reviewens, Klärens, Schätzens und Neuordnens von Einträgen im Product Backlog, damit sie für bevorstehende Sprints bereit sind. Das Ziel ist sicherzustellen, dass der Backlog stets aktuell, priorisiert und für alle, die daran arbeiten werden, gut verstanden ist.

Wichtige Fakten: Backlog Refinement

• Teams, die regelmäßige Backlog-Refinement-Sessions abhalten, berichten von 20-30 % weniger Klärungsanfragen während des Sprint Plannings, laut dem State of Scrum Report der Scrum Alliance (2023).
• Der Scrum Guide empfiehlt, nicht mehr als 10 % der Sprint-Kapazität des Entwicklungsteams für das Backlog Refinement aufzuwenden (Scrum.org, 2020).
• In einer Umfrage von Digital.ai aus dem Jahr 2022 gaben 68 % der Agile-Teams an, dass schlecht geschätzte oder unzureichend definierte Backlog-Einträge zu den drei häufigsten Ursachen für Sprint-Misserfolge gehören.

Refinement ist keine formale Scrum Ceremony im Scrum Guide, sondern wird dort als laufende Aktivität aufgeführt. Aber die meisten leistungsstarken Teams behandeln es als wiederkehrendes Meeting, weil die Disziplin, es bewusst nach einem Zeitplan durchzuführen, dafür sorgt, dass es tatsächlich zur Gewohnheit wird.

Wer nimmt teil und wie oft?

Die Kernteilnehmer sind der Product Owner und das Entwicklungsteam. Der Product Owner bringt Geschäftskontext, Prioritäten und neue Anforderungen ein. Entwickler liefern die technische Perspektive: Sie sind es, die erkennen, dass ein "einfaches" Feature tatsächlich drei Dienste betrifft oder dass zwei Stories wirklich dieselbe Sache in unterschiedlicher Formulierung sind.

Stakeholder, UX-Designer und Fachexperten können hinzugezogen werden, wenn bestimmte Einträge ihren Beitrag erfordern. Den Kernkreis klein zu halten, hält die Session fokussiert.

Rhythmus: Die meisten Teams halten eine Refinement-Session pro Sprint ab, typischerweise in der Mitte des Sprints, damit die wichtigsten Einträge des nächsten Sprints vor dem Sprint Planning bereit sind. Ein zweiwöchiger Sprint unterstützt oft eine 60-90-minütige Refinement-Session. Manche Teams bevorzugen zwei kürzere Sessions von 45 Minuten über den Sprint verteilt, abhängig von Backlog-Fluktuation und Teamgröße.

Das 10%-Kapazitätslimit des Scrum Guides ist eine nützliche Obergrenze. Für einen zweiwöchigen Sprint mit einem fünfköpfigen Team entspricht das etwa vier Personenstunden insgesamt, was einer 45-60-minütigen Session entspricht.

Was passiert beim Backlog Refinement?

Refinement-Sessions umfassen fünf Hauptaktivitäten:

Große Einträge aufteilen. Epics und große User Stories werden in kleinere, sprint-gerechte Teile aufgeteilt. Eine Story, deren Umsetzung drei Wochen dauern würde, muss in drei oder vier unabhängige Stories umgewandelt werden, die jeweils innerhalb eines Sprints abgeschlossen werden können.

Akzeptanzkriterien und Details hinzufügen. Vage Einträge wie "Checkout-Flow verbessern" werden in konkrete, testbare Anforderungen umgewandelt. Was bedeutet "verbessert"? Schnellere Ladezeit? Weniger Schritte? Für welches Gerät? Das Team stimmt über Kriterien überein, bevor es sich verpflichtet.

Aufwand schätzen. Einträge werden mithilfe von Story Points oder einer anderen Schätzeinheit bewertet. Viele Teams verwenden Planning Poker, um konsensbasierte Schätzungen ohne Ankereffekt zu erreichen. Schätzungen sind am wertvollsten für die obersten zwei oder drei Sprint-Backlog-Einträge: weiter entfernte Einträge werden sich zu stark verändern, um genaue Schätzungen zu rechtfertigen.

Einträge neu ordnen. Prioritäten verschieben sich. Ein Feature, das letzte Woche Platz 15 hatte, kann nach einem Kundengespräch auf Platz 3 springen. Der Product Owner passt die Reihenfolge nach Wert, Risiko, Abhängigkeiten und Feedback an.

Veraltete Einträge entfernen. Einträge, die keinen Sinn mehr ergeben, weil sich der Markt verändert hat, das Feature in anderer Form geliefert wurde oder seit sechs Monaten unberührt geblieben ist, werden entfernt oder archiviert. Ein aufgeblähter Backlog ist ein Vertrauensproblem: Wenn das Team Hunderte von Einträgen sieht und weiß, dass die meisten nie gebaut werden, nimmt es die Liste nicht mehr ernst.

Backlog Refinement vs. Sprint Planning

Diese beiden Ceremonies werden oft verwechselt, weil beide den Backlog betreffen. Aber sie dienen unterschiedlichen Zwecken und finden zu unterschiedlichen Zeiten statt.

Betrachten Sie Refinement als die Vorbereitung und Sprint Planning als die Verpflichtung. Das Überspringen des Refinements macht Sprint Planning zu einer Rechercheeinheit, was für alle langsam und unbequem ist.

Vorteile des regelmäßigen Refinements

Schnelleres Sprint Planning. Wenn Einträge bereits geschätzt und klar definiert sind, dauert Sprint Planning 30-60 Minuten statt einen halben Tag. Das Team begegnet den Stories nicht zum ersten Mal.

Bessere Schätzungen. Die Schätzqualität verbessert sich, wenn Teams Einträge diskutieren, bevor der Sprint-Druck einsetzt. Es gibt Raum zum Nachfragen, Hinterfragen des Umfangs und zur Neukalibrierung.

Weniger Sprint-Unterbrechungen. Vage Anforderungen erzeugen Klärungsanfragen mitten im Sprint. Vorher verfeinerte Stories mit Akzeptanzkriterien und Sonderfällen reduzieren die "Warte, was bedeutet das eigentlich?"-Gespräche, die den Fluss unterbrechen.

Gemeinsames Produktverständnis. Entwickler, die am Refinement teilnehmen, bauen ein klareres mentales Modell der Produkt-Roadmap auf. Das macht sie besser darin, technische Abhängigkeiten zu erkennen, Risiken frühzeitig zu melden und einfachere Ansätze vorzuschlagen, bevor die Arbeit beginnt.

Gesündere Backlog-Hygiene. Regelmäßiges Bereinigen hält den Backlog handhabbar. Ein Team, das den Backlog jeden Sprint reviewt, bereinigt ihn auf natürliche Weise, was die Priorisierung erleichtert und die Planung glaubwürdiger macht.

Definition of Ready (DoR)

Die Definition of Ready ist eine gemeinsame Checkliste, die ein Backlog-Eintrag bestehen muss, bevor das Team ihn als für einen Sprint geeignet betrachtet. Sie ist das Backlog-Äquivalent der Definition of Done, da beide gemeinsame Standards schaffen, nur an verschiedenen Enden des Arbeitszyklus.

Eine typische Definition of Ready umfasst:

• Klarer Titel und Beschreibung: Die Story erklärt, was gebaut werden soll und für wen.
• Akzeptanzkriterien: Das Team weiß, was für diesen Eintrag "fertig" bedeutet.
• Geschätzte Größe: Der Eintrag wurde mithilfe von Story Points oder einem gleichwertigen Maß bewertet.
• Identifizierte Abhängigkeiten: Alle Hindernisse, externe Abhängigkeiten oder Vorgänger-Einträge sind dokumentiert.
• Passt in einen Sprint: Der Eintrag ist klein genug, um innerhalb eines Sprints abgeschlossen zu werden. Wenn nicht, muss er aufgeteilt werden.
• Design- oder UX-Artefakte beigefügt (falls zutreffend): Relevante Mockups, Spezifikationen oder API-Verträge sind verlinkt.

Die DoR ist kein bürokratisches Gate, sondern eine gemeinsame Vereinbarung, die das Team davor schützt, vage Arbeit in einen Sprint zu ziehen und in der Mitte der Woche festzustellen, dass niemand weiß, was sie bedeutet. Erfüllt ein Eintrag die DoR beim Refinement nicht, nimmt der Product Owner ihn zur weiteren Bearbeitung zurück, bevor die nächste Session beginnt.

So führen Sie eine Backlog-Refinement-Session durch

Schritt 1: Backlog vor dem Meeting vorbereiten

Der Product Owner reviewt vor Beginn der Session die obersten 20-30 Einträge. Er ergänzt fehlenden Kontext, markiert Einträge, die bereit für die Schätzung sind, und bringt neue Einträge ein, die seit der letzten Session hinzugekommen sind. Unvorbereitet in das Refinement zu gehen verschwendet die Zeit aller.

Schritt 2: Die Prioritätseinträge durcharbeiten

Beginnen Sie oben im Backlog und arbeiten Sie sich nach unten vor. Für jeden Eintrag erklärt der Product Owner den Kontext und das Ziel. Erklärungen kurz halten: Refinement ist keine Demo oder kein Design-Review, sondern eine Klarheitsprüfung.

Schritt 3: Klären und Akzeptanzkriterien hinzufügen

Das Team stellt Fragen. Was sind die Sonderfälle? Was passiert, wenn der Benutzer X tut? Gibt es Geräte- oder Browser-Einschränkungen? Der Product Owner oder ein Fachexperte antwortet. Abgestimmte Akzeptanzkriterien werden zur Story hinzugefügt, bevor fortgefahren wird.

Schritt 4: Aufwand mithilfe von Story Points schätzen

Sobald die Story klar ist, schätzt das Team. Verwenden Sie Planning Poker oder eine andere Konsensmethode, um Ankereffekte zu vermeiden. Wenn die Schätzungen stark divergieren, erklären die Personen mit der höchsten und niedrigsten Schätzung ihre Begründung: Dies deckt versteckte Komplexität oder fehlausgerichtete Annahmen auf.

Einträge, die zu groß zum Schätzen sind, werden zur Aufteilung markiert und kehren als kleinere Stories zu Schritt 2 zurück.

Schritt 5: Bereitschaft bestätigen und neu ordnen

Nach Diskussion und Schätzung bestätigen Sie, ob der Eintrag Ihre Definition of Ready erfüllt. Wenn ja, ist er für einen bevorstehenden Sprint geeignet. Wenn nicht, notieren Sie, was fehlt, und weisen Sie die Verantwortung für die Lücke zu. Bestätigen Sie abschließend die Prioritätsreihenfolge der obersten Einträge, bevor Sie die Session schließen.

Eine kurze Retrospektive am Ende, "Was hat diese Refinement-Session effektiv oder ineffektiv gemacht?", verbessert die Qualität über Zeit.

Häufige Fehler

Refinement als Sprint Planning behandeln. Manche Teams versuchen, sich während des Refinements auf Sprint-Einträge zu verpflichten. Das vermischt zwei verschiedene Entscheidungen: was bereit ist, bearbeitet zu werden, und wozu wir uns in diesem Sprint verpflichten. Halten Sie sie getrennt.

Zu weit im Voraus verfeinern. Erhebliche Zeit damit zu verbringen, Einträge zu schätzen und zu detaillieren, die 10+ Sprints entfernt sind, ist in der Regel verschwendete Mühe. Anforderungen ändern sich. Konzentrieren Sie sich auf die nächsten 2-3 Sprints mit Details; halten Sie weiter entfernte Einträge als grobe Ideen oder Epics.

Überspringen, wenn der Backlog "gut aussieht." Der Backlog fühlt sich nie wirklich gut an, bis er plötzlich zur Krise beim Sprint Planning wird. Refinement ist eine Disziplin, die die Krise verhindert, keine Reaktion darauf.

Nur der Product Owner nimmt teil. Wenn Entwickler nicht am Refinement teilnehmen, werden Schätzungen später unter Zeitdruck gemacht, technische Komplexität wird übersehen, und Stories kommen beim Sprint Planning mit Annahmen an, denen das Team nie zugestimmt hat. Alle Relevanten müssen im Raum sein.

Session zu lang laufen lassen. Sobald das Refinement 90 Minuten überschreitet, lässt die Aufmerksamkeit stark nach. Wenn Sie durch die Zeit brennen und noch Einträge unverfeinert sind, ist es besser, einen Folgetermin zu planen, als mit einem müden Raum weiterzumachen. Kürzere, häufigere Sessions funktionieren oft besser als ein langer monatlicher Marathon.

Alte Einträge nie bereinigen. Backlog-Einträge, die seit mehr als drei Monaten auf Position 40-150 sitzen, sollten hinterfragt werden. Wenn das Team nicht artikulieren kann, warum ein Eintrag noch relevant ist, archivieren Sie ihn. Sie können ihn jederzeit wiederherstellen.

Häufig gestellte Fragen

Wie lang sollte eine Backlog-Refinement-Session sein? Das 10%-Kapazitätslimit des Scrum Guides entspricht für einen zweiwöchigen Sprint etwa 60-90 Minuten. Manche Teams führen stattdessen zwei 45-minütige Sessions pro Sprint durch. Halten Sie es in einer einzigen Sitzung unter 90 Minuten, da die Qualität danach nachlässt.

Wem gehört das Backlog-Refinement-Meeting? Der Product Owner ist dafür verantwortlich, dass der Backlog in gutem Zustand ist, daher moderiert er das Refinement typischerweise oder co-moderiert es. Der Scrum Master unterstützt bei Prozess und Moderationsqualität. Aber Refinement funktioniert am besten, wenn es kollaborativ ist, nicht als Product-Owner-Monolog.

Was ist der Unterschied zwischen "bereit" und "verfeinert"? Ein verfeinerter Eintrag wurde diskutiert und hat Akzeptanzkriterien erhalten. Ein "bereiter" Eintrag hat die Definition of Ready bestanden: Er ist geschätzt, klein genug für einen Sprint und hat keine ungelösten Abhängigkeiten. Jeder bereite Eintrag ist verfeinert, aber nicht jeder verfeinerte Eintrag ist notwendigerweise bereit.

Sollten Designer am Backlog Refinement teilnehmen? Das hängt von der Art der Arbeit ab. Bei Stories mit erheblichen UX- oder visuellen Design-Überlegungen verhindert die Anwesenheit eines Designers Missverständnisse über den Umfang und vermeidet Design-Nacharbeit mitten im Sprint. Bei Backend- oder Infrastrukturarbeit ist ihre Zeit anderswo besser aufgehoben.

Wie oft sollte der Backlog bereinigt werden? Ein leichtes Review jeden Sprint (Entfernung klar veralteter Einträge) plus eine tiefere Überprüfung vierteljährlich funktioniert für die meisten Teams gut. Vierteljährliche Überprüfungen erfassen Einträge, die ohne dass es jemand bemerkt hat, an Relevanz verloren haben.

---

Backlog Refinement ist eine jener Praktiken, die leicht übersprungen werden können, wenn man beschäftigt ist, und doch ist es genau dann, wenn das Team beschäftigt ist, dass das Überspringen den größten Schaden anrichtet. Ein gut gepflegter Backlog trennt Teams, die mit Zuversicht sprinten, von Teams, die ständig Umfangsverwirrung bekämpfen. Bauen Sie die Gewohnheit frühzeitig auf, schützen Sie die Zeit, und die kumulativen Auswirkungen zeigen sich schnell in Ihrer Sprint-Planning-Qualität.

Weiterführende Lektüre

• Product Backlog: Struktur, Eigentümerschaft und Priorisierungstechniken
• Sprint Planning: wie Sie einen verfeinerten Backlog in eine Sprint-Verpflichtung umwandeln
• User Stories: Stories schreiben, die klar genug zum Verfeinern sind
• Story Points: Aufwandsschätzungseinheiten verstehen
• Planning Poker: konsensbasierte Schätztechnik für Refinement-Sessions
• Definition of Done: das Abschluss-Gegenstück zur Definition of Ready
• Daily Standup: Sprint-Ausführung nach dem Refinement ausgerichtet halten