Agile Teams arbeiten typischerweise intensiv und konzentriert. Das kann hohe Produktivität freisetzen, doch auch leicht zu einem Tunnelblick führen, wenn sich das Entwicklungsteam sich jeweils nur auf die unmittelbar nächstliegenden Aufgaben konzentriert.
Das refinement hat viele Synonyme, etwa Schätzmeeting oder Schätzklausur. Den Begriff grooming verwendet man wegen anzüglicher Nebenbedeutungen nicht mehr.
Was nutzt das refinement?
Ziel des refinement ist sicherzustellen, dass zu Beginn des Sprint-Planning hoch priorisierten User Stories ready sind — fertig um im nächsten Sprint umgesetzt zu werden. Ein Nebeneffekt ist, das im Arbeiten mit dem Backlog die Sicht in die Zukunft klarer wird und Rückfragen zu einzelnen stories geklärt werden können.
Der regelmäßige und gemeinsame Blick auf den größeren Zusammenhang im refinement hilft, die Perspektive auf die Produktvision zu halten.
Das gesamte Scrum Team pflegt laufend das Product Backlog. Jedes Team findet einen für sich passenden Rhythmus zwischen laufender Pflege und Umsetzung. Als Daumenregel: 5-10 % der Teamkapazität werden für die Backlog-Pflege aufgewandt. Das hängt natürlich vom Zustand des Backlogs ab: ein frisch aufgesetztes Backlog für ein neues Produkt wird mehr refinement erfordern als ein Backlog, das im wesentlichen kleinere Ergänzungen und Änderungen für ein bereits seit längerer Zeit bestehendes Produkt enthält.
Das refinement ist die Anreicherung, Detaillierung und Priorisierung des Backlog und idealerweise Teil der täglichen Routine. Spätestens vor der Planung des nächsten Sprint muss das refinement geschehen, so dass informierte Entscheidungen getroffen werden können.
Mit laufenden refinements wird sicher gestellt, dass zu Beginn jeden Sprints die höchst priorisierten items ausreichend detailliert und für den Sprint vorbereitet und ready sind:
- durch die Regelmäßigkeit sind refinements in den Arbeitsablauf getaktet
- als Workshop-Format sind sie konzentriert auf wenige neue Stories und nutzen die Zeit effektiv
- bei offenen Fragen können neue Stories bis zur Klärung vertagt und erneut aufgenommen werden.
- items werden in der Regel vom Team geschätzt. Anders bei der Sprintplanung, während derer nur in Ausnahmefällen geschätzt werden sollte, da nur items ausgewählt werden, die bereits ready und damit schon geschätzt sind
Was ist ready?
Das Team legt selbst eine Definition für ready fest.
Folgende Anforderungen an Stories oder item sind geläufig:
- vom Team so gut verstanden, dass das Team die Verantwortung für die Realisierung übernimmt
- Die Story ist in ihrer Komplexität geschätzt und der Product Owner kann ihre Priorität anpassen.
- klein genug für die Umsetzung in einem einzigen Sprint nach der Definition of Done des Teams, d.h. mit Test, Dokumentation und allem, was im Umfeld getan werden muss
- es gibt mindestens einen automatisierten Test, gegen den implementiert wird
- wenn vorhanden: interne ISO-9000 Kritierien sind erfüllt
- (…)