Product Backlog Refinement

Regelmässiges Product Backlog Refinement (PBR) ist notwendig während jedes Sprints, um Items für zukünftige Sprints vorzubereiten (Ready). Schlüsselaktivitäten bei einem PBR sind (1) das aufteilen großer Items, (2) Detaillierung von Items bis diese Ready sind und (3) schätzen. Im Geiste der empirischen Prozesskontrolle beschreibt Scrum nicht, wie ein PBR durchzuführen ist empfiehlt aber, dass das Team nicht mehr als 10% ihrer Sprintkapazität darin investiert. Normalerweise wird eines in der Mitte des Sprints durchgeführt.

Hinweis! Refinements von Items wird nicht vom Product Owner oder einer Business Analyst Gruppe separat durchgeführt - eine solche Vorgehensweise würde die lean Verschwendung von Übergabe und Informationszerstreuung erhöhen. Im Gegenteil, das Team sollte dieses Refinement durchführen-nicht nur eine Teilgruppe des Teams, sondern das gesamte Team, u.a. weil eine Scrum-Regel die Teilgruppenbildung für spezifische Themen, wie Analyse oder Testing, untersagt.

Product Backlog Refinement Übersicht

Product Backlog Refinement wird häufig durchgeführt als:

• Übergreifendes Product Backlog Refinement (geteilt mit allen Teams)
• Team-Level Product Backlog Refinement
• Multi-Team Product Backlog Refinement

Übergreifendes Product Backlog Refinement

Die LeSS Regel birgt die Frage: Wie wird entschieden welche Teams wahrscheinlich ein Item implementiert? Darüberhinaus sind die Skalierungsaspekte, die soeben besprochen wurden, zu beachten: Gemeinsames Verständnis, Koordination, gemeinsames Arbeiten, abgestimmte Schätzungen und Ausbalancierung von Spezialitäten und Agilität.

Eine übergreifende PBR Sitzung adressiert all dies. Kurz zusammengefasst: Halte einen übergreifenden PBR Workshop mit Repräsentanten vor den jeweiligen Team PBR Sitzungen, um herauszufinden, welches Team an welchem Item arbeiten könnte und um das gegenseitige Lernen und die Abgestimmtheit zu verbessern. Teilnehmer ist der Product Owner, die jeweiligen Sachgebietsexperten und alle Teammitglieder - oder Repräsentanten jedes Teams. Repräsentanten sind üblicherweise bevorzugt, um die Sitzungen klein zu halten und um nicht alle in yet-another-meeting zu haben, in Abwägung zu den Kosten des Informationsflusses und der Informationszerstreuung.

Mache das folgende:

• teile große Items
• führe sehr leichtgewichtige Item-Analysen für elementares Verständnis durch
• schätze die Items
• identifiziere stark vernetzte Items, diese bedeuten geteiltes und gemeinsames arbeiten sowie einen erhöhten Koordinationsaufwand

Team-Level Product Backlog Refinement

Wenn ein Item eindeutig von einem Team umgesetzt werden kann und es nicht stark vernetzt mit anderen Items ist, dann entspricht die Vorgehensweise im Product Backlog Refinement dem in einem ein-Team Scrum. Das Team führt das Refinement selbst durch, idealerweise zusammen mit dem Nutzer/Kunden/Interessensvertreter und informiert den Product Owner über Änderungen (Aufteilungen, neue Schätzungen) im Product Backlog.

Multi-Team Product Backlog Refinement

Multi-Team PBR ist gegeben, wenn mehr als ein Team im selben Raum zur selben Zeit ist und ein PBR durchführt. Teilnehmer sind Sachgebietsexperten und alle Teammitglieder oder Repräsentanten von jedem Team.

Wie unterscheidet sich das von einem übergreifenden PBR? An einem übergreifenden PBR nehmen Teilnehmer aller Teams teil, bei einem Multi-Team PBR weniger aber mindestens mindestens zwei Teams. In diesem Fall ist es zudem wahrscheinlicher, dass alle Teammitglieder teilnehmen nicht nur Repräsentanten.

Führe Multi-Team PBR durch, um das gemeinsame Verständnis zu vergrößern und um Koordinationsgelegenheiten zu nutzen, wenn eine Gruppe von Teams an einem gemeinsamen Thema von Items arbeitet oder Items stark vernetzt sind.

Multi-Team PBR können Team PBR ergänzen oder ganz ersetzten.