Backlog Refinement ist die Scrum-Aktivität, die bei Zeitdruck am ehesten ausgelassen wird, und deren Fehlen zwei oder drei Sprints später den größten Schaden anrichtet. Schlecht verfeinerte Elemente zeigen ihre fehlenden Details mitten im Sprint, wenn die Kosten, ein Missverständnis zu entdecken, weit höher sind, als sie während des Refinements gewesen wären.
Kontinuierlich verfeinern, nicht als einzelnes Event. Refinement als ein geplantes Meeting pro Sprint zu behandeln, erzeugt tendenziell entweder eine überstürzte Sitzung, die nicht genug abdeckt, oder eine so lange Sitzung, dass sie selbst zur Erschöpfungsquelle wird. Teams, die in kleineren, häufigeren Sitzungen verfeinern (zwanzig Minuten mehrmals pro Woche statt zwei Stunden einmal pro Sprint), halten den Backlog tendenziell mit weniger kumulativem Schmerz in besserem Zustand.
Von oben nach unten verfeinern, und nur so weit wie nötig. Elemente nahe der Spitze des Backlogs, die wahrscheinlich im nächsten Sprint oder den beiden nächsten bearbeitet werden, verdienen echte Sorgfalt: klare Akzeptanzkriterien, ein geteiltes Verständnis des Umfangs, eine Schätzung, der das Team tatsächlich vertraut. Elemente weiter unten brauchen dieses Detailniveau noch nicht, und zu viel darin zu investieren, ist verschwendete Arbeit, da sich Prioritäten und Anforderungen ändern, bevor sie erreicht werden. Die Disziplin liegt darin, genau genug, genau rechtzeitig zu verfeinern, nicht alles auf dieselbe Tiefe unabhängig von der Nähe.
Vor dem Verfeinern aufteilen, nicht danach. Ein Backlog-Element, das zu groß ist, um sinnvoll verfeinert zu werden, ist ein Signal, dass es geteilt werden muss, nicht stärker verfeinert. Teams, die versuchen, detaillierte Akzeptanzkriterien auf ein übergroßes Element zu zwingen, erzeugen tendenziell Kriterien, die mehrere unterschiedliche Arbeitspakete unbeholfen zusammenbündeln, statt ein klares Arbeitspaket.
Das gesamte Team einbeziehen, nicht nur die Product-Owner-Person und ein paar erfahrene Entwickler:innen. Refinement-Sitzungen, die einen Teil des Teams ausschließen, erzeugen tendenziell Backlog-Elemente, die nur für die im Raum Anwesenden Sinn ergeben. Wer die Arbeit am Ende leistet, sollte eine Stimme dabei gehabt haben, zu definieren, was "fertig" dafür bedeutet. Sonst hat Refinement das Missverständnis nur von vor dem Sprint nach während des Sprints verlagert.
Eine "Definition of Ready" führen, und sie tatsächlich durchsetzen. Ein geteilter, expliziter Maßstab dafür, was ein Element bereit für einen Sprint macht (klare Akzeptanzkriterien, keine ungelösten externen Abhängigkeiten, eine Größe, die das Team sicher schätzen kann), gibt Refinement ein konkretes Ziel. Ohne das wird "ist das genug verfeinert?" zu einer subjektiven Ermessensfrage, die sich unter Zeitdruck leicht überspringen lässt.
Refinement nutzen, um Uneinigkeit ans Licht zu bringen, nicht nur Details zu füllen. Die wertvollsten Refinement-Sitzungen sind die, in denen jemand sagt "warte, ich dachte, das bedeutet etwas anderes", nicht die, die reibungslos verlaufen, weil ohnehin schon alle still zugestimmt haben (oder still uneins waren, ohne es zu sagen). Eine Refinement-Sitzung ohne jede Reibung ist oft ein Zeichen, dass nicht genug echte Prüfung stattgefunden hat, kein Zeichen exzellenter Abstimmung.
Nichts davon braucht insgesamt mehr Zeit als schlampiges Refinement. Es verschiebt die Anstrengung lediglich nach vorne, wenn sie günstig ist, statt sie mitten im Sprint auftauchen zu lassen, wenn sie teuer ist.