Das Sprint Ziel in Scrum
Das Sprint Ziel definiert den Nutzen, den ein Produktinkrement am Ende des Sprint erreicht. Das Sprint Ziel wird allerdings so definiert, dass es nicht die Summe der umzusetzenden User Stories ist. Ein Sprint Ziel schreibt den Nutzen des Produktinkrements in einer abstrakten Form, so ist es möglich das Sprint Ziel zu erreichen, auch wenn z.B. eine User Story getauscht wurde oder nicht umgesetzt wurden konnte.
Das Scrum Team definiert
Das Entwicklungsteam, der Product Onwer und der Scrum Master definieren gemeinsam das Sprint Ziel. Dabei gehen die Teams in der Regel so vor, dass der Product Owner ein solches Ziel als Vorschlag mit in das Team bringt. Dann wird mit dem Entwicklungsteam darüber diskutiert und im besten Falle gleich übernommen. Es kann auch vorkommen, dass das Entwicklungsteam kleine Anmerkungen hat oder das Sprint als utopisch ansieht - dann muss in die Verhandlung mit dem Product Owner gegangen werden. Das Sprint Ziel wird während des Sprints nicht verändert.
Das Sprint Ziel am Board
Das Sprint Ziel wird immer zum Sprint Backlog gehängt. Das hilft zum einen sehr im Sinne der Visualisierung - das Team schaut zwangsläufig immer jeden Tag (zu Beispiel im Daily Scrum) auf dieses Ziel und wird erinnert. Ach wenn dieser Aspekt oft als "lächerlich" oder "überflüssig" angesehen wird, ist es in meinen Augen sehr entscheidend.
Zudem kann das Team so auch viel besser die drei Fragen im Daily Scrum auf dieses Sprint Ziel beziehen.
Das Sprint Ziel kann nicht erreicht werden
Es kann durchaus auch vorkommen, dass ein Sprint Ziel einmal nicht erreicht wird. Das sollte immer die Ausnahme bleiben und ebenso in der Retrospektive ausführlich untersucht werden. Nehmen wir an das Scrum Entwicklungsteam hat sich komplett verschätzt und das Ziel des laufenden Sprints ist jetzt schon nicht mehr erreichbar. Dann kann und sollte der Sprint durch den Product Owner abgebrochen werden. Auch der Product Owner kann durch eine Änderung der Anforderungen und andere wirtschaftliche Entscheidungen sich dazu genötigt sehen, das Sprint Ziel einzustellen, da es nicht mehr zu erreichen ist.
Der Sprint wird in diesem Falle abgebrochen. Es ist besser den aktuellen Sprint abzubrechen, als ihn zu Ende zu führen, obwohl wir wissen, dass das Ziel nicht mehr erreicht werden kann.
Beispiele
Wenn Sie Ziele zum ersten Mal aufstellen wollen, suchen Sie in der Regel eine Vorlage, ein Beispiel - kurz: wie machen es denn eigentlich andere? So ein Ziel könnte lauten: Ersten haptischen Prototypen für das neue Navigationsgerät erstellen, die Loginfunktionalität des Portals etablieren oder auch den Umgang mit Scrum lernen. Sie sehen schon, dass das Ziel ganz unterschiedlich sein kann. Nur eines sollte es eben nicht sein: eine einfache Wiederholung von Anforderungen / Product Backlog Einträgen.
Sie können sich nun bestimmt auch vorstellen, dass das im Sprint definierte Ziel als eine kleine Vision für den Sprint gilt. Es ist konkret genug eine Richtung festzulegen, aber noch so abstrakt, dass Sie sich für oder gegen Eigenschaften des Produktes entscheiden können.
Es ist nun vollkommend ausreichend, wenn Sie dieses Ziel am Sprint Backlog des Team festhalten. So kann jedes einzelne Teammitglied aus dem Entwicklungsteam tagtäglich seine Arbeit gegen eben dieses Ziel reflektieren!
Und was wenn in einem Sprint 4 Stories stecken und sich diese Thematisch an 4 verschiedenen Randbereichen des Produktes befinden? Wie findet man in so einem Fall ein Ziel?
Hallo Fred,
was wäre das für ein konkretes Beispiel?
Grundsätzlich sollte der Product Owner pro Sprint im Gedanken etwas haben, was am Ende des Sprints als Wert für den Kunden liefern möchte. Das Sprint Ziel ist das Ergebnis des ganzen Scrum Teams, muss folglich aber eine Richtung haben. Wenn das nicht geht, ist meine Vermutung pauschal (ohne das Beispiel zu kennen), dass entweder das Team nicht richtig geschnitten ist oder es Probleme mit der Priorisierung des Backlogs gibt. Vielleicht auch noch mal auf die Vision schauen…
Viele Grüße
Sebastian Schneider
Nehmen wir an unser Produkt wäre MS Word. Im Backlog befinden sich im Moment fünf Userstories:
1) Kreditkartenverifizierung für Office365 Verlängerung
2) Bug beim Ausklappen des Ribbon Menüs
3) Eine neue Anzeige der Schriftarten
4) Eine Mappingverbesserung beim PDF Export
5) Das neue Firmenlogo im About Text
Das Team schafft es sich im nächsten Sprint zu den ersten dreien zu committen.
Ich würde kein eindeutiges Ziel formulieren können.
Das ist ein interessantes Beispiel. Also wenn ich die ersten drei Dinge lese, dann ist letztendlich 1) was (aus meiner Sicht) einen richtigen erlebbaren Kundenwert darstellt. Ist 1) komplett in einem Sprint zu erledigen? Ich bin ja ein Verfechter von User Stories (auch wenn sie nicht verplichtend sind) aber ich könnte mir unter dem Aspekt vorstellen, dass “Verifizierung von Kreditkarten” als Ziel nehme (oder ähnlich) und dazu dann aber mehr als ein Product Backlog Item für 1) verfügbar ist (kann sein, muss nicht. Hängt vom Team, vom Inhalt, Sprintlänge etc ab). Ich persönlich nutze auch Ziele wie “Verifizierung von Kreditkarten” und erlaube es, dass es die ein oder andere (wichtige und priorisierte) Aufgabe gibt, die im Sprint getan wird, aber nicht 100% auf das Ziel einzahlt. Also könnte 2 & 3 mit drin sein. Das Sprint Ziel muss auf die Vision einzahlen, insofern auch da noch mal gegen checken.
Wenn ich mir nun alle Items (1-5) ansehe, dann werde ich das Gefühl nicht los, dass es sich aktuell um eine Art “Maintenance” oder “Verbesserungsphase” handelt. Kann das sein? Wenn ja, das wäre zum Beispiel ja auch ein Ziel das nutzbar wäre. Ist 1) nun wirklich so klein, dass es problemlos umgesetzt werden kann als ein Item, dann würde mich interessieren, wie lange die Sprints sind – denn kann sich das Team wirklich nur auf drei Items committen? Ich würde nachbohren und tippen das Item 1 größer ist (wenn es jetzt nicht Auslagern über API an Drittanbieter ist und trivial damit wird) – aber auch dann, ist zu wenig im Sprint. Dann schauen, ob mehrere Items möglich sind, die vielleicht doch auf ein Ziel einzahlen.
Hilft das?
Danke für Ihre ausführliche Antwort. Sie hilft mir soweit weiter, als dass ich es zur weiteren Reflexion mit in mein Team nehmen werde.
Schöne Grüße