tarent heißt jetzt Qvest Digital AG | mehr erfahren

Sprintziel – Akademische Extrameile oder handliches Werkzeug?

Adrian Salamon
| Scrum Master, Qvest Digital
Veröffentlicht 6. Januar 2021

Ein gutes Sprintziel hilft bei der Priorisierung, schafft Fokus und fördert zielgerichtete Zusammenarbeit im Team. So profitieren Teams und Unternehmen. Erfahrt, was ein gutes Sprintziel auszeichnet, welche Hürden es gibt und wie wir davon profitieren.

Was ist ein Sprintziel? Theorie nach dem Scrum Guide

Kurz zu den Basics: Der Sprint ist das Zeitfenster, in dem das Team versucht, prognostizierte Aufgabenpakete umzusetzen. Das Sprintziel hilft dabei, einen gemeinsamen Fokus auf einen Teil des Sprints zu legen. Der Scrum Guide (2020) sagt dazu:

As the Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.

Das Sprintziel dient also einerseits der regelmäßigen Inspektion des eigenen Vorgehens während des Sprints. Es hilft andererseits auch, neue Erkenntnisse so zu behandeln, dass sie entweder den Erfolg des Sprints nicht behindern oder ihn im Extremfall sogar abbrechen, wie es der Scrum Guide vorschreibt:

A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.

Das Sprintziel ist also ein wichtiges Werkzeug der Entscheidungshilfe, wenn es um die Ausrichtung und auch Durchführung des Sprints geht. Wie man dieses Instrument hilfreich verwenden kann, werden wir gleich noch erläutern.

Was bedeutet das Sprintziel für ein Scrum Team?

Bei der Planung wählen die Entwickler*innen den Sprintscope aus den vom Product Owner am höchsten priorisierten Backlogitems. Warum also noch zusätzlich dazu ein Sprintziel setzen, wenn bereits eine Ordnung besteht?

Eine dafür geeignete Metapher ist die Betrachtung der Sprint Backlogitems als Menü im Restaurant. Es gibt einen Salat zur Vorspeise, Pommes als Beilage und einen Burger (Hamburger oder Veggieburger) als Hauptspeise. Während alle drei Teilgerichte für das Zusammenspiel wichtig sind, ist es doch der Burger, der Kund*innen anlockt und an dessen Geschmack und Qualität sich das Restaurant mit der Konkurrenz messen muss.

Damit ist zwar nicht gemeint, dass der Kundin qualitativ minderwertige Pommes serviert würden. Aber sie könnte eher verzeihen, wenn die Beilage wenige Minuten zu spät nachgeliefert wird, solange der saftige Burger mit würziger Soße und frischem Brot die sonstigen Verfehlungen des Restaurants ausgleichen kann.

Zurück im Bild der Softwareentwicklung fällt es Teams im Review gelegentlich schwer zu bewerten, ob ihr Sprint nun ein Erfolg war oder nicht. Im Sprint wird Wert geschaffen, aber vielleicht nicht jede User Story auch wirklich komplett fertig („Done“) umgesetzt. Häufig sind nicht alle Baustellen abgeschlossen. Ist damit der Sprint gerissen? An der Stelle frage ich als Scrum Master gerne nach dem Sprintziel, das, wenn es gut formuliert ist, Antwort darauf geben kann: Wenn das Sprintziel erreicht wurde, dann war es doch zumindest ein akzeptabler Sprint, selbst wenn nicht alles fertig wurde, was zu Sprintbeginn prognostiziert wurde. Kein Wunder also, dass der neue Scrum Guide (2020) mit der Frage »Why is this Sprint valuable?« und dem damit verbundenen Sprintziel sogar das erste Thema des Sprint Plannings vorgibt.

Wie finden wir ein gutes Sprintziel?

Das gemeinsame Finden des Sprintziels ist Teil des Sprint Plannings. Dabei sind zwei Vorgehensweisen denkbar: Entweder wählt das Team auf Basis des vom Product Owner geordneten Product Backlogs einen Sprint Umfang und definiert auf dessen Basis ein Sprintziel. Dabei ist wichtig, dass das Ziel gemeinsam definiert wird, um eine höhere Motivation durch Selbstverpflichtung (Commitment) zu schaffen. Wir halten uns gerne an selbstauferlegte Regeln und weniger an Regeln, die uns von außen vorgeschrieben werden.

Eine Alternative wäre, mit einem Sprintziel zu starten, das der Product Owner vorgibt. Das Team überlegt anschließend, welche Backlogitems dafür notwendig wären und baut darauf seinen Sprint auf. Je nach Situation kann das eine oder das andere Vorgehen das Sinnvollere sein.

Egal, wie das Sprintziel gefunden wird, es gibt einige Empfehlungen, wie geeignete Formulierungen aussehen können: Es…

  • … besteht aus 1 bis 2 Sätzen
  • … ist messbar bzw. falsifizierbar (confirmable)
  • … ist fachlich formuliert / kundenzentriert
  • … hat als Vorgabe, dass alle externen Abhängigkeiten gelöst sind

Zum letzten Punkt ist zu sagen: Nichts ist schlimmer, als alles Menschenmögliche gegeben zu haben und trotzdem zu scheitern, weil außerhalb des eigenen Einflussbereichs etwas nicht geklappt hat. Beachtet man diese wenigen Bedingungen, kann ein Sprintziel zum Beispiel so aussehen:

„Am Ende des Sprints sollen unsere Kundinnen in der Lage sein, alle Texte in der App auch auf Englisch, Französisch und Polnisch anzeigen zu lassen.“

Aber wie finden wir nun unser richtiges Spritziel? Einige Teams nehmen sich als Art default Sprintziel vor: Wir erledigen alle Stories im Sprint. Allerdings ist das kein fokussiertes Sprintziel, sondern ein Commitment auf den Sprintscope (Sprint Planning Topic 2). Um einen Fokus zu setzen, kann das Identifizieren der wichtigsten Hauptstory ein erster Ansatzpunkt sein. Allerdings würde dafür auch eine klare Priorisierung innerhalb des Sprint Backlogs ausreichen. Im Idealfall ist das Ziel ein Zusammenspiel verschiedener Elemente, das Mehrwert für die Endkundin liefert. Hierbei hilft es, wenn das Sprint Backlog sich auf wenige Baustellen konzentriert und nicht zehn wichtige Features gleichzeitig tangiert. Eine solche Heterogenität an Themen führt zu einem schwierigen Prozess der Zielformulierung und einem gekünstelten, verklausulierten und verketteten Sprintziel.

Die Probleme der Praxis

In der Praxis sind Sprint Plannings oft kräftezährende Meetings in aufeinanderfolgenden Ausbaustufen. Viele starten mit einem – wie ich es nenne – „Sprint Planning 0“, in dem der letzte Sprint rekapituliert wird, Restaufwände geschätzt werden, unfertige Stories weiter refined werden, Anwesenheiten für den folgenden Sprint gesammelt werden, um schließlich im Sprint Planning Topic 1 über das Ziel des Sprints und im Sprint Planning Topic 2 über den Umfang zu sprechen. Häufig ziehen sich die Entwickler*innen danach für ein Sprint Planning Topic 3 zurück und machen sich einen Plan, wie die Aufgaben konkret umzusetzen sind (oft auch als langweiliger Storybreakdown durchgeführt, aber das ist ein anderes Thema). Während Topic 1-3 vom Scrum Guide sinnvollerweise vorgeschrieben sind, sehe ich häufig viel zu viel Zeit im „Sprint Planning 0“ verschwendet.

Sich nach oder während einer so auslaugenden Meetingsession mit einem Sprintziel der Metaebene zu befassen, kann schnell wirken wie eine extra Schaufel Overhead. Ein Team gestand mir einmal, dass es in einem anstrengenden Sprint Planning nicht noch 15 Minuten damit verschwenden wolle, einen langen Satz mit verschachtelten Nebensätzen zu formulieren. Für sie fühlte es sich nach erzwungenem Waste an, da sie keinen Mehrwert darin sahen. Lässt man Sprint Planning 0 einfach weg, ist die Wahrscheinlichkeit höher, mit noch klarem Kopf in den neuen Sprint starten. Natürlich muss man zusätzlich dazu auch den Sinn und Zweck des Sprintziels mit dem Scrum Team erarbeiten.

Überprüfung des Ziels

Damit das gefundene Sprintziel auch einen Sinn erfüllt, ist es wichtig, im Sprint immer wieder darauf zurückzukommen. Eine Empfehlung für das Daily Scrum könnte die Frage sein, wie man sich heute organisieren will, um das Sprintziel zu erreichen.

Zusätzlich kann das Team sich eigene Regeln geben, z. B. dass mindestens zwei Teammitglieder*innen ausschließlich am Sprintziel arbeiten sollen, solange es nicht erreicht ist. So wird ein Schwerpunkt im Sprint gesetzt, aber es ist auch noch Raum, um andere Backlogitems im Sprint parallel zu bearbeiten.

Spätestens im Sprint Review sollte das Sprint Ziel dann wieder Thema sein. So können die Entwickler*innen bereits in ihrer Einleitung zum Review auf das Sprintziel hinweisen und damit beweisen, dass sie ihr selbstgestecktes Ziel erreicht haben. Alternativ kann auch der Scrum Master im Verlauf des Reviews danach fragen und den Beweis dafür dann präsentiert bekommen.

Der Kreislauf von Inspect & Adapt gelingt hier natürlich auch nur, wenn genügend Offenheit und Transparenz im Team gelebt wird.

Fazit

Ein gutes Sprintziel unterstützt bei der Priorisierung, schafft Fokus und fördert zielgerichtete Zusammenarbeit im Team. Das Bestätigen oder Falsifizieren bietet auch eine Möglichkeit, Feedback zum aktuellen Sprint zu geben, das auch die Zusammenarbeit mit Stakeholdern unterstützen kann. Es zu finden ist Arbeit und kann im Team viel Zeit kosten, wenn das Setting drum herum nicht passend ist. Mit etwas Vorbereitung und einem overheadfreien Sprint Planning ist es jedoch ein geniales Werkzeug.

Literatur