"Wie gutes Backlog Refinement wirklich aussieht"

Backlog Refinement ist kein Event im Scrum Guide. Das war es nie. Die Ausgabe von 2020 erwähnt es einmal, beiläufig, als fortlaufende Aktivität, die bis zu 10 % der Teamkapazität in Anspruch nehmen kann. Es wird kein Format, keine Häufigkeit, keine Dauer und kein Facilitationsansatz vorgeschrieben. Es wird lediglich festgestellt, dass der Product Backlog verfeinert werden muss – und der Rest bleibt dem Team überlassen.

Diese fehlende Vorschrift hat eine außerordentliche Vielfalt an Praktiken hervorgebracht, die ein gemeinsames Problem teilen: Sie fokussieren auf die Aktivität statt auf das Ergebnis. Teams führen Refinement-Sessions durch. Sie schätzen Stories. Sie splitten Epics. Sie stellen Fragen und fügen Akzeptanzkriterien hinzu. Und dann kommen sie unvorbereitet ins Sprint Planning, die Session zieht sich, und alle fragen sich, warum Planning immer schmerzhaft ist.

Der Zweck von Refinement ist nicht, Refinement durchzuführen. Der Zweck ist, Sprint Planning schnell, entscheidungsfreudig und auf gemeinsamer Verstehensgrundlage zu machen. Jede Refinement-Aktivität sollte an diesem Zweck gemessen werden.

---

Der Einstieg: Das vierstündige Sprint Planning, das neunzig Minuten hätte dauern sollen

Das Muster ist erkennbar. Sprint Planning ist für zwei Stunden angesetzt. Die erste Story wird vorgestellt. Das Team stellt Fragen, die Wochen zuvor hätten gestellt werden sollen. Der Product Owner ist sich bei einigen Akzeptanzkriterien unsicher. Jemand bringt eine Abhängigkeit auf, die niemand gemappt hatte. Die Schätzdiskussion zeigt, dass zwei Teammitglieder völlig unterschiedliche Vorstellungen davon haben, was die Story erfordert.

Das wiederholt sich mit der zweiten Story. Und der dritten. Nach neunzig Minuten hat das Team Stories für einen Sprint geplant und ist von der kognitiven Last erschöpft, Dinge zu verstehen, die hätten im Voraus verstanden werden sollen.

Vier Stunden später ist der Sprint geplant. Alle sind müde. Das Commitment fühlt sich fragil an, weil die Hälfte der Stories nicht wirklich verstanden war, als sie akzeptiert wurden. Und im nächsten Sprint passiert es wieder.

Das ist kein Sprint-Planning-Problem. Es ist ein Refinement-Problem. Konkret: die Konsequenz eines Refinements, das die Aktivität als abgeschlossen betrachtete, als die Stories geschätzt waren, statt wenn das Team wirklich bereit war, sie zu planen.

---

Die Realität: Was Refinement falsch macht

Refinement als Schätzungstheater

Die häufigste Dysfunktion: Refinement-Sessions, die strukturell identisch mit Planning-Poker-Sessions sind. Stories werden vorgestellt. Das Team stellt ein paar Fragen. Punkte werden vergeben. Die Story wird als refined markiert. Die Session geht weiter.

Das Problem ist, dass Schätzen und Verstehen nicht dasselbe sind. Ein Team kann eine Story schätzen, die es nicht versteht – es schätzt nur mit geringer Konfidenz und hoher Varianz. Die in einer Planning-Poker-Session produzierte Zahl ist ein Maß für wahrgenommene Komplexität, nicht für echte Bereitschaft. Eine geschätzte, aber nicht verstandene Story wird im Planning und im Sprint Probleme schaffen.

Der Test für echte Bereitschaft ist nicht „Hat diese Story eine Schätzung?” Er ist: „Kann jedes Teammitglied in zwei Sätzen beschreiben, wie Done für diese Story aussieht – ohne das Ticket zu lesen?”

Wenn die Antwort nein lautet, wurde die Story nicht refined. Sie wurde geschätzt.

Refinement als einmaliges wöchentliches Meeting

Die zweite Dysfunktion: Refinement als Zeremonie mit einem festen Zeitslot behandeln. Dienstags um 15 Uhr, sechzig Minuten, dieselbe Gruppe von Menschen jede Woche. Diese Struktur erzeugt mehrere Probleme.

Erstens bündelt sie Refinement auf einen einzelnen Zeitpunkt, was bedeutet, dass Stories, die erhebliche Klärung benötigen, genauso viel Zeit bekommen wie Stories, die fast keine brauchen. Das Meeting-Format kann nicht zwischen ihnen unterscheiden.

Zweitens erzeugt es eine Warteschlange. Stories, die bis Dienstag nicht bereit sind, werden erst nächsten Dienstag refined. Wenn eine Story Input von einem Stakeholder benötigt, der diese Woche nicht verfügbar ist, wartet sie. Sprint Planning findet trotzdem statt.

Drittens erzeugt es ein falsches Gefühl von Abgeschlossenheit. Stories, die durch die Dienstagsession gegangen sind, fühlen sich refined an, auch wenn die grundlegenden Fragen nicht beantwortet wurden. Sie haben die Zeremonie durchlaufen. Die Zeremonie validiert sie, unabhängig davon, ob das Ergebnis erreicht wurde.

Gutes Refinement ist kontinuierlich, nicht zeremoniell. Es geschieht in Gesprächen zwischen Product Owner und einzelnen Teammitgliedern. Es geschieht in kurzen Austauschen nach dem Daily. Es geschieht asynchron in Ticket-Kommentaren. Die Dienstagsession – wenn sie existiert – ist ein Knoten in einem kontinuierlichen Prozess, nicht der Prozess selbst.

Refinement ohne die richtigen Menschen

Die dritte Dysfunktion: Stories ohne die Menschen zu verfeinern, die einbezogen werden müssen. Das klassische Beispiel: eine Refinement-Session, in der der Product Owner Geschäftsanforderungen an Entwickler präsentiert, die keinen Kontext für das zugrundeliegende Kundenproblem haben. Das Team schätzt auf Basis technischer Komplexität. Das „Warum” fehlt. Die Stories sind technisch umfangen, aber strategisch verwaist.

Gutes Refinement erfordert, wer auch immer das relevante Wissen für die diskutierten Stories hat. Für eine Story mit erheblichen UX-Implikationen: jemand, der die Nutzerforschung gesehen hat. Für eine Story mit komplexen Integrationsanforderungen: der Entwickler, der das betreffende System verantwortet. Für eine Story, die von einer noch nicht getroffenen rechtlichen Entscheidung abhängt: Klarheit, dass die Entscheidung existiert oder ein Plan, wann sie getroffen wird.

Die richtigen Menschen sind nicht immer zu einem festen Dienstagslot verfügbar. Das ist ein weiterer Grund, warum zeremonielles Refinement strukturell begrenzt ist.

„Eine verfeinerte Story ist nicht eine, die durch das Refinement-Meeting gegangen ist. Sie ist eine, bei der jede Person, die an ihr arbeiten wird, das erwartete Ergebnis, die relevanten Einschränkungen und die Definition of Done beschreiben könnte – bevor der Sprint beginnt.” Markus – agile-checksum.com

---

Der Checksum: Was Bereit wirklich bedeutet

Der Scrum Guide beschreibt ein Konzept namens Definition of Ready – eine optionale, teameigene Checkliste, die eine Story erfüllen muss, bevor sie für einen Sprint ausgewählt werden kann. Nicht alle Teams verwenden sie, und sie kann bürokratisch werden, wenn sie zu rigide angewendet wird. Als Denkrahmen für das, was Refinement erreichen soll, ist sie jedoch nützlich.

Hier ist, was eine echte Definition of Ready erfassen sollte:

1. Das Ergebnis ist in Nutzerbegriffen beschrieben, nicht in Implementierungsbegriffen.

„Als Nutzer möchte ich Suchergebnisse nach Datum filtern” ist eine User Story. „Datumsfilter auf Search-Endpoint mit ISO-8601-Parameter implementieren” ist eine technische Spezifikation. Letztere mag die richtige Detailtiefe für die Implementierung sein, aber Refinement sollte von Ersterer ausgehen – weil die Nutzerbegriffe den Kontext transportieren, der bestimmt, ob die Implementierung korrekt ist.

2. Die Akzeptanzkriterien sind spezifisch und testbar.

Nicht „der Filter funktioniert korrekt”, sondern: „Wenn ein Datumsbereich angewendet wird, werden nur Ergebnisse innerhalb dieses Bereichs zurückgegeben; Ergebnisse außerhalb des Bereichs erscheinen nicht; ein Empty State wird angezeigt, wenn keine Ergebnisse dem Filter entsprechen; der Filter bleibt über Pagination hinweg erhalten.” Jedes Kriterium sollte falsifizierbar sein – es sollte möglich sein, einen Test zu schreiben, der entweder besteht oder nicht.

3. Abhängigkeiten sind identifiziert und entweder gelöst oder explizit gemanagt.

Eine Story mit einer ungelösten Abhängigkeit ist nicht bereit. Sie mag schätzbar sein, aber sie ist nicht planbar. Abhängigkeiten sollten aufgelistet, ihr Status bekannt sein, und entweder ist die Abhängigkeit vor dem Planning gelöst oder es gibt einen expliziten Plan, wie sie im Sprint gemanagt wird.

4. Das Team hat ein technisches Gespräch geführt, nicht nur ein geschäftliches.

Der Product Owner beschreibt das Was. Die Entwickler müssen das Wie besprochen haben – zumindest auf hohem Niveau – bevor der Sprint beginnt. Nicht um ein detailliertes technisches Design zu erstellen, sondern um die Unbekannten zu identifizieren: die Teile der Implementierung, die Untersuchung erfordern, die Komponenten, die geändert werden müssen, die Risiken, die genannt werden müssen. Eine Story, die im Refinement nur ein geschäftliches Gespräch hatte, erfordert im Planning ein technisches. Das ist Planungszeit, die für Refinement-Arbeit ausgegeben wird.

5. Die Größe ist gut genug verstanden, um ein Commitment zu machen.

Das erfordert keine Story Points. Es erfordert, dass das Team genug Verständnis vom Umfang der Story hat, um ein vernünftiges Commitment einzugehen, sie innerhalb eines Sprints abzuschließen. Wenn die Antwort auf „Können wir das in einem Sprint abschließen?” lautet „das wissen wir ehrlich gesagt nicht” – braucht die Story mehr Refinement oder muss sie gesplittet werden.

---

Praxisbeispiele

Das Team, das alles in Ein-Punkt-Stories aufgeteilt hat

Ein Entwicklungsteam in einem Fintech-Unternehmen hatte einen besonderen Ansatz für Refinement gewählt: Jede Story wurde gesplittet, bis sie in eine Ein-Punkt-Schätzung passte. Die Logik war, dass kleine, klar definierte Stories einfacher abzuschließen und zu liefern sind. Das stimmt. In der Praxis wurde das Splitten jedoch ohne ausreichendes Verständnis durchgeführt – Stories wurden in kleinere Einheiten derselben Unsicherheit aufgeteilt.

Das Ergebnis war ein Backlog voller kleiner Stories, die einzeln einfach aussahen, aber gemeinsam ein System bildeten, das niemand gemappt hatte. Im Sprint Planning wählte das Team zehn Ein-Punkt-Stories aus, plante sie einzeln und entdeckte dann mitten im Sprint, dass Stories 4, 7 und 9 nicht unabhängig abgeschlossen werden konnten, wegen Integrationsabhängigkeiten, die im Refinement niemand aufgedeckt hatte.

Die Lösung war nicht, das Splitten aufzuhören. Es war die Anforderung, dass die Abhängigkeiten zwischen gesplitteten Stories explizit gemappt wurden, bevor eine von ihnen ins Planning eingeht. Wenn das Team die Integrationsreihenfolge nicht beschreiben konnte, war das Splitten verfrüht.

Der Product Owner, der alles alleine refined hat

Ein häufiges Anti-Muster: Der Product Owner verfeinert Stories eigenständig, schreibt detaillierte Akzeptanzkriterien, splittet Epics, fügt technische Notizen hinzu – und präsentiert die verarbeiteten Stories dann dem Team im Planning. Die Stories sind gut geschrieben. Die Akzeptanzkriterien sind klar. Und das Team hat kein Ownership davon, weil es nicht am Formen des Verständnisses beteiligt war.

Refinement, das isoliert stattfindet, produziert Stories, die extern kohärent, aber intern undurchsichtig sind – das Team kann lesen, was benötigt wird, hat aber nicht die Begründung, den Kontext oder die Einschränkungen verinnerlicht. Im Sprint entstehen Fragen, die hätten beantwortet werden sollen. Das Team delegiert Entscheidungen an den Product Owner, die es selbst treffen können sollte.

Gutes Refinement baut gemeinsames Verständnis auf. Es kann nicht von einer Person gemacht und dann an eine andere übergeben werden. Der Prozess des Fragens, Hinterfragens, Klärens und gelegentlichen Widersprechens ist kein Overhead – er ist der Mechanismus, durch den gemeinsames Verständnis entsteht.

---

Das Fazit: Refinement ist ein Qualitätstor, kein Meeting

Der Test der eigenen Refinement-Praxis ist nicht, wie viele Stories durchgelaufen sind. Es ist, wie sich Sprint Planning anfühlt.

Wenn Sprint Planning regelmäßig zu lang läuft, erhebliche Klärung erfordert, fragile Commitments produziert oder endet, ohne dass das Team sicher ist, wozu es sich verpflichtet hat – dann funktioniert das Refinement nicht. Nicht weil das falsche Format oder die falsche Schätztechnik verwendet wird, sondern weil die Stories, die ins Planning kommen, nicht wirklich bereit sind.

Die Lösung ist nicht mehr Refinement-Meetings hinzuzufügen. Es ist, die Definition of Done für das Refinement selbst zu ändern. Eine Story ist nicht refined, wenn sie besprochen wurde. Sie ist refined, wenn jede Person, die an ihr arbeiten wird, das erwartete Ergebnis beschreiben kann, ohne das Ticket zu lesen.

Den Checksum für die eigene Refinement-Praxis durchführen:

1. Wie viele Stories im letzten Sprint Planning erforderten erhebliche Klärung, die hätte vorab erledigt werden sollen? Wenn mehr als eine: der Refinement-Output ist nicht bereit genug.
2. Kann ein beliebiges Teammitglied jetzt die Akzeptanzkriterien für die fünf obersten Backlog-Items mit eigenen Worten beschreiben? Wenn nicht: das Verständnis ist dünner, als die Dokumentation vermuten lässt.
3. Was ist die Standardpraxis, wenn eine Story eine ungelöste Abhängigkeit hat? Wenn die Antwort lautet „wir planen sie trotzdem und lösen die Abhängigkeit im Sprint”: das ist kein Planning-Problem, es ist ein Refinement-Problem, das in der Sprint-Ausführung bezahlt wird.

---

Glossar: Verwendete Begriffe in diesem Artikel

• Product Backlog – Eine geordnete Liste von allem, was möglicherweise im Produkt benötigt wird, im Besitz und verwaltet vom Product Owner.
• Product Owner – Die Scrum-Verantwortlichkeit für die Maximierung des Produktwerts und die Verwaltung des Product Backlogs.
• Sprint Planning – Ein Scrum-Event, in dem das Team die Arbeit des kommenden Sprints plant.
• Sprint – Ein fester Zeitrahmen von 1–4 Wochen, in dem ein Scrum-Team ein potenziell auslieferbares Inkrement liefert.
• Definition of Done – Die gemeinsame Vereinbarung darüber, was „vollständig” für ein Produktinkrement bedeutet.
• Scrum Master – Die Scrum-Verantwortlichkeit für die Einführung von Scrum und die Unterstützung von Team und Organisation.