Was heißt der Satz “Refinement usually consumes no more than 10% of the capacity of the Development Team” im Scrum Guide? Wie viel Aufwand ist Product Backlog Refinement denn nun?
Timeboxen der Scrum Ereignisse
Die Timebox für die Scrum Ereignisse ist relativ klar. Sprint Planung: maximal 2 h je Woche Sprint; Sprint Review und Sprint Retrospektive zusammen ebenfalls max. 2 h je Woche Sprint; Daily Scrum max. 15 min. Da hat kaum jemand Fragen.
Aber was ist denn nun die Timebox für das Product Backlog Refinement?
Product Backlog Refinement ist kein Ereignis
Der erste Schritt zur Antwort ist das Verständnis, dass Product Backlog Refinement kein Ereignis ist. Mit Product Backlog Refinement ist die gesamte Arbeit des Scrum Teams am Product Backlog gemeint. Product Backlog Refinement kann einige gemeinsame Arbeitszeiten (“Meetings”) umfassen, z.B. ein Schätzen mit dem Team. Aber dazu gehört auch die Arbeit des Product Owners an seinem Schreibtisch.
Beim Product Backlog Refinement sprechen wir daher von Aufwand – und nicht von einer Timebox wie bei den Ereignissen.
Aufwand, nicht Timebox für Product Backlog Refinement
Wie groß ist aber der Aufwand? Was bedeuten die 10 % jetzt so genau?
Je größer das Team ist, um so mehr Stories müssen Sprint für Sprint fertig sein, und um so mehr Aufwand ist das Product Backlog Refinement. Daher hängt der Aufwand für das Product Backlog Refinement von der Teamgröße ab.
Wir rechnen das mal kurz mit einem Beispiel: Wir haben ein Team mit 8 Personen und eine Sprintlänge von 10 Tagen. Die Teamkapazität ist also 80 Personentage (PT), der Aufwand für das Product Backlog Refinement bei 10% also maximal 8 PT.
Wer macht das Refinement?
Wie wir diesen Aufwand verteilen, steht nicht im Scrum Guide. Es gibt ganz verschiedene Lösungen, um diesen Aufwand zu stemmen.
Es ist aber klar, dass Product Owner (PO) und Entwicklungsteam diese Arbeit zusammen machen. Wenn der PO das Refinement alleine machen würde wäre das der klassische Staffellauf-Ansatz. Manchmal begegnen wir solchen Teams, die ein “Alternatives Scrum” machen. Sie sind zu erkennen an Sätzen wie: “PO, diese Anforderung ist nicht gut genug, so können wir damit nicht arbeiten, gehe zurück und komme wieder wenn du fertig bist.” Also: Refinement ist eine gemeinsame Aufgabe – und folglich ein gemeinsamer Aufwand von PO und Entwicklungsteam.
Folgende Varianten für das Refinement sind zum Beispiel möglich:
- Der PO macht viel Refinement-Arbeit und ein Schätz-Meeting mit dem Entwicklungsteam. Die Verteilung ist dann 1 PT bzw. 8h für die 1h Treffen mit dem Team, und 7 PT für den PO alleine. Der PO ist in diesem Fall Vollzeit beschäftigt, da er neben dem Refinement ja noch die Abnahmen im Sprint macht (und Sprint Planung und Sprint Review auch noch).
- Der Product Owner lässt das Team viel Arbeit machen. Er kommt mit Epics zum Entwicklungsteam und lässt diese vom Team detaillieren. Dazu trifft er sich zwei mal für 2h mit dem Team. Hier “verbraucht” das Team 4 PT und der PO 4 PT. In diesem Fall hat der PO noch Zeit, sich ggf. um andere Aufgaben zu kümmern.
Fazit
Product Backlog Refinement ist fortlaufende Arbeit und hat als solche keine Timebox. Deshalb steht im Scrum Guide: Der Aufwand für das Refinement ist 10% von der Kapazität des Teams. Wie diese Personentage Aufwand auf PO und Entwicklungsteam verteilt werden – das kann jedes Team für sich entscheiden.
