Sprint Ziel

Was ist ein Sprint Ziel?

“Arbeitet jemand von Euch mit Sprint-Zielen?” Wenn ich diese Frage in den Trainings stelle, melden sich selten mehr als ein oder zwei Teilnehmende. Dabei ist das Sprint-Ziel meiner Meinung nach einer der mächtigsten Hebel in Scrum.

Mit dem letzten Scrum Guide wurde es nun sogar in die völlig neue Kategorie der “Commitments” befördert. Eine solche tiefgreifende strukturelle Änderung hat es an Scrum bisher noch nie gegeben. Es wird also Zeit, sich mit dem Sprint-Ziel etwas näher zu beschäftigen.

Das Sprint-Ziel erklärt, warum ein Sprint wertvoll ist. Es geht beim Sprintziel also nicht darum, was am Ende geliefert werden soll – das steht ja schon im Sprint Backlog. Sondern es geht darum, warum dieses Ergebnis den Anwendern oder den Geldgebern gefallen sollte. Bei einer Smartphone-App würde das Sprint-Ziel zum Beispiel verwendet, um im Store anzuzeigen, was neu ist in dieser Version. Freuen sich die Anwender dann auf die neue Version und laden sie gerne herunter, war das Sprint-Ziel gut.

Aber Vorsicht: Das Sprint-Ziel ist etwas anderes, als Release Notes. Im Sprint-Ziel beschreibt das Scrum Team, was es sich vornimmt, zu erreichen. In den Release Notes, was es tatsächlich getan hat.

Über gute und schlechte Sprint-Ziele

Anhand der Version 2.0.3 der Corona WarnApp kann man das schön sehen (siehe Abb 1): Ziel dieser Version waren Check-Ins für Events per QR-Code. Der Wert eines solchen Sprints ist unmittelbar einsichtig. Man darf auch ohne Insider-Wissen vermuten, dass die Entwickler stolz darauf waren, als sie dieses zusätzlichen Puzzlestück zur Freiheit fertig gestellt hatten. Wir haben hier also einige wichtige Eigenschaften eines guten Sprint-Ziels zusammen:

  • Das Sprint-Ziel leistet eine klare Aussage, warum der Sprint wertvoll ist und für wen. Es ist also für die Stakeholder unmittelbar verständlich, nachvollziehbar und bewertbar.
  • Es bleibt wage genug, um noch auf unvorhergesehenes reagieren zu können. Welche Sonderfälle werden abgedeckt, was passt nicht mehr in den Sprint? Solange das Sprint-Ziel nicht gefährdet ist, bleibt hier durchaus noch Entscheidungsspielraum, den das Scrum Team auch während des Sprints noch nutzen kann und sollte.
  • Das Spint-Ziel setzt ein nutzbares Ergebnis voraus, es kann also nicht auf Kosten der Qualität erzwungen werden.

Was uns motiviert

Diese drei Kriterien entsprechen „Purpose“, „Autonomy“ und „Mastery“, laut Dan Pink den drei wichtigsten Voraussetzungen für Motivation. Das Sprint-Ziel spielt also eine wichtige Rolle dabei, das Team nicht nur zu fokussieren, sondern erzeugt intrinsische Motivation. Zumindest wenn es gut ist.

Ein Beispiel für ein wenig motivierendes Sprint-Ziel findet man ebenfalls bei der Corona-WarnApp nur wenige Wochen später: Für die Version 2.1.3 heißt es lapidar „Mit diesem Update beheben wir einen Fehler“. Als Stakeholder würde mich hier zumindest interessieren, was verändert wurde, damit dieser Fehler in Zukunft gar nicht mehr ausgeliefert würde. Und welcher Fehler überhaupt? „Testautomatisierung erweitern, um Fehlerklasse XY zuverlässig zu erkennen“ wäre da schon ein besseres Sprint-Ziel, zumindest für interne Stakeholder.

Heben Sprint-Ziele häufig nur auf die innere Qualität ab, würde ich als Scrum Master einmal eine Retrospektive zum Thema Produktqualität ansetzen. Das Scrum Team kann dann diskutieren, warum solche Sprint-Ziele notwendig sind. Wie könnte man wieder mehr Zeit auf Ziele verwenden, die dem Anwender tatsächlich einen neuen Wert schaffen? Sprint-Ziele, die sich nur mit Fehlern beschäftigen, sind für alle Beteiligten frustrierend. Sie bedeuten, dass man nun das auch wirklich liefert, was man schon vor ein paar Sprints behauptet hatte, man hätte es geliefert.

Das Sprint-Ziel im Fokus behalten

Damit das Sprint-Ziel wirklich nützlich wird, sollte es sich durch den ganzen Sprint ziehen. Es wird während der Sprint Planung erarbeitet und vereinbart, wenn das ganze Scrum Team es für realistisch hält.

Im Daily Scrum wird der Fortschritt gegen das Sprint-Ziel gemessen, also „Was müssen wir noch tun, um das Sprint-Ziel zu erreichen“. Während des Sprints setzt es die Leitplanken. Welche sind Entscheidungen unkritisch, weil sie das Sprint-Ziel nicht gefährden? Welche Enstscheidungen müssen noch mit dem Product Owner diskutiert werden, weil sie das Sprint-Ziel gefährden könnten? Wenn sich herausstellt, dass doch mehr Arbeit notwendig ist, als man in der Planung dachte, versuchen alle gemeinsam, den Umfang zu reduzieren, ohne das Sprint-Ziel zu gefährden. Das setzt natürlich voraus, dass man gut verstanden hat, was an dem Sprint-Ziel für die Stakeholder wichtig ist. Damit kann man das Essenzielle unterscheiden von dem, was zwar schön aber doch verzichtbar ist.

Im Sprint Review nutzt das Scrum Team das Sprint-Ziel schließlich als Überschrift und Kontext: Warum haben wir diesen Sprint überhaupt gemacht? Warum ist es für Euch, liebe Stakeholder, interessant, sich mit dem Ergebnis zu beschäftigen? Und wie findet Ihr unsere Umsetzung?

Gute Sprint-Ziele finden

Ein gutes Sprint-Ziel zu finden braucht sowohl ein gutes Verständnis für die Bedürfnisse der Stakeholder als auch einige Erfahrung beim Schneiden von Sprints. Deshalb machen erfahrene Product Owner das gemeinsam mit dem Scrum Team und möglicherweise auch im Austausch mit einzelnen Stakeholdern. Ein hervorragendes Werkzeug dafür ist Story Mapping. Dabei zerlegt das Team ein komplexes Problem sehr systematisch in kleine, in sich wertvolle Teile, die auf sehr natürliche Weise zu Sprint-Zielen führen. Ein schönes Beispiel für Story Mapping zeigt der leider viel zu früh verstorbene David Hussman in diesem Video.

In der Sprint Planung unterzieht das Scrum Team das Sprint Ziel nochmal einem Realitätscheck: Es überlegt, welche Backlog Items auf das Sprint-Ziel einzahlen, und ob es realistisch ist. Falls nicht, muss das Team entweder auf eine Idee kommen, wie sich das Ziel auch mit weniger Aufwand erreichen lässt, oder das Sprint-Ziel entsprechend reduzieren. Erst wenn alle einverstanden sind, gilt das Sprint-Ziel als vereinbart.

Übrigens muss das Sprint-Ziel nicht unbedingt eine für die Anwender wertvolle Funktionalität sein. Ich erinnere mich ein Team, das ein völlig neues Consumer-Gerät bauen sollte. Am Anfang mussten sie erst einmal die zukünftigen Kunden verstehen und Ideen entwickeln, was man bauen könnte. Dafür verplanten sie einen kompletten Sprint für Haushaltsbesuche und einen Design-Thinking Workshop. Das Sprint-Ziel lautete „Ideen für die Verprobung generieren“, das Ziel für den Sprint davor war schlicht „Haushaltsbesuche ermöglichen“. Es ging also darum, zu lernen – nicht das schlechteste Sprint-Ziel, wenn spätere Sprints sich dann auch um das Liefern kümmern.

Tipps & Tricks

Was wichtig ist: Das Sprint Ziel wird nicht von irgendjemandem außerhalb des Scrum Teams dem Team aufoktroyiert. Es entsteht durch eine gemeinsame Sicht des gesamten Scrum Teams. Andere dürfen zwar Wünsche äußern, oder auch ihre Vorstellungen von Wert („Wenn dieser Button nicht rosa eingefärbt wird, steht die ganze Firma auf dem Spiel!…“). Entschieden wird es aber vom Scrum Team in Sprint Planung.

Ein Tipp noch aus der Praxis: Erfahrene Teams wählen ihre Sprint Ziele so, dass noch ein paar Backlog Items extra in den Sprint passen. Das erhöht das nicht nur die Chance, das Sprint-Ziel auch tatsächlich zu erreichen. Es bietet zudem auch noch Raum, den ein oder anderen Fehler zu beheben, oder technische Schulden abzubauen. Das reduziert die Notwendigkeit für öde Sprint-Ziele á la „Mit diesem Update beheben wir einen Fehler“, auch wenn man doch hin und wieder auch diesen Kelch leeren muss.

Willst Du mehr über Sprint-Ziele erfahren? Dann besuche doch einen CSPO oder A-CSPO Kurs bei uns.

Anmerkung: Meine Überlegungen zur Corona-WarnApp erfolgen aus reiner Anwenderperspektive. Ich verfüge über keinerlei Insider-Informationen über Organisation oder Überlegungen des Entwicklungsteams. Ich bin den Entwicklerinnen und Entwicklern der App sehr dankbar für das, was sie für geleistet haben und weiterhin leisten. Dass ich sie hier als Beispiel verwendet habe, ist Zeichen meiner Anerkennung, nicht Kritik.

Sprint Ziel Beispiel


Abb 1: Beispiel für ein gutes Sprintziel – zumindest aus meiner Sicht: Endlich liefert die Corona WarnApp eine Alternative zur Zettelwirtschaft in Restaurants und liefert damit einen Vorgeschmack auf zukünftige Lockerungen. Als Sprint-Ziel würde der PO hier vielleicht „Check-In per QR Code ermöglichen“ vorschlagen.

Sprint Ziel Beispiel

Abb 2: Beispiel für ein eher ödes Sprintziel. Als Anwender freue ich mich über automatische Updates, die mir die Beschäftigung mit solchen Sprint-Zielen ersparen. Als Scrum Master wird es Zeit, einmal ein paar Fragen zu stellen.

Scroll to Top