Agile Methode: Sprint Ziele (Timebox Ziel)
Es hat sich als sinnvoll erwiesen für jeden Sprint, bzw. für jede Timebox ein Ziel zu formulieren, dass durch diese Timebox erreicht werden soll.
Ein solches Ziel kann die Umsetzung einer User Story sein, oder das Erstellen von einer oder mehrerer Funktionalitäten. Es kann aber auch nur einen Teilbereich einer User Story oder eine Teilfunktionalität sein, die in einer Timebox fertig gestellt werden soll.
Das zentrale Element eines solchen Ziels ist der Aspekt des Wertes. Innerhalb einer Timebox muss etwas erstellt werden, dass einen Wert für den Product Owner, bzw. die Stakeholder darstellt. Dieses Inkrement muss einen selbständigen Wert darstellen. Der Wert muss also als solcher - unabhängig von allen Funktionalitäten die die Leistung sonst noch hat - entstehen.
Am Ende der Timebox muss in einem Review von den Stakeholdern überprüft werden können, ob das Ziel erreicht wurde.
Gegenseitige Verpflichtung von Team und Product Owner
Das Sprint Ziel ist eine gegenseitige Verpflichtung zwischen dem Team, das die Leistung erstellt und dem Product Owner als Vertreter der Auftraggeber und sonstiger Stakeholder.
- Das Team verpflichte sich am Ende der Timebox das Ziel zu erfüllen.
- Der Product Owner verpflichtet sich das Ziel nicht zu verändern und das Team zu unterstützen.
Das Ziel muss also über den Zeitraum des Sprints konstant bleiben, damit das Team konzentriert auf dieses Ziel hinarbeiten kann.
Zwischen "Änderung" und "Klärung"
Das Ziel darf nicht verändert werden. Wenn ein Ziel verändert wird, dann bedeutet das, dass neue Tasks hinzu kommen, alte Tasks entfernt werden, Funktionalitäten geändert werden, User Stories neu geschrieben werden und insgesamt ein Neuplanung des Sprint stattfinden muss.
Eine Klärung bedeutet, dass z.B. eine User Story detaillierter erläutert wird, so dass das Team besser versteht, was damit gemeint ist. Dabei dürfen dann aber keine zusätzlichen Tasks auftauchen, Funktionalitäten zusätzliche Eigenschaften bekommen oder ähnliches Zusätzliches entstehen, dass über die geplante WIP (Work in Process) der Timebox hinaus geht.
Entstehen bei der "Klärung" solche zusätzlichen Arbeiten, dann sind sie in Form einer neuen User Story zu formulieren und werden Teil des Product Backlogs - und in einem späteren Sprint bearbeitet.
Abnormaler Abbruch
Natürlich gibt es immer die Möglichkeit, dass ein Sprint abgebrochen werden muss, weil das gesetzte Ziel seinen ökonomischen Wert verloren hat. Hierbei handelt es sich jedoch um eine äußerst seltene Ausnahme. Wie häufig kann es vorkommen, dass ein Product Owner innerhalb von 4 Wochen erkennt, dass ein von ihm festgesetztes, mit den Stakeholdern abgesprochenes Ziel seinen ökonomischen Sinn verliert?
Seminar: Vorbereitung zur Scrum Zertifizierung bei der Scrum.org