Backlog Refinement facilitieren: Agenda, Rollen und Methoden

Vielleicht läuft dein Sprint Planning gar nicht wegen der Planung so lange, sondern weil im Refinement etwas fehlt. Genauer: weil das Refinement schlecht facilitiert ist.

Viele Scrum-Teams haben Backlog Refinement zu einem Verwaltungsakt gemacht. Der Product Owner liest Tickets vor, das Team nickt, ein paar Story Points werden geschätzt, fertig. Heraus kommt ein Backlog, der auf dem Papier gefüllt aussieht und im Sprint Planning auseinanderfällt, weil niemand die richtigen Fragen gestellt hat.

Dieser Artikel richtet sich an alle, die Refinement als das nutzen wollen, was es sein kann: die ergiebigste Facilitation-Gelegenheit, die ein Scrum-Team pro Sprint hat.

Was Refinement leisten soll

Der Scrum Guide 2020 beschreibt Refinement als fortlaufende Aktivität, in der Product Backlog Items zerlegt und genauer definiert werden, etwa mit Beschreibung, Reihenfolge und Größe. Product Owner und Entwicklungsteam überprüfen die Items gemeinsam: Sie verfeinern, schätzen und ordnen sie. Das klingt einfach.

Schwierig wird es beim Wort „gemeinsam". In der Praxis dominiert häufig der Product Owner die Diskussion, während das Team zuhört. Roman Pichler betont, dass Refinement eine gemeinsame Aufgabe von Product Owner und Entwicklungsteam sein sollte. Wenn der PO das Meeting leitet und den Inhalt vorgibt, bleibt dem Team kaum Raum, technische Risiken, Abhängigkeiten und Wissenslücken einzubringen.

Ein Meeting zu leiten und es zu facilitieren sind deshalb zwei verschiedene Dinge. Ein Facilitator schafft die Bedingungen, unter denen das Team gemeinsam denkt. Er gibt keine Antworten vor, sondern stellt Fragen.

Die DEEP-Kriterien als Diagnose

Mike Cohn und Roman Pichler nutzen das DEEP-Akronym als Gesundheits-Check für Backlogs. Die vier Dimensionen:

• Detailed appropriately: Nahe Items sind fein genug für einen Sprint, ferne Items bleiben bewusst grob.
• Estimated: Jedes Item hat eine relative Größenschätzung.
• Emergent: Der Backlog entwickelt sich laufend weiter und ist kein eingefrorener Plan.
• Prioritized: Die Reihenfolge spiegelt aktuellen Business-Wert, Risiko und Abhängigkeiten wider.

Für die Facilitation ist DEEP nützlich, weil jede Dimension eine andere Aktivität verlangt. Story Splitting und Akzeptanzkriterien bedienen „Detailed Appropriately", Schätzübungen „Estimated", offene Fragen zu neuen Erkenntnissen „Emergent" und Priorisierungsübungen „Prioritized".

Am häufigsten wird „Emergent" vernachlässigt. Teams verbringen die ganze Session mit bekannten Items und fragen nie: Was hat sich seit letzter Woche verändert? Was haben wir vom Kunden gehört? Welche technischen Schulden haben wir entdeckt? Nach drei Sprints bildet der Backlog dann die Realität nicht mehr ab.

Meine Empfehlung: Prüfe vor jeder Session, welche DEEP-Dimension gerade am schwächsten ist, und baue die Agenda danach auf.

Rollen in der Session

Drei Rollen haben in Refinement-Sessions klare Aufgaben:

• Der Product Owner bringt priorisierte Items und den Kontext zu den Akzeptanzkriterien mit.
• Das Entwicklungsteam bringt technische Machbarkeit, Abhängigkeiten und Aufwandsschätzungen ein.
• Der Scrum Master oder ein designierter Facilitator hält den Prozess: Zeit, psychologische Sicherheit, ausgewogene Redeanteile.

Eine der häufigsten Dysfunktionen ist der „Hero PO": Wer zugleich für den Inhalt verantwortlich ist und die Sitzung leitet, kann nicht neutral facilitieren. Wer am stärksten an einem Ergebnis hängt, eignet sich in der Praxis am wenigsten dafür, den Prozess zu verantworten.

Einen Versuch wert ist es, die Facilitator-Rolle im Team rotieren zu lassen. Das stärkt das gemeinsame Ownership für den Backlog und verhindert Engpässe, wenn der PO einmal nicht da ist.

Gäste wie UX-Researcher oder Stakeholder können für bestimmte Items dazukommen. Wer aber ohne klare Rolle die ganze Session dabei ist, macht aus der gemeinsamen Arbeitssitzung eine Präsentation, und Entwickler halten technische Bedenken zurück.

Eine Agenda in fünf Phasen

Eine gut facilitierte Refinement-Session lässt sich in fünf Phasen gliedern:

• Minuten 0–5: Check-in und Framing. Statt „Wir reviewen heute den Backlog" lieber fragen: Was wollen wir am Ende dieser Session wissen, das wir jetzt noch nicht wissen?
• Minuten 5–15: Neue Items sammeln. Bevor bestehende Items drankommen, Raum für Neues schaffen: Was ist neu? Was hat sich verändert?
• Minuten 15–45: Story-Readiness-Review mit strukturierten Fragen und Story Splitting für die nächsten Items.
• Minuten 45–65: Schätzung mit einer zeitbegrenzten Methode wie Planning Poker oder T-Shirt Sizing.
• Minuten 65–75: Priorisierungs-Check mit Dot Voting oder Stack-Ranking, um die Reihenfolge vor dem Abschluss zu bestätigen.

Die Zeitbox für jeden Abschnitt dient weniger der Effizienz als der Orientierung: Sie zeigt, dass dieses Gespräch Grenzen hat. Das macht Menschen eher bereit, etwas beizutragen, weil sie wissen, dass sie nicht darin festhängen werden.

Der Check-in zu Beginn wird im Refinement am meisten unterschätzt. Eine einzige Frage („In einem Wort: Wie bereit fühlt sich dieser Backlog für dich an?") zeigt dem Facilitator, wie es um das Team steht, bevor es inhaltlich losgeht. Ohne diese Frage fehlt ihm diese Information.

Bewährt hat sich ein „Three-Question Gate" für jedes Backlog-Item mit drei Prüffragen: Wissen wir, wie „Done" aussieht? Wissen wir, wer der Nutzer ist? Gibt es erkennbare Blocker? Items, die das Gate nicht bestehen, gehen ohne Schätzung zurück zum PO. Das wirkt streng, erspart dem Team aber spekulative Schätzungen.

Schätzen: Planning Poker und T-Shirt Sizing

Der Wert des Schätzens im Refinement liegt weniger in der Zahl am Ende als im Gespräch, das dabei entsteht.

Planning Poker ist so angelegt, dass alle ihre Karte gleichzeitig aufdecken. Das verhindert Anchoring: Niemand lässt sich von der Zahl beeinflussen, die jemand anderes zuerst nennt. Zeigt eine Entwicklerin eine 2 und ein Kollege eine 13, ist das das wertvollste Ergebnis der Übung. Es zeigt, dass im Raum unterschiedliche Vorstellungen existieren, die vor dem Sprint-Start geklärt werden müssen.

Facilitatoren, die die Senior-Entwicklerin ihre Karte zuerst zeigen lassen oder unausgesprochen signalisieren, welche Größe der PO erwartet, betreiben „Estimation Theater". Das sieht aus wie Planning Poker, bringt aber keine neue Information.

T-Shirt Sizing (XS/S/M/L/XL) passt besser zu frühen Backlog-Phasen oder großen Mengen an Items, bei denen Fibonacci-Punkte eine Genauigkeit vortäuschen würden, die es nicht gibt. Sinnvoll ist oft beides nacheinander: zuerst T-Shirt Sizing als schneller Durchgang über alle Kandidaten für den Sprint, dann Planning Poker nur für die nächsten Stories, die eine feinere Schätzung brauchen.

Priorisierung sichtbar machen

Mit Dot Voting lassen sich die Prioritäten der Gruppe schnell sichtbar machen, ohne lange Debatte. Jedes Teammitglied verteilt eine feste Anzahl Punkte (3–5) auf die Items, die es für am wichtigsten hält. Das Ergebnis ist sofort lesbar und zeigt Präferenzen, die in einer mündlichen Diskussion kaum auftauchen würden.

Während des Dot Votings achtet der Facilitator darauf, dass niemand vorher für sein Item wirbt. Erst wird still und unabhängig abgestimmt, danach gemeinsam über das Ergebnis gesprochen, nicht umgekehrt.

Nach der Abstimmung kommen die wichtigsten Fragen: „Was überrascht euch an diesem Ergebnis?" und „Gibt es etwas in der unteren Hälfte, das wir möglicherweise unterschätzen?" Damit fallen Fälle auf, in denen die Punkte eher Bekanntheit als echte Priorität widerspiegeln.

Techniken für mehr Beteiligung

Stille Lesezeit stammt aus Amazons Meeting-Kultur und funktioniert im Refinement gut: Statt dass der PO ein Ticket vorliest, bekommt das Team 2–3 Minuten, um es selbst zu lesen. So haben alle dieselbe Information im gleichen Tempo aufgenommen, und das Framing des PO prägt die Interpretation des Teams weniger.

Vorformulierte Fragen helfen dem Facilitator, keine Suggestivfragen zu stellen. Statt „Versteht ihr alle diese Story?" (Antwort: Nicken) besser: „Was müsste wahr sein, damit das in einem Sprint fertig wird?" oder „Was ist die riskanteste Annahme in dieser Story?"

Auch die Uhrzeit spielt eine Rolle. Refinement-Sessions am Freitagnachmittag oder direkt nach dem Sprint-Demo-Termin liefern erfahrungsgemäß schwächere Ergebnisse. Als Facilitator solltest du dich für sinnvolle Termine einsetzen. Lässt die Energie mitten in der Session sichtbar nach, hilft ein kleiner Perspektivwechsel: „Formuliere diese Story einmal aus der Sicht des Nutzers, der sie zum ersten Mal benutzt."

Workshop Weaver bietet für solche Momente eine Bibliothek strukturierter Facilitation-Methoden, die sich direkt in eine Refinement-Agenda einbauen lassen, von Energizern bis zu Priorisierungs-Templates.

Typische Fehler und Gegenmaßnahmen

Der häufigste Fehler: Das Team fängt an, das Feature zu designen, statt die Story zu verfeinern. Ein erfahrener Facilitator spricht das direkt an: „Ich merke, wir sind gerade in eine Design-Diskussion gerutscht. Lass uns das festhalten und als separaten Spike einplanen." Sonst wird aus einem 60-minütigen Refinement eine dreistündige Design-Session.

Der zweite Klassiker ist ein aufgeblähter Backlog. Items, die seit sechs Sprints dort liegen und nie priorisiert werden, deuten auf ein Facilitation-Problem hin. Ein regelmäßiges Aufräumen mit Dot Voting und einer klaren Frage („Würden wir das in den nächsten drei Sprints wirklich angehen?") hält den Backlog als strategisches Werkzeug brauchbar.

Wenn sich Sessions regelmäßig im Kreis drehen, hilft eine facilitierte Retrospektive zum Refinement-Prozess selbst. Das Team gestaltet die Struktur der nächsten Session mit, statt eine neue Agenda vorgesetzt zu bekommen. Daran hält es sich deutlich länger als an Methoden-Vorgaben von außen.

Refinement als Hebel im Sprint

Backlog Refinement ist mehr als eine Aufwärmübung. An keiner anderen Stelle im Sprint kann Facilitation so viel bewirken: falsche Annahmen früh aufdecken, Komplexität sichtbar machen und ein gemeinsames Verständnis herstellen, bevor das Sprint Planning jede Diskussion unter Zeitdruck setzt.

Mein Vorschlag für deine nächste Session: Prüfe sie gegen die vier DEEP-Dimensionen und gegen die Agenda in diesem Artikel. Welche Dimension vernachlässigt ihr regelmäßig? Und was passiert in eurer Session dort, wo eigentlich Facilitation stattfinden sollte?

Wenn du die Methoden vertiefen willst: Planning Poker, T-Shirt Sizing und Dot Voting sind die praktischen Werkzeuge für diese Struktur, jeweils mit genauen Anweisungen, wann und wie du sie einsetzt.