Sprint Goal
In der heutigen Folge geht es um das Sprint Goal (deutsch: Sprintziel). Diese Folge ist aufbauend auf die letzte Folge Commitment.
Denn es braucht Commitment um sich auf ein begeisterndes Sprintziel im Planning einigen zu können.
Warum ist das heute Thema? Henry hat entdeckt, dass er das Thema anders behandelt als Janina und auch anders als es im Scrum Guide steht.
Diese Folge auf YouTube: https://youtu.be/gxm4WSArVLY
Keiner hat’s
Stimmt natürlich nicht. 😀 Es gibt sicherlich viele Teams, die ein Sprintziel haben. Bist Du in einem solchen Team, dann schreib uns bitte an hello@znipcast.de wir würden uns wirklich sehr freuen mehr Sprint Goals und die Teams dazu kennenzulernen. Dort hin zu kommen, vor allem konstant Ziele zu haben, ist nicht ganz so leicht.
Daher, wenn über 80% Trefferquote herrscht, sage ich gern „Keiner hat’s“. 😀
Was ist denn ein Sprint Goal?
In den Scrum Folgen haben wir sicher schon darüber gesprochen, dass die Iterationen im Scrum Sprints heißen. Ein Sprintziel ist daher schon einmal das Ziel eines Sprints. Diese Sprints haben die Länge von 1 bis 4 Wochen. Das Ziel markiert nun, was auf jeden Fall in dieser Zeit vom Team erreicht werden soll. Sogar das Commitment des Teams dies auch zu erreichen.
Wie definieren?
Es gibt jetzt mehrere Möglichkeiten zum Sprintziel zu kommen. Generell ist es Einigung zwischen Product Owner und Entwicklern während des Sprint Plannings.
Hier ist es wie überall in der Agilität: Es gibt keine Blaupausen, schau was gut zu Deinem Team passt.
Was in den Sprint kommt ist auch das Ziel
Eine Möglichkeit wäre, dass alle Anforderungen (Stories), die es in den Sprint schaffen, also in das Sprint Backlog, auch dem Sprintziel entsprechen. Gehen also 12 Anforderungen rein, dann sind diese 12 auch das Sprint Ziel. Fertig. Widerspricht gleichzeitig dem Scrum Guide, der ganz klar sagt, dass das Sprintziel auch erreichbar sein muss, wenn man nicht alle Anforderungen umgesetzt hat. Also vielleicht ein paar Abstriche bei den Anforderungen machen.
StoryPoints
Das Team entscheidet wie viele StoryPoints in einen Sprint genommen werden. Hier wird unabhängig von der wahren Zahl der Anforderungen, die in den Sprint gehen, zusätzlich die StoryPoints, bei denen sich das Team zuversichtlich fühlt als Sprintziel festgelegt. Also das Team glaubt 12 Anforderungen umsetzen zu können und ist absolut zuversichtlich für 30 StoryPoints als Sprint Goal. Nun kann es sein, dass die 30 StoryPoints bereits nach 10 Aufgaben erreicht sind. Wie das Team dies bewerkstelligt bleibt ihm überlassen. Dieses Limit könnte man auch generell auf die Anforderungen, die in den Sprint kommen, festlegen.
Die 70% Regel oder doch 80?
Einige Teams commiten sich einfach zu 70 oder 80% des Sprint Backlogs als Sprintziel. Also wir nehmen uns 100% vor und sichern Dir, lieber Product Owner oder Stakeholder, 70% davon bis Sprint Ende zu. Kann man machen und ist auch recht easy, doch wie motivierend ist dies für Dich?
Empirie
Wenn Du ein frisches Team vor Dir hast, probiert aus, was ihr euch zutraut und wo es hingeht. Beobachtet das was klappt und was nicht klappt und passt die Methode dazu an.
Eine Empfehlung vor allem für den Anfang, lasst dort das Sprintziel einfach erst einmal weg, wenn sich das Team damit nicht so leichttut.
Gerade für Urlaubszeiten kann das interessant sein.
Mittelwert
Jeder schreibt auf, was er denkt, was zum Sprintziel schaffbar ist. Dann wird der Mittelwert oder Median gebildet und das ist das Ziel für den Sprint. Das Aufschreiben kann auch die Nennung der jeweiligen Anforderungen (Stories) sein, die sich derjenige zutraut.
Motivierender Slogan
In einigen Teams kann es sich lohnen als „Sprintziel“ einen motivierenden Slogan oder ein Motto zu wählen. Wir wollen diesen Sprint besser mit unseren Kunden interagieren. In dieser Iteration feiern wir unsere Erfolge so richtig. Mut ist unsre Ziel!
In dem Fall ist das Sprint Goal eher auf der Metaebene und geht nicht direkt um konkrete Aufgaben, sondern Dinge auf die wir besonders im Sprint achten und in der Retrospektive oder im Review zusammentragen.
Anzahl Tasks zählen
Statt in Anzahl StoryPoints könnte Dein Team auch die Anzahl Tasks zählen. Das Commitment würde sich also um die erledigten Aufgaben zum Iterationsende drehen.
Henrys Methode: Das Ziel vorher klar haben
Es steht anders im Scrum Guide, als es Henry machen würde. Im Scrum Guide steht, dass sich das Sprintziel aus den Backlog Items bildet, die in den Sprint kommen und das Ziel muss erfüllbar sein ohne alle Items zu erledigen. Über das Ziel selbst wird sich im Planning im Team geeinigt. Henry möchte lieber, dass die Product Owner bereits mit einem Ziel in das Planning gehen und dann das Team gemeinsam die passenden Anforderungen (Backlog Items) dazu auswählt und sich commited. Natürlich bleibt das Ziel auch so verhandelbar. Der Product Owner kommt schon mit einem konkreteren Vorschlag, der dann feinjustiert wird. Eher selten gibt es dann ein komplett neues Ziel.
Dieses Ziel selbst kommt einem Feature oder einer neuen Funktion des Produktes gleich. Zum Ende des Sprints kann unser Produkt folgendes…
Danach wählen alle gemeinsam die Anforderungen aus, die dazu passen. Und auch hier wäre es gut, wenn der Product Owner bereits vorbereitet wäre. 🙂
Ich finde diese Variante motiviert viel mehr und ist eher etwas gemeinsames, was man tragen kann. Zudem wird das Sprint Goal so nicht einfach nur eine Aufzählung von Anforderungen.
Natürlich dürfen dann auch noch weitere Anforderungen mit in den Sprint, sie gehören dann nur nicht zum Ziel.
Opferannode
Wir legen im Plannig fest, was wir nicht machen werden (also opfern), wenn die Arbeitszeit in Richtung Sprintende eng wird.
Kundenmehrwert
Richtig gut ist es, wenn der Product Owner und die Stakeholder berichten können wie viel Kundenmehrwert eine Anforderung liefert. Beispielsweise in Euro. Das Ziel könnte dann sein in einem Sprint Summe X an Kundenmehrwert zu schaffen.
Gamification auf das Sprintziel
Um das Sprintziel attraktiv zu gestalten kann man Gamification darauf anwenden. Beispielsweise Süßigkeiten, wenn Etappen davon umgesetzt wurden oder Legosteine, die gut sichtbar von einem Gefäß in das nächste andern. Dies funktioniert am ehesten in der Normingphase eines Teams.
Get shit done,
Gefällt dir die Podcastfolge? Dann empfiehl sie gerne anderen weiter, z.B. indem du die Folge in deiner Story teilst. Wenn du magst verlinke @znip_academy_agile und wir teilen deinen Like mit unseren Hörern.
Du möchtest dich von uns in der Tiefe in eurem Veränderungsprozess begleiten lassen, eure größten Komplexitätsnester auflösen und die besten Teamtipps bekommen? Dann bewirb dich gerne für unser True Leader Coaching: https://znip.academy/produkt/scrum-master-coaching – Durch deine Bewerbung hast du die Chance auf einen der nächsten freien Plätze.
In der Podcastfolge erwähnte Folgen zur Vertiefung:
Connecte dich gerne hier mit uns:
