Beim Product Backlog Refinement handelt es sich um die Detaillierung und Konkretisierung der Product Backlog Items. Konkret geht es darum, die Product Backlog Items um die Details wie Beschreibungen, Schätzungen und Priorisierung zu ergänzen. Die Features, Funktionen, Erwartungen und Änderungen des Produkts, die im Product Backlog aufgezählt sind, werden also näher beschrieben. Die Durchführung des Product Backlog Refinements erfolgt zwischen dem Product Owner und den Developers. Das Product Backlog Refinement hat keinen festen beziehungsweise bestimmten Zeitpunkt im Rahmen des SCRUM Prozesses. Das Product Backlog Refinement erfolgt fortlaufend.
Die Entscheidung, wann und wie es durchgeführt wird, liegt beim SCRUM Team. Der Aufwand für das Product Backlog Refinement sollte insgesamt nicht mehr als 10 Prozent der gesamten Entwicklungsarbeit ausmachen. Im Rahmen des Product Backlog Refinements werden die einzelnen Product Backlog Items überprüft und angepasst. Die Product Backlog Items selbst können jederzeit von Product Owner oder auf seine Anweisung hin angepasst werden. Die Entscheidung über die Anpassung der Product Backlog Items liegt also beim Product Owner, die Entscheidung über den Zeitpunkt der Durchführung des Product Backlog Refinements liegt beim SCRUM-Team.
Die Detaillierung und Granularität der Product Backlog Items sind durchaus unterschiedlich. Grundsätzlich sind alle Product Backlog Items vom Product Owner in eine Rangfolge gebracht worden. Die Rangfolge beschreibt hierbei, welches aus Sicht des Product Owners die wichtigsten Funktionen sind, die als nächstes von den Developers umgesetzt werden sollten. Hierbei stehen Product Backlog Items, die als nächstes umgesetzt werden sollten, ganz oben im Product Backlog, und Items, die später umgesetzt werden sollten, weiter unten. Die Backlog Items, die als nächstes anstehen, sind hierbei konkreter beschrieben und detaillierter als die Items, die erst für eine spätere Umsetzung anstehen. Hierbei ist wichtig, dass die Items, die potenziell für den nächsten Sprint vorgesehen sind, so ausreichend detailliert sind, dass jedes Mitglied des SCRUM-Teams auch versteht, was zu tun ist und was die Anforderungen bezüglich des „Done“ sind. Die Voraussetzung, dass ein Backlog Item aus dem Product Backlog ins Sprint Backlog übergeht und somit im Sprint umgesetzt werden kann, ist also, dass dieses Backlog Item so detailliert wurde, dass es in dem anstehenden Zeitfenster des kommenden Sprints auch umgesetzt werden kann.
Wenn ein Backlog Item von den Developers innerhalb eines Sprints erledigt („Done“) werden kann, wird es als bereit („Ready“) für die Auswahl für den nächsten Sprint und damit für das Sprint Backlog gesehen. Für die Schätzungen sind immer die Developers zuständig. Der Product Owner kann Einfluss auf die Developers nehmen und ihnen helfen, die Schätzungen durchzuführen und Abwägungen und Trade-offs vorzunehmen. Dennoch bleiben die Entscheidung und die finale Durchführung der Schätzung bei den Developers.
Planning Poker
Die Voraussetzung, dass ein Backlog Item von den Developers entwickelt werden und jemals den Zustand des „Done“ erreichen kann, ist, dass es ausreichend detailliert beschrieben wurde. Nur wenn das Backlog Item priorisiert, geschätzt und verstanden ist, ist es bereit, aus dem Product Backlog ins Sprint Backlog überführt zu werden. Die „Definition of Ready“ beschreibt also, wie detailliert ein Backlog Item beschrieben werden muss beziehungsweise welche Kriterien es erfüllen muss, damit es so „bereit“ ist, dass es im anstehenden Sprint von den Developers auch umgesetzt werden kann.