Backlog Refinement moderieren: Welche Fragen müssen vor dem Planning geklärt sein?
Share
Backlog Refinement moderieren heißt, ein gemeinsames Verständnis über relevante Arbeit herzustellen und offene Unsicherheiten gezielt zu verkleinern. Vor dem Sprint Planning sollte ausreichend klar sein, welchen Nutzen ein Eintrag hat, wie er sinnvoll zugeschnitten ist und welche wichtigen Fragen noch offen sind. Refinement verlangt keine vollständige Vorplanung jeder technischen Einzelheit.
Vielleicht endet euer Refinement regelmäßig in einer langen Lösungsdiskussion zu einem einzigen Eintrag. Die nächsten Themen bleiben liegen, während die eigentliche Nutzerfrage noch unklar ist. Oder ihr geht zwanzig Einträge oberflächlich durch und entdeckt im Planning dieselben offenen Punkte erneut. Ein klarer Gesprächsrahmen kann beide Muster sichtbar machen.
Refinement ist eine laufende Tätigkeit
Der Scrum Guide beschreibt Refinement als das Verfeinern und Zerlegen von Product-Backlog-Einträgen. Es ist kein zusätzliches vorgeschriebenes Scrum Event mit einer eigenen festen Timebox. Ihr könnt gemeinsame Termine nutzen, aber auch kleinere Gespräche und gezielte Klärungen zwischen diesen Terminen.
Bevor ihr euren Ablauf verändert, prüft das gemeinsame Verständnis. Mit unseren Scrum Cards könnt ihr Rollen, Events und Artefakte auslegen und besprechen, wie Product Backlog, Planning und die Arbeit im Sprint zusammenhängen. Die 40 Karten dienen dem Lernen und enthalten zusätzlich ein Planning-Poker-Deck für eine Person.
Wenn alle gleichzeitig physisch schätzen sollen, benötigt jede schätzende Person ein eigenes Deck. Ein Produktset versorgt also nicht automatisch die gesamte Gruppe mit Schätzkarten. Für die folgende Fragenrunde reicht dagegen ein gemeinsames Lernkartenset, sofern alle die Inhalte gut sehen und besprechen können.
Mit wenigen relevanten Einträgen vorbereiten
Wählt Einträge aus, die voraussichtlich bald wichtig werden oder deren Unsicherheit früh geklärt werden muss. Es ist selten hilfreich, das gesamte Product Backlog in gleicher Tiefe auszuarbeiten. Weit entfernte Ideen können sich noch stark verändern.
Für jeden ausgewählten Eintrag sollten der gewünschte Nutzen und die aktuell bekannte Ausgangslage kurz beschrieben sein. Bringt vorhandene Rückmeldungen oder Beispiele mit. Wenn eine wichtige Person eine fachliche Frage beantworten muss, klärt ihre Teilnahme oder einen geeigneten Rückfrageweg vorher.
Die Moderation braucht kein fertiges Lösungskonzept. Sie sollte aber wissen, welche Art von Ergebnis für den Termin sinnvoll ist: ein kleinerer Zuschnitt, eine geklärte Annahme, eine nachvollziehbare Größeneinschätzung oder ein konkreter Rechercheauftrag. So lässt sich am Ende beurteilen, ob die Arbeit weitergekommen ist.
Die Fragen in einer hilfreichen Reihenfolge stellen
| Gesprächsschritt | Leitfrage | Woran ihr Fortschritt erkennt |
|---|---|---|
| Nutzen verstehen | Für wen soll sich was verbessern? | Ein nachvollziehbarer Anwendungsfall |
| Erwartung konkretisieren | Woran erkennen wir das gewünschte Verhalten? | Gemeinsame Beispiele und wichtige Grenzen |
| Zuschnitt prüfen | Welcher kleinere Teil wäre bereits nützlich? | Eine handhabbare Einheit |
| Unsicherheit prüfen | Was wissen wir noch nicht und warum ist es relevant? | Benannte offene Fragen |
| Größe besprechen | Was macht die Arbeit aufwendig oder unvorhersehbar? | Nachvollziehbare Einschätzung |
| Nächsten Schritt wählen | Ist genug klar oder braucht es gezielte Klärung? | Ein eindeutiger weiterer Weg |
Diese Reihenfolge ist eine Moderationshilfe, kein vorgeschriebenes Scrum-Schema. Wenn ihr bei einer späteren Frage erkennt, dass der Nutzen unklar ist, geht zurück. Eine schnelle Schätzung ohne gemeinsames Verständnis spart meist nur scheinbar Zeit.
Am Beispiel diskutieren statt abstrakt zustimmen
Bitte um einen konkreten Fall: Wer beginnt mit welchem Problem und was sollte anschließend möglich sein? Ergänzt einen Grenzfall. Bei einer Suchfunktion könnte das eine Eingabe ohne Treffer sein, bei einer internen Anfrage eine fehlende Pflichtinformation.
Wenn das Team unterschiedliche Antworten gibt, ist das ein nützlicher Befund. Ihr habt eine Annahme entdeckt, bevor die Umsetzung sie teuer macht. Notiert den Unterschied und entscheidet, ob ihr ihn im Raum klären könnt oder eine weitere Perspektive braucht.
Achtet darauf, fachliche Klarheit nicht mit der vollständigen Vorentscheidung der Umsetzung zu verwechseln. Die Developers müssen Raum behalten, während der Arbeit passende Lösungen zu entwickeln. Refinement soll ausreichend Orientierung schaffen, nicht jede Entdeckung im Sprint verhindern.
Einen großen Eintrag sinnvoll schneiden
Ein fiktives Team möchte eine neue Auftragsübersicht bauen. Der erste Eintrag enthält Filter, Export, Benachrichtigung und unterschiedliche Berechtigungen. Eine lange Schätzrunde wird wenig helfen, solange unklar ist, welcher erste nutzbare Teil wirklich gebraucht wird.
Das Team fragt nach dem wichtigsten Anwendungsfall. Es stellt fest, dass der Service zunächst überfällige Aufträge erkennen und deren zuständige Person sehen muss. Daraus entsteht ein kleinerer erster Zuschnitt. Die übrigen Möglichkeiten bleiben im Product Backlog und werden später anhand weiterer Erkenntnisse betrachtet.
Ob dieser Schnitt tatsächlich nutzbar ist, muss das Team am Produkt und seinen Qualitätsbedingungen prüfen. Ein kleiner technischer Teilschritt ist nicht automatisch ein sinnvoller Nutzenschnitt. Die gemeinsame Frage lautet: „Was kann die vorgesehene Person damit anschließend besser tun?“
Schätzen als Gespräch über Unterschiede nutzen
Wenn ihr Planning Poker verwendet, lasst zunächst unabhängig schätzen. Sprecht dann über deutlich unterschiedliche Einschätzungen. Welche zusätzliche Arbeit sieht eine Person? Welche Annahme ist bei einer anderen Person noch offen? Die Zahl ist der Anlass für dieses Gespräch, nicht sein wichtigstes Ergebnis.
Verzichtet darauf, einen Durchschnitt als automatisch richtige Schätzung zu behandeln. Vielleicht hat eine Person eine notwendige Qualitätsprüfung berücksichtigt, die andere noch nicht. Dann braucht ihr ein gemeinsames Verständnis. Vielleicht ist die Unsicherheit so groß, dass zuerst eine begrenzte Untersuchung sinnvoll ist.
Die Scrum.org-Ressource zu Refinement-Fragen betont unter anderem das gemeinsame Verständnis und die laufende Klärung. Übernehmt praktische Richtwerte aus solchen Ressourcen nicht als zusätzliche verbindliche Scrum-Regeln. Euer konkreter Bedarf ergibt sich aus dem Produkt und den offenen Fragen.
Drei Gründe, eine Diskussion zu unterbrechen
Erstens fehlt eine Information, die niemand im Raum liefern kann. Benennt dann die Frage, die zuständige Person und einen Rückmeldetermin. Zweitens diskutiert ihr Details einer Lösung, obwohl der Zweck unklar ist. Geht zur Nutzenfrage zurück. Drittens ist der Eintrag aktuell nicht relevant genug, um die nötige Klärung zu rechtfertigen. Dann muss er nicht sofort vollständig ausgearbeitet werden.
Ein guter Abbruch ist kein Scheitern. Er verwandelt eine diffuse Diskussion in einen konkreten nächsten Schritt. Wichtig ist, dass die offene Frage später wiedergefunden wird. „Müssen wir noch klären“ ohne Zuständigkeit führt beim nächsten Termin lediglich zur Wiederholung.
Für eine erste gemeinsame Sitzung könnt ihr 45 Minuten für drei ausgewählte Einträge reservieren. Das ist ein Testformat, keine feste Vorgabe. Beendet nach jedem Eintrag kurz mit dem erreichten Stand und entscheidet, ob ihr sinnvoll zum nächsten wechseln könnt.
Den Erkenntnisgewinn am Ende benennen
Schließt jeden besprochenen Eintrag mit zwei kurzen Sätzen ab: Was ist jetzt klarer als vorher und welche Frage bleibt offen? Diese Zusammenfassung macht sichtbar, ob die Diskussion ihren Zweck erfüllt hat. Sie hilft auch Menschen, die an einer kleineren vorbereitenden Runde nicht beteiligt waren.
Wenn mehrfach dieselbe offene Frage stehen bleibt, prüft den Klärungsweg. Vielleicht fehlt eine entscheidungsfähige Person oder es wird Information erwartet, die niemand tatsächlich beschaffen kann. Mehr Refinement-Zeit allein löst diesen Engpass nicht. Ein konkreter Auftrag mit passender Zuständigkeit ist dann der nächste sinnvolle Schritt.
Häufige Fragen zum Backlog Refinement
Brauchen wir eine Definition of Ready?
Scrum schreibt keine Definition of Ready vor. Eine kleine gemeinsame Orientierung kann helfen, darf aber nicht zu einem starren Übergabetor zwischen Rollen werden. Prüft, ob die Liste tatsächlich Verständnis verbessert oder nur Dokumente verlangt. Unsicherheit verschwindet nicht dadurch, dass ein Formular vollständig ausgefüllt ist.
Muss immer das ganze Team teilnehmen?
Nicht jede Klärung braucht alle Personen. Entscheidend ist, dass relevantes Wissen einfließt und wichtige Ergebnisse gemeinsam verfügbar sind. Wenn die Vorbereitung in kleinen Gesprächen stattfindet, dürfen wesentliche Annahmen nicht ausschließlich dort bleiben.
Wo liegt die Grenze zum Sprint Planning?
Refinement schafft Verständnis und einen geeigneten Zuschnitt. Im Sprint Planning plant das Scrum Team den Sprint. Die Scrum-Rollenübersicht ergänzt die Verantwortlichkeiten. Nehmt beim nächsten Refinement einen Eintrag weniger und prüft dafür bewusst, ob nach dem Gespräch alle denselben Nutzen und die wichtigsten offenen Fragen benennen können.
