So legen Sie ein Ziel für den Sprint fest (mit Beispielen)
Ein Sprintziel ist ein Satz, der verdeutlicht, warum der Sprint wichtig ist. Hier erfahren Sie, was ein starkes Ziel ausmacht, warum es vor dem Umfang steht, sowie Beispiele für schwache und starke Ziele im direkten Vergleich.
Ein Sprintziel ist ein einziger Satz, der verdeutlicht, warum es sich lohnt, den Sprint durchzuführen. Es ist das einzige 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 des Sprints eng wird, gibt das Ziel vor, welche Arbeiten vorrangig behandelt und welche zurückgestellt werden sollen.
Die meisten Teams betrachten das Ziel lediglich 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 zuerst 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 („die 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 besser einen sehr guten Grund geben – einen Sicherheitspatch, eine zwingende Abhängigkeit – oder er muss warten. Wenn Sie zuerst den Umfang festlegen, erscheint jedes Element gleich wichtig, und es gibt nichts, was man streichen könnte, wenn der Donnerstag aus dem Ruder läuft.
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 in der Praxis geändert hat. „Das Epic zur Passwortzurücksetzung 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 sagt Ihnen sofort, worauf Sie sich konzentrieren müssen. Wenn das Ziel lautet: „Nutzern das Zurücksetzen ihres Passworts ermöglichen“, stellen Sie den Prozess 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 in Verzug gerät und nichts in einwandfreiem Zustand veröffentlicht wird.
- Das Team muss es auswendig wiedergeben können. Ein Ziel, das niemand wiedergeben kann, ist ein Ziel, an dem sich niemand orientiert. Wenn das Team das Planungsdokument öffnen 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 benannt wird.
| Schwaches Tor | Warum es nicht funktioniert | Eindrucksvolles Tor |
|---|---|---|
| „Arbeiten an der Neugestaltung des Bezahlvorgangs.“ | Bezeichnet einen Bereich, kein Ergebnis. Es gibt keine Ziellinie. | „Ein Stammkunde kann den Bestellvorgang auf dem Smartphone in weniger als einer Minute abschließen.“ |
| „40 Story-Punkte aus dem Backlog abschließen.“ | Ein Ergebnis ist ein Maßstab, 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, Kompromisse einzugehen. | „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 Nutzer oder ein bestimmtes System führt eine bestimmte Aufgabe nach einem bestimmten Standard aus. Man könnte jedes einzelne Ziel vorführen, und alle Anwesenden würden ohne Widerspruch zustimmen, ob es erreicht wurde oder nicht.
Ein Ziel, nicht mehrere
Streben Sie ein einziges Ziel an. Ein einziges Ziel ist es, das Kompromisse erst möglich macht – bei zwei konkurrierenden Zielen gibt es kein Prinzip, für das man sich einsetzen könnte, wenn die Zeit knapp wird, und schon sind Sie wieder bei der Situation, in der alles ein wenig aus dem Ruder läuft.
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 in einem Sprint zusammengefasst wurden, die als zwei separate Sprints übersichtlicher wären. Gelegentlich kommt eine kleine Menge 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; das 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 für die Messung des Fortschritts. 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 Durchführung 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; andernfalls 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, an dem man festhalten kann, 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.