In den letzten beiden Artikeln zum Thema „Agiles Schätzen und Planen“ wurden bereits vorgestellt, wie es möglich ist, einen Sprint so zu planen, daß man sich möglichst immer die optimale Menge an User Stories vornimmt (nicht zu viel, aber auch nicht zu wenig).
Diese Planung wird alleine durch das Team durchgeführt (plus den Scrum Master). Eine Einflussnahme von aussen ist nicht vorgesehen, nicht einmal durch den Product Owner.
Das Team soll sich nämlich die zu erledigende Arbeit für den Sprint möglichst selbst auswählen, muss sich diesem „Sprint-Ziel“ dann aber auch verschreiben und darf auch nur noch in Ausnahmefällen davon abrücken. Auf diese Weise soll sich das Team stärker mit den Zielen identifizieren als wenn sie diese von aussen zugewiesen bekämen. Übrigens ein Ansatz, der tatsächlich funktioniert, wie unsere Erfahrungen hier eindeutig zeigen.
Natürlich möchte man aber auch dem Product Owner einen (berechtigten) Einfluss auf die Sprint-Ziele zugestehen. Wie löst man nun diese scheinbare Konfliktsituation?
Eigentlich ganz einfach:
Der Product Owner nimmt mit an der Sprintplanung teil.
Eigentlich ist dies sowieso notwendig, da nur der Product Owner dem Team den Sinn und Zweck einzelner Einträge des Product Backlogs erklären kann. Ein gutes Verständnis der Einträge ist aber wiederum unabdingbare Voraussetzung für eine gute Schätzung.
Kommt man nun gegen Ende der Planung an den Punkt, an dem das Team sich die Einträge für den neuen Sprint aussucht, so geschieht dies ja anhand der Einträge des Product Backlogs (das ja nach Geschäftswert sortiert ist). Die Sortierung aktuell zu halten gehört mit zu den wichtigsten Aufgaben des Product Owners.
Hat das Team die Liste der Features fertig erstellt, so wird sie noch einmal dem Product Owner vorgelegt, um sein Einverständnis zu erhalten. Normalerweise wird man es auch erhalten. Sollte dies aber wieder Erwarten nicht der Fall sein, so bleiben ihm noch drei Möglichkeiten der Einflussnahme:
- Er sortiert die Einträge des Product Backlog neu. Dies sollte eigentlich nur in Ausnahmefällen notwendig sein, zumindest wenn er es mit seiner Aufgabe genau nimmt, und das Product Backlog konstant aktuell hält,
- Er reduziert den Umfang eines Eintrags, um ihn so doch noch mit in den aktuellen Sprint aufnehmen zu können
- Er splittet den Eintrag auf. Der erste (dringendere) Teil wird sofort realisiert, der Rest auf einen späteren Sprint verschoben.
Somit wird die Kontrolle darüber, was in einem Sprint realisiert wird, zu gleichen Teilen auf Team und Product Owner verteilt:
Auf das Team, weil es alleine entscheidet, wieviele Story Points im Sprint umgesetzt werden können, und zudem noch die Einträge des Product Backlogs mit Story Points beschätzt.
Und auf den Product Owner, da er dem Team eine verbindliche Reihenfolge vorgibt, in der die Einträge des Product Backlogs realisiert werden müssen, und dieses bis zum Ende der Sprintplanung noch ändern kann.
Spielen alle Beteiligten ehrlich und aufrichtig zusammen, so schafft man so eine fast optimale Auslastung des Teams.
Darüber hinaus behält man auch immer den „Business Case“ (man verzeihe mir dieses Wort) im Auge, da der Product Owner, der ja derjenige mit der „Vision“ ist, immer dafür sorgt, die richtigen Anforderungen zur richtigen Zeit zu realisieren.
Die Sprintplanung ist also nun komplett, es kann also losgehen mit der Realisierung :). Bis zu Beginn des nächsten Sprints die nächste Planung ansteht…
BFI
Wird geladen ...
