Backlog Refinement: So leiten Sie das Meeting

Das Sprint Planning für Sprint 43 hätte eine Stunde dauern sollen. Nach vierzig Minuten hing Lenas Team immer noch an Punkt eins fest: dem Ablauf für abgelaufene Karten, den das Sprint Review drei Tage zuvor an die Spitze des Backlogs gesetzt hatte. Niemand wusste, wie der Zahlungsanbieter mit einer abgelaufenen Karte umgeht, also konnte niemand sagen, wie groß die Arbeit war. (Lenas Team ist ein fiktives Beispiel, kein reales Team.)

Das Problem war nicht die Planung. Das Problem war, dass sich niemand den Eintrag vor dem Meeting angesehen hatte.

Genau dafür gibt es das Backlog Refinement. Dieser Leitfaden zeigt, was der Scrum Guide von 2020 tatsächlich dazu sagt (geprüft im November 2026), eine Agenda für 60 Minuten mit einer getakteten Schleife pro Eintrag, wie oft Sie sich treffen sollten, einen Ready-Check mit fünf Fragen, den Vergleich von Backlog Refinement und Sprint Planning sowie ein einseitiges Protokoll zum Kopieren.

Was ist Backlog Refinement?

Backlog Refinement ist die laufende Arbeit, die obersten Einträge im Product Backlog aufzuteilen, zu klären, zu ordnen und in ihrer Größe einzuschätzen, damit sie klein und klar genug für das nächste Sprint Planning sind. Der Scrum Guide von 2020 nennt es „Product Backlog Refinement“ und beschreibt es als das Zerlegen und weitere Definieren von Product-Backlog-Einträgen in kleinere, präzisere Einträge.

Den folgenden Punkt lassen die meisten Leitfäden aus: Backlog Refinement ist kein Scrum-Event. Der Guide nennt fünf Events: den Sprint, das Sprint Planning, das Daily Scrum, das Sprint Review und die Sprint-Retrospektive. Refinement steht nicht auf dieser Liste. Der Guide nennt es eine „laufende Aktivität“, und Scrum.org sagt es deutlich: Product Backlog Refinement ist kein vorgeschriebenes Event in Scrum.

Sie müssen also kein Refinement-Meeting abhalten. Die meisten Teams tun es trotzdem, weil eine feste Stunde dafür sorgt, dass es auch passiert.

Was der Scrum Guide über Backlog Refinement sagt

Der Guide widmet dem Thema drei Sätze beim Product Backlog und eine Zeile im Abschnitt zum Sprint: Das Product Backlog wird nach Bedarf verfeinert. Zwei dieser Sätze zählen im Raum am meisten:

• Was es ergänzt: Refinement fügt Details hinzu, etwa eine Beschreibung, eine Reihenfolge und eine Größe.
• Wer die Größe festlegt: Die Developers, die die Arbeit erledigen, sind für die Größenschätzung verantwortlich. Der Product Owner kann sie beeinflussen, indem er ihnen hilft, Zielkonflikte zu verstehen und abzuwägen.

Wir haben den englischen Originaltext des Guides nach den Wörtern durchsucht, die Teams meist mit diesem Meeting verbinden. „Grooming“ kommt nicht vor. Ebenso wenig „Definition of Ready“, „Story Points“, „estimate“ oder „User Story“. Das sind verbreitete Praktiken, und sie können funktionieren, aber sie sind keine Scrum-Regeln. Der einzige Bereitschaftstest im Guide lautet: Einträge, die das Scrum Team innerhalb eines Sprints fertigstellen kann, gelten als bereit für die Auswahl.

Die Formulierung hat sich über die Jahre verändert, wie die Versionsgeschichte des Scrum Guides zeigt:

Damit ist auch die Frage Backlog Refinement oder Grooming beantwortet: dieselbe Praxis, und „Grooming“ ist der Name, den der Guide 2013 gestrichen hat.

Agenda für das Backlog Refinement Meeting (60 Minuten)

Der Guide überlässt Ihnen das Format, deshalb hier eine Agenda für das Backlog Refinement in einer Stunde. Die Zeiten sind unser Vorschlag, keine Scrum-Regel. Der Product Owner verschickt die Liste mit vier oder fünf Einträgen zwei Arbeitstage vorher, damit die Developers sie zuerst lesen können.

Sollen die Entscheidungen festgehalten werden, während alle reden? Legen Sie ParrotNotes auf den Tisch und erhalten Sie nach dem Stoppen der Aufnahme eine Zusammenfassung und Aufgaben. ParrotNotes kostenlos testen.

1. Mit dem Ziel beginnen

Der Product Owner sagt, welchem Product Goal diese Einträge dienen und welcher Eintrag am ehesten das nächste Sprint Goal trägt. Dann zeigt er die Liste. Alles, was nicht darauf steht, wartet bis nächste Woche.

2. Die Schleife pro Eintrag

Führen Sie jeden Eintrag durch dieselben fünf Schritte und halten Sie eine Uhr sichtbar:

1. Warum (2 Min.): Der Product Owner sagt, für wen der Eintrag ist und welches Problem er löst.
2. Fragen (3 Min.): Die Developers fragen, was sie wissen müssten, um ihn umzusetzen.
3. Aufteilen (2 Min.): Passt er nicht in einen Sprint, wird er in kleinere Einträge zerlegt, von denen jeder für sich nützlich bleibt.
4. Größe (2 Min.): Die Developers, die die Arbeit erledigen, schätzen die Größe mit der Methode, die Ihr Team nutzt.
5. Reihenfolge und Verantwortliche (2 Min.): Der Product Owner ordnet den Eintrag ins Backlog ein, und jede offene Frage bekommt eine verantwortliche Person und ein Datum vor dem Planning.

Ein Eintrag, der 15 Minuten erreicht, endet dort. Notieren Sie, was fehlt, bestimmen Sie eine verantwortliche Person und gehen Sie zum nächsten.

3. Die Spitze des Backlogs prüfen

Zählen Sie, wie viele Einträge jetzt den Ready-Check unten bestehen. Viele Teams möchten etwa zwei Sprints Vorlauf haben, damit das Planning nie bei null beginnt. Fehlt etwas, wählt der Product Owner aus, was nächste Woche dran ist.

4. Zusammenfassen und abschließen

Lesen Sie Aufteilungen, Größen und offene Fragen laut vor und verschicken Sie das Protokoll noch am selben Tag.

Wie oft und wie lange?

Der Guide von 2020 nennt keine Zahl. Die Angabe von 2017, nicht mehr als 10 % der Kapazität, ist gestrichen, taugt aber weiterhin als Obergrenze. So viel ergibt sie pro Person bei Arbeitstagen von acht Stunden:

Eine Stunde pro Woche plus etwas Lesezeit vorab liegt deutlich unter der alten Grenze. Auch ProdPad empfiehlt eine Sitzung von etwa einer Stunde. Sieben Personen eine Stunde lang sind sieben Personenstunden pro Woche, und unser Meetingkosten-Rechner zeigt, was das kostet.

Legen Sie die Sitzung nicht auf den Tag vor dem Sprint Planning. Mitte der Woche bleibt Zeit, offene Fragen zu klären, und unser Leitfaden zum Besprechungsrhythmus hilft Ihnen, sie zwischen Ihre anderen wiederkehrenden Meetings zu legen.

Wer nimmt am Backlog Refinement teil, und wer leitet es?

Der Guide sagt nicht, wer es leitet. Scrum.org schreibt, dass selbstorganisierte Teams festlegen, wie oft Refinement stattfindet und wer an jeder Sitzung teilnimmt. In der Praxis sieht das so aus:

Sie brauchen nicht jede Woche alle Developers. Zwei oder drei, die die Einträge voraussichtlich umsetzen, können das Refinement übernehmen, solange der Rest das Ergebnis im Backlog sehen kann.

Der Ready-Check: fünf Fragen pro Eintrag

Viele Teams nennen das eine „Definition of Ready“. Der Guide kennt keine, also sehen Sie diese Fragen als Checkliste, nicht als Hürde:

1. Können wir in einem Satz sagen, für wen der Eintrag ist und warum?
2. Lässt er sich innerhalb eines Sprints fertigstellen? Das ist der Test aus dem Guide selbst.
3. Sind sich die Developers, die ihn umsetzen, über die Größe einig?
4. Wissen wir, wie wir prüfen, ob er fertig ist? Ein oder zwei Beispiele reichen.
5. Ist jede offene Frage beantwortet oder hat eine verantwortliche Person mit Datum vor dem Planning?

Ein Eintrag, der an einer Frage scheitert, ist einfach noch nicht bereit, und das Protokoll hält fest, was fehlt.

Backlog Refinement vs. Sprint Planning

Das Refinement bereitet Einträge vor, damit sie verstanden werden. Das Sprint Planning wählt aus, welche bereiten Einträge in den Sprint kommen und warum. Das eine speist das andere.

Der Guide erlaubt eine gewisse Überschneidung: Im Sprint Planning darf das Scrum Team die Einträge weiter verfeinern. Ein paar klärende Fragen dort sind in Ordnung. Ein ganz neues Epic dort zu schätzen, hat Lenas Montag gesprengt.

Wenn das Backlog Refinement ausufert

Halten Sie diese Sätze bereit:

Das funktioniert auch außerhalb der Softwareentwicklung. Stellen Sie sich ein fiktives Eventteam aus fünf Personen vor, das „Den Kundentag im Frühjahr durchführen“ verfeinert. Das passt nicht in einen Sprint von zwei Wochen, also teilt das Team es auf: Location buchen, Agenda entwerfen und Einladungen verschicken. Zwei der drei bestehen den Ready-Check noch in derselben Stunde, und die Frage zur Location bekommt eine verantwortliche Person und eine Frist bis Donnerstag.

Vorlage für das Backlog Refinement: das einseitige Protokoll

Der Guide verlangt kein Protokoll, aber das Sprint Planning braucht diese Antworten. Kopieren Sie es in das Dokument Ihres Teams.

PROTOKOLL BACKLOG REFINEMENT
Team:              Datum:             Moderation:
Product Owner:     Anwesend:

1. VERFEINERTE EINTRÄGE
   Eintrag | Aufgeteilt in | Größe | Bereit? (ja / noch nicht)

2. OFFENE FRAGEN
   Frage | Verantwortlich | Bis wann

3. GEÄNDERTE REIHENFOLGE
   Eintrag | Neue Position | Warum

4. SPITZE DES BACKLOGS
   Bereite Einträge:  Etwa wie viele Sprints Vorlauf:

5. NÄCHSTE SITZUNG
   Datum:             Mitzubringende Einträge:

Hier ausgefüllt für das fiktive Team, am Mittwoch nach jenem langen Montag:

PROTOKOLL BACKLOG REFINEMENT
Team: Checkout-Team     Datum: 25. Nov.    Moderation: Lena
Product Owner: Ana      Anwesend: Tomas, Priya, Sam

1. VERFEINERTE EINTRÄGE
   Apple Pay | Button im Checkout; gespeicherte Adresse in Apple Pay
             | M; M | ja; noch nicht
   Gespeicherte Karte entfernen | nicht aufgeteilt | S | ja
   Kartenreihenfolge im Checkout | nicht aufgeteilt | S | noch nicht

2. OFFENE FRAGEN
   Braucht unser Zahlungsanbieter eine neue Händlereinstellung
   für Apple Pay? | Tomas | 27. Nov.
   Wirkt sich die Gebührenänderung im Januar auf die
   Kartenreihenfolge aus? | Mei | 27. Nov.

3. GEÄNDERTE REIHENFOLGE
   Gespeicherte Karte entfernen | Hoch auf 2 | Jede Woche Support-Tickets

4. SPITZE DES BACKLOGS
   Bereite Einträge: 5   Etwa wie viele Sprints Vorlauf: 1,5

5. NÄCHSTE SITZUNG
   Datum: 2. Dez.        Mitzubringende Einträge: Kartenreihenfolge, Belege

Abschnitt 2 rettet das nächste Planning. Übertragen Sie diese Fragen in Ihr Protokoll zum Nachverfolgen von Aufgaben, damit jemand sie vor Montag prüft.

Sollten Sie das Backlog Refinement aufnehmen?

Eine Aufnahme erlaubt der Moderation, auf die Uhr zu achten statt zu tippen, und abwesende Developers können nachhören, warum ein Eintrag aufgeteilt wurde. Fragen Sie vorher, sagen Sie, was Sie aufbewahren und wer es sieht, und hören Sie auf, wenn jemand widerspricht. Die Regeln zur Einwilligung unterscheiden sich je nach Ort, und unser Leitfaden zu One-Party-Consent in den USA erklärt die US-Grundlagen.

ParrotNotes nimmt auf einem Smartphone oder Mac im Raum auf, ohne Meeting-Bot, und liefert ein Transkript, eine Zusammenfassung und Aufgaben, die Sie ins Protokoll übernehmen können. Stand November 2026 erlaubt der kostenlose Plan 30 Minuten pro Aufnahme und 100 Minuten pro Monat. Pro (19,99 USD pro Monat oder 14,99 USD pro Monat bei jährlicher Zahlung) bietet 3.000 Minuten pro Monat und Aufnahmen bis zu 3 Stunden, genug für jede Sitzung.

Im kostenlosen Plan nehmen Sie die Schleife für Ihre zwei schwierigsten Einträge und die Zusammenfassung am Ende auf. Das sind etwa 30 Minuten, und genau dort fallen die Entscheidungen. Laden Sie ParrotNotes herunter und testen Sie es in Ihrer nächsten Sitzung.

Machen Sie das Refinement zur ruhigen Stunde vor dem Planning

Gutes Backlog Refinement macht das Sprint Planning langweilig, im besten Sinne. Denken Sie daran, dass der Guide es als Aktivität behandelt, nicht als Event, also passen Sie es an Ihr Team an. Verschicken Sie die Einträge zwei Tage vorher, führen Sie jeden durch dieselben fünf Schritte, beenden Sie jeden Eintrag nach 15 Minuten, nutzen Sie den Ready-Check und verschicken Sie noch am selben Tag eine Seite.

Lenas Team hat das Refinement auf Mittwochvormittag verlegt. Beim Planning für Sprint 44 kam Apple Pay aufgeteilt, geschätzt und mit Tomas' Antwort im Anhang. Das Team wählte den Eintrag in vier Minuten aus und beendete das Planning zwanzig Minuten früher.