Ein Sprintziel ist ein einzelner Satz, der verdeutlicht, warum es sich lohnt, den Sprint durchzuführen. Es ist das eine Ergebnis, zu dem sich das Team verpflichtet: das, was am Ende des Sprints tatsächlich zutrifft. Alles, was das Team auswählt, sollte diesem Ziel dienen, und wenn der Zeitplan im Sprint eng wird, gibt das Ziel vor, welche Aufgaben priorisiert und welche zurückgestellt werden müssen.

Die meisten Teams betrachten das Ziel als Zusammenfassung der von ihnen ausgewählten Tickets. Das ist der falsche Ansatz, und genau deshalb sind so viele Ziele nutzlos.

Das Ziel hat Vorrang vor dem Umfang

Legen Sie zunächst das Ziel fest und wählen Sie dann die Aufgaben aus, die diesem dienen. Ein Ziel, das aus einer Reihe bereits ausgewählter Tickets rückentwickelt wurde („Punkte 4, 7 und 12 umsetzen“), ist kein Ziel; es ist ein Inhaltsverzeichnis. Es kann Ihnen nicht dabei helfen, eine Entscheidung zu treffen, da es keine Aussage darüber enthält, was wirklich wichtig ist.

Die Reihenfolge ist entscheidend. Wenn Sie sich vor der Festlegung des Umfangs auf das Ergebnis einigen, wird die Auswahl zu einer Reihe einfacher Fragen: Bringt uns dieser Punkt dem Ziel näher? Wenn ja, nehmen Sie ihn auf. Wenn nein, sollte es einen sehr guten Grund dafür geben (eine Sicherheitskorrektur, eine zwingende Abhängigkeit) – andernfalls muss er warten. Wenn Sie zuerst den Umfang festlegen, erscheint jedes Element als gleich wichtig, und es gibt nichts, was man streichen könnte, wenn der Donnerstag aus dem Ruder läuft.

A sprint goal anchoring the stories selected around it Sprint goal
Das Ziel ist das Ziel; die ausgewählten Elemente sind Pfeile, die darauf gerichtet sind. Ein Element, das in eine andere Richtung zeigt, ist ein Kandidat für die Streichung, kein Grund, das Ziel zu erweitern.

Was ein starkes Ziel bewirkt

Ein Ziel hat dann seine Berechtigung, wenn es drei Aufgaben erfüllen kann:

  • Es bezeichnet ein Ergebnis, keine Aufgabenliste. „Benutzer können ihr Passwort selbst zurücksetzen, ohne den Support zu kontaktieren“ sagt Ihnen, was sich geändert hat. „Das Epic ‚Passwort zurücksetzen‘ abschließen“ sagt Ihnen, welches Jira-Board Sie sich ansehen müssen.
  • Es trifft für Sie Kompromisse. Der wahre Test für ein Ziel ist der letzte Tag des Sprints, an dem nicht alles umgesetzt werden kann. Ein gutes Ziel zeigt Ihnen sofort, worauf Sie sich konzentrieren müssen. Wenn das Ziel lautet: „Nutzern das Zurücksetzen ihres Passworts ermöglichen“, stellen Sie den Ablauf zum Zurücksetzen bereit und lassen die optische Überarbeitung der E-Mail – die zwar wünschenswert wäre – außer Acht. Wenn das Ziel lautet: „Die Tickets abarbeiten“, haben Sie keine Grundlage für eine Auswahl, sodass alles ein wenig auf der Strecke bleibt und nichts in einwandfreiem Zustand veröffentlicht wird.
  • Das Team kann es auswendig wiedergeben. Ein Ziel, das niemand wiedergeben kann, ist ein Ziel, an dem sich niemand orientiert. Wenn das Team das Planungsdokument aufschlagen muss, um sich daran zu erinnern, warum es hier ist, ist das Ziel zu lang oder zu vage.

Schwache Ziele vs. starke Ziele

Der Unterschied zwischen einem schwachen und einem starken Ziel besteht fast immer darin, ob eine Handlung oder ein Ergebnis als Ziel benannt wird.

Schwaches TorWarum es nicht funktioniertEindeutiges Ziel
„Arbeiten an der Neugestaltung des Bezahlvorgangs.“Bezeichnet einen Bereich, nicht ein Ergebnis. Es gibt keine Ziellinie.„Ein Stammkunde kann den Bestellvorgang auf dem Handy in weniger als einer Minute abschließen.“
„40 Story-Punkte aus dem Backlog abschließen.“Ein Ergebnis ist ein Maß, dem das Ziel dienen sollte, und nicht das Ziel selbst.„Fassen Sie die drei häufigsten Gründe zusammen, aus denen Kunden den Kundendienst wegen Rechnungsfragen kontaktieren.“
„Die Leistung verbessern und Fehler beheben.“Zwei Ziele, keine Priorität, keine Möglichkeit, Abwägungen vorzunehmen.„Das Dashboard wird bei Konten mit mehr als 10.000 Datensätzen in weniger als zwei Sekunden geladen.“
„Stellen Sie die Berichtsfunktion fertig.“„Fertig“ verschleiert den Umfang – wessen Definition von „fertig“ gilt hier?„Führungskräfte können einen wöchentlichen Teambericht ohne unsere Unterstützung als PDF exportieren.“

Beachten Sie, dass die aussagekräftigen Ziele alle eine gemeinsame Struktur aufweisen: Ein bestimmter Benutzer oder ein bestimmtes System führt eine bestimmte Aktion nach einem bestimmten Standard aus. Sie könnten jedes einzelne Ziel vorführen, und alle Anwesenden würden ohne Widerspruch zustimmen, ob es erfüllt wurde oder nicht.

Ein Ziel, nicht mehrere

Streben Sie ein einziges Ziel an. Ein einziges Ziel macht Kompromisse erst möglich; bei zwei konkurrierenden Zielen gibt es kein Prinzip, für das man sich einsetzen könnte, wenn die Zeit knapp wird, und man landet wieder bei dem Zustand, in dem alles ein wenig auf der Strecke bleibt.

Sollte sich die Arbeit tatsächlich nicht unter ein einziges Ziel einordnen lassen, betrachten Sie dies als Hinweis und nicht als Problem, das man einfach unter den Teppich kehrt. In der Regel bedeutet dies, dass der Sprint zu viel umfasst oder dass zwei Arbeitsstränge zu einem Sprint zusammengefasst wurden, die als zwei separate Sprints übersichtlicher wären. Gelegentlich kommt eine kleine Menge an nicht zum Ziel gehörender Routinearbeit hinzu. Das ist in Ordnung, solange allen bewusst ist, dass es sich dabei um Ballast handelt und nicht um die eigentliche Aufgabe.

Wem gehört das Tor?

Der Product Owner bringt die Absicht ein: den geschäftlichen Grund, warum dieser Sprint wichtiger ist als die Alternativen. Das gesamte Team formt diese Absicht zu einem Ziel, zu dem es sich tatsächlich verpflichten kann, was bedeutet, dass die Entwickler davon überzeugt sein müssen, dass es mit der verfügbaren Kapazität erreichbar ist. Ein Ziel, an das das Team nicht glaubt, ist nichts weiter als ein Wunsch mit einer Frist.

Sobald Sie ein Ziel haben, für das es sich lohnt, sich einzusetzen, wird der Rest der Planung einfacher: Die Agenda dient als Maßstab für die Auswahl der Aufgaben, und das tägliche Scrum dient als Maßstab, an dem der Fortschritt gemessen wird. Das am Montag festgelegte Ziel ist das, woran sich das Team während des gesamten Sprints orientiert.

Häufig gestellte Fragen

Was ist ein Sprintziel?

Ein Sprintziel ist ein einzelner Satz, der darlegt, warum es sich lohnt, den Sprint durchzuführen: das eine Ergebnis, zu dem sich das Team verpflichtet. Es wird während der Sprintplanung festgelegt, noch bevor der Umfang definiert wird, und gibt dem Team ein gemeinsames Ziel vor, dem die ausgewählten Backlog-Elemente dienen. Es ist der Grund für die Existenz des Sprints, nicht die Liste der darin enthaltenen Tickets.

Was zeichnet ein gutes Sprintziel aus?

Ein gutes Sprintziel beschreibt ein Ergebnis, keine Aufgabenliste; es ist konkret genug, um Ihnen zu verdeutlichen, worauf Sie verzichten müssen, wenn der Zeitplan im Sprint eng wird; und das gesamte Team kann es auswendig wiedergeben. Wenn Ihr Ziel lediglich darin besteht, „diese Tickets abzuschließen“, kann es Ihnen nicht dabei helfen, Kompromisse zu finden – und genau das ist die eigentliche Aufgabe eines Ziels.

Wer legt das Ziel des Sprints fest?

Der Product Owner bringt die Absicht ein (den geschäftlichen Grund, warum dieser Sprint von Bedeutung ist), und das gesamte Team formt daraus ein Ziel, zu dem es sich während der Planung verpflichten kann. Es handelt sich um eine Zusammenarbeit, nicht um eine Anweisung. Die Entwickler müssen davon überzeugt sein, dass das Ziel mit der verfügbaren Kapazität erreichbar ist, sonst bleibt es nur ein Wunsch.

Kann ein Sprint mehr als ein Ziel haben?

Streben Sie ein einziges Ziel an. Ein einziges Ziel ermöglicht es dem Team, unter Druck Kompromisse einzugehen; bei zwei konkurrierenden Zielen gibt es kein Prinzip, das es zu wahren gilt, wenn die Zeit knapp wird. Wenn sich die Arbeit tatsächlich in zwei Teile aufteilt, ist dies oft ein Zeichen dafür, dass im Sprint zu viel erreicht werden soll oder dass die Arbeit zweier Teams in einem Sprint zusammengefasst wurde.