Das wöchentliche Product Backlog Refinement ist eine der Praktiken, die in kurzer Zeit zu einer wirkungsvollen Verbesserung führen. Dies kann in der Praxis sein jedoch sehr knifflig sein. Der Erfolg der Pflege kann daher von vielen Faktoren abhängen.
Bevor es losgeht
Der Zweck des Backlog Refinement ist es, die Product Backlog Items im Product Backlog so vorzubereiten, dass die Product Backlog Items die im Backlog „oben“ stehen, möglichst gut für einen der nächsten Sprints vorbereitet sind. Sprich die Spitze des Product Backlogs wird verfeinert.
Wer?
Backlog Refinement ist eine gemeinschaftliche Maßnahme. Ein Moderator (Scrum Master) hält die Sitzung auf dem Weg zum Ziel. Ein Vertreter des Managementteams klärt die übergeordneten Prioritäten. Ein Product Owner klärt die Details der Product Backlog Items. Vertreter des Entwicklungsteams definieren den Arbeits- und Arbeitsaufwand, der erforderlich ist, um die Fertigstellung der vereinbarten Product Backlog Items zu erfüllen. Es sollte daher mindestens ein Entwickler und ein Tester eingesetzt werden, um alternative Sichtweisen des Systems sicherzustellen.
Wann?
Das Product Backlog Refinement sollte während der mittleren 60% des Sprints erfolgen. Die ersten 20% des Sprints sollten dazu dienen, das Tempo festzulegen und jedem einen gewissen Fortschritt zu ermöglichen. Die letzten 20% des Sprints könnten die Zeit sein, in der sie sich auf die restlichen Elemente im Burndown-Diagramm konzentrieren. Das Pflegen während der letzten 20% stört die Dynamik und kann zu einem fehlgeschlagenen Sprint führen. Abhängig von der Auslastung der Teams darf man sich gerne ein- bis zweimal pro Woche treffen, um das Backlog zu überprüfen.
Das Goldlöckchen-Prinzip und das Product Backlog Refinement
Beim Goldlöckchen-Prinzip geht es darum, das zu finden, was „genau richtig“ ist. Ziel ist es, einen Ausgleich zu schaffen, indem man genügend Nutzen aus der Aktivität zieht und gleichzeitig den potenziellen Abfall minimiert. Die 6 Vorteile der Product Backlog Refinement:
- Transparenz erhöhen
- Wert klären
- Zerlegung in verwendbare Stücke
- Abhängigkeiten reduzieren
- Prognosen
Transparenz erhöhen
Das Product Backlog ist ein Artefakt, das zur Transparenz beiträgt. Es ist die „Quelle der Wahrheit“ für das, was im Produkt geplant ist. Das Hinzufügen von Details erhöht die Transparenz darüber, was ein Plan liefern soll und welche Fortschritte erzielt werden sollen.
Goldlöckchen Fragen
- Wie gut verstehen Stakeholder und das Scrum-Team, was für das Produkt geplant ist?
- Wie oft sind die interessierten Stakeholder überrascht, was geliefert wurde?
Wert klären
Wenn man die Details um den Wert klärt, sind die Ergebnisse klarer, die man mit dem Product Backlog Item (PBI) zu erreichen versucht. Warum will man das? Was ist der Anwendernutzen? Was ist der wirtschaftliche Nutzen? Dies hilft dem Entwicklungsteam, die richtige Lösung zu finden, um den Bedarf zu decken. Dies kann sich auf das Anforderungsprofil, den Kostenvoranschlag und den Auftrag auswirken, da der Product Owner und das Entwicklungsteam herausfinden, was tatsächlich benötigt wird. Dieses Gespräch schafft ein gemeinsames Verständnis.
Goldlöckchen Fragen
- Wie oft stellt man während eines Sprints fest, dass es kein gemeinsames Verständnis für die Geschäftsanforderungen gibt oder was man baut, um sie zu erfüllen?
- Wie oft stellt man in einem Sprint Review oder nach einer Freigabe fest, dass ein Product Backlog Item nicht den Anforderungen des Benutzers oder des Unternehmens entspricht?
Zerlegung in verwendbare Stücke
Man möchte, dass die Product Backlog Items so klein sind, dass ein Entwicklungsteam mehr als eins in einem Sprint vervollständigen kann. Mehr als ein Product Backlog Item in einem Sprint gibt dem Team daher die Flexibilität, ein Sprintziel zu erreichen und ein „Done“ Inkrement zu liefern.
Goldlöckchen Fragen
- Wie oft liefert man kein „Done“ Inkrement? Wie oft erfüllt man ein Sprintziel nicht?
- Sind PBIs viel größer, als das Team dachte oder nicht dünn genug geschnitten?
Abhängigkeiten reduzieren
Abhängigkeiten werden oft zu Hindernissen und können ein Team zum Stillstand bringen. Während sich nicht alle vermeiden lassen, sollte man sie nach Möglichkeit reduzieren. Dies ist besonders wichtig für Abhängigkeiten außerhalb des Scrum Teams. Man kann die Product Backlog Items daher auf verschiedene Weise zerschneiden und aufteilen. Zumindest möchte man, dass die Abhängigkeiten transparent sind.
Goldlöckchen Fragen
- Wie oft entdeckt man während eines Sprints Abhängigkeiten, die das Sprintziel gefährden?
- Wie lange bleiben Product Backlog Items in einem Sprint durch Abhängigkeiten „blockiert“?
- Wann muss man Product Backlog Items neu anordnen, um Abhängigkeiten zu berücksichtigen?
- Wie stark wirkt sich dies auf die Fähigkeit des Product Owners zur Wertoptimierung aus?
Prognosen
Ein verfeinertes Product Backlog kombiniert mit historischen Informationen hilft bei einer Prognose.. Scrum verbietet keine Vorausplanung. Scrum sagt einfach, dass man seinen Aufwand, die potenzielle Verschwendung und die Tatsache, dass man die Zukunft in einer komplexen Domäne nicht perfekt vorhersagen kann, berücksichtigen sollte.
Goldlöckchen Fragen
- Wie viel Vorlaufzeit ist erforderlich, damit Benutzer, Kunden und andere Interessengruppen eine neue Funktion implementieren können? Was sind die Auswirkungen, wenn sie weniger Vorlaufzeit haben?
- Wie detailliert müssen Anwender, Kunden und andere Stakeholder in Prognosen sein? Was ist die Auswirkung, wenn sie weniger Details haben?
Einen Überblick zur Serie Scrum Basics findest du hier: Scrum Basics: Alles auf einen Blick