In einem früheren Artikel habe ich beschrieben, was das Product Backlog ist und was ein gutes Product Backlog auszeichnet. Heute möchte ich das Thema mal von einer anderen Seite betrachten: welche Ziele wir mit dieser Arbeit verfolgen.
Was also ist das Ziel des Backlog Refinements?
Generell kann man sagen, dass es beim Refinement darum geht, das Product Backlog im guten Zustand zu halten (weiter unten werde ich beleuchten, was das bedeutet) aber es soll dem Team auch helfen, ein gemeinsames Verständnis für die Anforderungen des nächsten Sprints zu erlangen.
Deswegen hebt der Scrum Guide hervor, dass es sich nicht um eine einmalige sondern kontinuierliche Tätigkeit handelt, bei der „Product Owner und das Entwicklungsteam gemeinsam“ an der Verfeinerung des Backlogs arbeiten sollen und dass letztlich das Team entscheidet wie und wann es diese Tätigkeit ausführt.
Also was ist denn ein guter Zustand?
Da wir in Scrum (ganz im Sinne der agilen Prinzipien) jegliche Zeitverschwendung vermeiden wollen, bedeutet das: unser Backlog soll unsere Prioritäten wiederspiegeln und es sollen die Backlog-Items den bestmöglichen (angemessenen) Detailgrad aufweisen, die im nächsten Sprint bearbeitet werden sollen.
Der wahrscheinlich beste Indikator hierfür ist, eine beliebige Person im Team zu fragen, die nicht beim Verfassen der ursprünglichen Story (falls denn das Format von Stories verwende wird) beteiligt war:
Ist für dich klar, WAS mit der Story erreicht werden soll und WIE das überprüft werden kann?
Davon abgesehen gibt es eine gewissermaßen technische Anforderung: wir wollen die „Größe“ einer Story kennen, um sagen zu können: jawoll, die Story passt in den nächsten Sprint.
Übrigens: In Scrum liegt die Verantwortung für diese Schätzungen beim Team.
Eine beliebte Eselsbrücke, mit der man sich zumindest merken kann, wie ein gutes Product Backlog aussehen sollte, ist das Akronym DEEP. Das steht für:
- Detailed appropriately: Höher priorisierte Einträge haben ein ziemlich solides Maß an Informationen, während andere weniger detailliert sein können.
- Estimated appropriately: höher priorisierte Einträge müssen mit einer Schätzung versehen sein und sollten den aktuellen Wissenstand zum Thema widerspiegeln
-
Emergent: Das Product Backlog sollte ein lebendes Dokument sein, das regelmäßig erweitert, angepasst oder aus dem sogar Einträge wieder entfernt werden.
-
Prioritized: Im Product Backlog spiegelt sich die Priorisierung der Einträge wider, meist in Form einer entsprechenden Sortierung
Daraus wird deutlich, dass beim Refinement der Fokus nicht ausschließlich auf der einzelnen Story liegen sollte – und dass auch hier das Team die ein oder anderen fehlenden Puzzleteile beitragen kann – etwa um technische Abhängigkeiten der Stories untereinander abzubilden.
Bei den einzelnen Einträgen selbst gilt: sofern es eine Definition of Ready gibt, kann diese helfen, den angemessenen Detailgrad eines einzelnen Eintrags zu beurteilen, wenn dieser im nächsten Sprint aufgenommen werden soll („fertig, um daran arbeiten zu können“). Allerdings sollte so eine Definition of Ready nicht als Werkzeug missverstanden werden, mit dem man die anderen beteiligten Personen auf die richtige Linie einpeitschen kann, sondern eher als ein Hilfsmittel für eine grundlegende Orientierung.
Erwähnenswert ist auch, dass zwar nur die für den nächsten Sprint gedachten Einträge einen hohen Detailgrad haben müssen, es aber dennoch Sinn macht, wenn wir Infos ergänzen sobald sie uns bekannt werden.
Zusammenfassend kann man sagen, dass es letztlich darum geht, unser Leben einfacher zu machen: mindestens während der Sprintplanung aber last but not least auch im eigentlichen Sprint.