digitalien.org — Stefan Knecht

Backlog refinement — aufgeräumt bleiben

Agile Teams arbeiten typischerweise intensiv und konzentriert. Das kann hohe Produktivität freisetzen — und zu einem Tunnelblick führen, wenn jeweils nur die unmittelbar nächstliegenden Aufgaben im Sichtfeld stehen.

Das refinement hat viele Synonyme, etwa Schätzmeeting oder Schätzklausur. Den Begriff grooming verwendet man wegen anzüglicher Nebenbedeutungen besser nicht mehr.

Wozu 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 — bereit zur Umsetzung?

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
  • (…)

Wer macht das refinement?

Das Team entscheidet gemeinsam mit dem Product Owner, wie das refinement durchgeführt wird und wer daran teilnimmt. Es kann sinnvoll sein, auch Stakeholder einzuladen.