Backlog Refinement Meeting Agenda: 60 Minuten, fünf Blöcke und die Regel, was draußen bleibt

Warum Refinement ohne Timebox ausufert

Die meisten Backlog-Refinement-Meetings sterben einen langsamen Tod durch Scope Creep. Was als 45-minütiger Abgleich zu Ticketdetails beginnt, wird zur einstündigen Architekturdebatte. Dazu kommen Schätzungen für Stories, die noch niemand geschrieben hat, und eine Neuverhandlung der Roadmap. Am Ende ist nichts refined.

Das hat einen strukturellen Grund. Der Scrum Guide beschreibt Refinement als fortlaufende Aktivität und gibt kein Format vor. Das ist bewusst so. In der Praxis erfindet deshalb jedes Team sein eigenes Meeting. Ein Meeting ohne Struktur gehört nach zehn Minuten der Person, die am lautesten redet.

Der Scrum Guide von 2017 nannte noch eine Obergrenze: Refinement verbrauche „in der Regel nicht mehr als 10 % der Kapazität des Development Teams“. In späteren Fassungen ist die Zahl verschwunden, Scrum-Trainer zitieren sie trotzdem weiter. Als Deckel taugt sie, ich halte sie allerdings für großzügig. Teams mit guter Vorbereitung kommen mit einer festen Stunde pro Woche aus. Teams ohne Vorbereitung kommen mit keiner Zeitmenge aus.

Das typische Muster ohne Timebox kenne ich aus Dutzenden Teams: Drei Items fressen fast die gesamte Diskussionszeit, ein Dutzend andere sieht vor dem Sprint Planning niemand an. Gegen genau dieses Muster richtet sich die Agenda in diesem Artikel. Was Refinement grundsätzlich ist und warum es sich lohnt, steht im Leitfaden zum Backlog Refinement und auf der Methodenseite. Allgemeine Moderationstipps für die Sitzung findest du in Backlog Refinement: How to Facilitate an Effective Session. Hier geht es um den Ablauf einer einzelnen Stunde.

Grooming oder Refinement: Der Unterschied in einem Absatz

„Grooming“ war in der frühen Scrum-Praxis der informelle Begriff für das Aufräumen des Backlogs: umsortieren, Veraltetes löschen, ein bisschen Ordnung schaffen. Mit der Zeit wurde „Refinement“ zum offiziellen Begriff im Scrum Guide, und Scrum.org hat „Grooming“ auch wegen seiner unerfreulichen Nebenbedeutung im Englischen aus Glossar und Trainingsmaterial gestrichen. Viele Teams benutzen beide Wörter heute synonym. Für eine Agenda zählt der funktionale Unterschied: Grooming klingt nach passiver Pflege, Refinement nach gemeinsamer, aktiver Vorbereitung konkreter Items. Diese Agenda behandelt Refinement deshalb als Arbeitssitzung mit Eintrittskriterien. Das Aufräumen erledigt der Product Owner allein und vorher.

Wie sich Refinement vom Sprint Planning unterscheidet

Sprint Planning ist ein formales Scrum-Event mit fester Timebox am Anfang jedes Sprints. Heraus kommen ein Sprint Goal und ein Sprint Backlog. Refinement läuft während des Sprints, hat keine vorgeschriebene Kadenz und produziert klarere, grob geschätzte Items.

Die Leitfrage ist jeweils eine andere. Im Refinement lautet sie: Verstehen wir dieses Item gut genug, um es zu schätzen und irgendwann einzuplanen? Im Sprint Planning: Welche der bereits verstandenen Items ziehen wir in diesen Sprint, und wie setzen wir sie um? Wer beides vermischt, sprengt die Timebox des Plannings. Nach meiner Erfahrung ist das der häufigste Grund, warum Plannings überziehen.

Mike Cohn beschreibt dasselbe von der anderen Seite: Teams, die Refinement auslassen, entdecken die Unbekannten live im Planning. Ich habe das oft gesehen. Ein Team geht mit halbfertigen Stories in ein zweistündiges Planning und verbringt die ersten 30 Minuten damit, Stories zu schneiden und Akzeptanzkriterien nachzuschärfen. Diese halbe Stunde fehlt dann für die Frage, wie der Sprint laufen soll.

Was der Product Owner vorher vorbereitet

Ob ein Refinement gelingt, steht zu großen Teilen vor dem Termin fest. Der Product Owner bringt mit:

• eine geordnete Kandidatenliste, typischerweise im Umfang von ein bis zwei Sprints
• bekannten Kontext pro Item: Mockups, Abhängigkeiten, verwandte Tickets
• eine Markierung für Items mit offenen Fragen, die erst Stakeholder beantworten müssen
• eine Trennung in „bereit fürs Refinement“ und „braucht vorher Discovery“

Den letzten Punkt empfiehlt auch Roman Pichler: Items ohne minimale Problembeschreibung gehören in ein separates Discovery-Gespräch. Wenn der PO seine Items so vorsortiert, kann ich als Moderator die zweite Kategorie komplett überspringen. Das spart mehr Zeit als jede Moderationstechnik.

Hilfreich ist, dem PO die Eintrittskriterien schriftlich vorab zu geben. Dann prüft er selbst, bevor das Team es in der Sitzung tun muss. Ich schicke sie zwei Tage vor dem ersten Termin mit, als kurze Checkliste mit vier Punkten.

Eintrittskriterien pro Item

Eintrittskriterien sind eine leichtgewichtige Form der Definition of Ready. Ein Item muss sie erfüllen, bevor es Diskussionszeit bekommt. Dieser Satz hat sich in vielen Teams bewährt:

1. Es gibt eine User Story oder eine klare Problembeschreibung in einem Satz.
2. Akzeptanzkriterien sind entworfen, auch wenn sie noch unvollständig sind.
3. Das Item hängt an keiner offenen Architekturentscheidung und keiner ungeklärten externen Abhängigkeit.
4. Es passt grob in einen Sprint oder ist ausdrücklich zum Schneiden markiert.

Der Nutzen zeigt sich im Moderationsgespräch. Ohne Kriterien muss ich im Moment abwägen, ob ein Item reif ist, und in solchen Ermessensfragen driftet ein Meeting in die Debatte. Mit Kriterien sage ich: „Punkt drei ist offen, nächstes Item.“ Das ist sachlich, und niemand fühlt sich persönlich abgewiesen.

Eine Warnung aus der Praxis: Die Kriterien müssen vom Team kommen. Wenn PO oder Scrum Master sie vorgeben, akzeptieren die Entwicklerinnen und Entwickler sie in der Sitzung nicht. Sie sind diejenigen, die beurteilen, ob sie ein Item schätzen können. Eine halbe Stunde in der nächsten Retro reicht, um den ersten Entwurf gemeinsam zu schreiben.

Die 60-Minuten-Agenda in fünf Blöcken

• Minuten 0–5: Zweck der Sitzung nennen, die Regel für das, was draußen bleibt, laut vorlesen, Item-Reihenfolge mit dem PO bestätigen. Über die Reihenfolge wird hier nicht diskutiert.
• Minuten 5–15: Die obersten vier bis fünf Items gegen die Eintrittskriterien prüfen, etwa zwei Minuten pro Item. Was durchfällt, geht mit einem konkreten Auftrag zurück an den PO.
• Minuten 15–45: Vertiefte Diskussion und Schätzung der Items, die bestanden haben. Eins nach dem anderen, mit einer strikten Timebox von acht bis zehn Minuten pro Item. Realistisch schafft ihr drei.
• Minuten 45–55: Zu große Items schneiden und die Formulierung der Akzeptanzkriterien festziehen.
• Minuten 55–60: Entscheidungen zusammenfassen, Parkplatzthemen mit Verantwortlichen versehen, nächsten Termin bestätigen.

Drei vollständig bereite Items pro Stunde klingt nach wenig. Bei wöchentlichem Refinement sind das sechs pro Zwei-Wochen-Sprint. Für die Teams mit fünf bis sieben Entwicklern, die ich begleitet habe, lag das nah an der Menge, die sie im folgenden Sprint ohnehin gezogen haben. Wer regelmäßig mehr braucht, schneidet seine Stories vermutlich zu klein oder refined zu weit in die Zukunft.

Für die Schätzung selbst nehme ich, was das Team kennt. Planning Poker funktioniert, für grobe Größen reicht oft T-Shirt Sizing.

Ein Timer pro Block

Eine Gesamtdauer von 60 Minuten verhindert kein Überziehen. Gruppen dehnen Diskussionen auf die verfügbare Zeit aus. Atlassian beschreibt Timeboxing als agiles Gegenmittel, wirksam wird es aber erst mit einem sichtbaren Timer pro Block und pro Item, den alle im Blick haben. Bei acht Minuten pro Item unterbreche ich beim Signal mit: „Wir parken das und klären es außerhalb.“ Diese eine Gewohnheit rettet mehr Refinements als alles andere, was ich kenne.

Der Parkplatz hängt sichtbar am Whiteboard oder liegt im geteilten Board. Mit ihm kann ich eine Idee anerkennen, ohne ihr die Timebox zu opfern. Jedes Parkplatzthema bekommt am Ende einen Namen und ein Datum. Ohne beides wird der Parkplatz zum Friedhof.

Warum eine eingehaltene Agenda auch eine Vertrauensfrage ist, habe ich in Your Agenda Is a Promise ausführlicher beschrieben.

Die Regel für das, was draußen bleibt

Diese Regel lese ich zu Beginn jeder Sitzung vor. Sie umfasst Lösungsdesign, Schätzungen ohne Story und Roadmap-Debatten.

Lösungsdesign

Refinement endet bei der Frage: Verstehen wir das Problem und die grobe Größe? Wie genau gebaut wird, gehört in einen technischen Spike oder ein eigenes Design-Gespräch. Der Grund ist praktisch. Eine Architekturdebatte kann nur ein Teil des Raums sinnvoll führen, der Rest wartet und schaut auf das Handy. Wenn ein Entwickler sagt „Wir könnten das auf drei Arten bauen“, antworte ich: „Dann machen wir daraus einen Spike, und ihr kommt mit einer Empfehlung zurück.“

Schätzungen ohne Story

Ein Item ohne Story und ohne Akzeptanzkriterien wird nicht geschätzt. Eine solche Zahl hat keine Grundlage. Schlimmer ist, was danach passiert: Platzhalter-Schätzungen tauchen Monate später als Zusage auf. Bei einem Zahlungsteam eines Onlinehändlers habe ich erlebt, wie eine im Refinement hingeworfene 13 für ein namenloses Epic auf einer Folie für den Lenkungsausschuss landete, als verbindlicher Aufwand. Wer ein Item ohne Story schätzen will, bekommt von mir die Gegenfrage: Was genau schätzen wir?

Roadmap- und Priorisierungsdebatten

Was im nächsten Quartal gebaut wird oder ob die Strategie kippt, klären PO und Führung außerhalb dieses Termins. Refinement übernimmt die Reihenfolge, die der PO mitbringt, und macht die nächsten Items bereit. Wer im Team grundsätzliche Zweifel an der Priorisierung hat, bringt sie ins Gespräch mit dem PO oder in die Sprint Review. Die Zweifel sind oft berechtigt, der Ort ist falsch.

Moderationsgewohnheiten, die die Agenda halten

Die Moderation braucht einen Namen. Oft ist das der Scrum Master, es kann aber auch jemand anderes sein. Die Person darf nicht gleichzeitig die Prioritäten des PO oder eine technische Position vertreten. Wer inhaltlich mitstreitet, kann die Timebox nicht glaubwürdig halten.

Die Agenda wird jedes Mal neu angesagt, auch beim vierzigsten Termin. Das wirkt redundant. Es gibt mir aber die soziale Erlaubnis, in Minute 23 einzugreifen, ohne willkürlich zu wirken, denn die Regel stand am Anfang im Raum.

Die Agenda bleibt die ganze Zeit sichtbar. Vor Ort hängt sie am Whiteboard, remote teile ich einen Tab mit Agenda, Timer und Parkplatz. In Workshop Weaver habe ich die fünf Blöcke einmal als Vorlage mit Timeboxen angelegt und befülle sie pro Termin nur noch mit den aktuellen Items. Teams, die aus dem Gedächtnis moderieren, fragen deutlich öfter, wo man gerade steht.

Am Ende steht ein kurzes schriftliches Protokoll: Welche Items sind jetzt bereit, welche wurden geschnitten, welche geparkt. Der PO pflegt das direkt nach der Sitzung ins Backlog ein, solange alle es noch im Kopf haben.

Fazit: Drei Sprints unverändert testen

Diese Agenda ist eine Disziplin. Die 60 Minuten und die Regel für das, was draußen bleibt, schützen die Aufmerksamkeit des Teams für die eine Aufgabe, für die Refinement da ist: die nächsten Items bereit machen. So gehst du vor:

1. Mit dem Team die eigene Definition of Ready klären und daraus die Eintrittskriterien ableiten. Der Leitfaden zum Backlog Refinement hilft, sie an euren Kontext anzupassen.
2. Dem PO die Kriterien schriftlich geben, zwei Tage vor dem ersten Termin.
3. Die Agenda drei Sprints lang unverändert fahren, Timer pro Block inklusive.
4. Erst danach die Timeboxen justieren, anhand der Protokolle: Wie viele Items wurden pro Sitzung bereit, wie viele landeten auf dem Parkplatz?

Wer schon nach der ersten Sitzung an den Blöcken schraubt, misst vor allem, wie ungewohnt der Timer für das Team noch ist.