Es gibt einen einfachen Test, ob dein Sprint ein Ziel hat. Stell mitten im Sprint die Frage: „Wenn wir alle Stories liefern, aber [X] tritt nicht ein — war der Sprint dann ein Erfolg?"
Wenn niemand sagen kann, was X ist, gibt es kein Sprintziel. Es gibt eine Auswahl von Tickets, die zufällig in denselben zwei Wochen wohnen.
Die meisten Teams, die ich sehe, haben genau das. Formal steht irgendwo ein „Sprintziel" — meist eine Aufzählung der grössten Stories, umformuliert als Satz. Das ist kein Ziel. Das ist die Inhaltsangabe des Backlogs.
Warum das jeden Sprint Geld kostet
Ein Sprintziel ist keine Zeremonie-Deko. Es ist eine Entscheidungsregel — und sie wird genau dann gebraucht, wenn etwas nicht nach Plan läuft. Also immer.
Mitten im Sprint passiert Folgendes, garantiert: Eine Story entpuppt sich als doppelt so gross. Ein Stakeholder bringt etwas „Dringendes". Ein Blocker taucht auf. Jetzt muss jemand entscheiden: Was lassen wir fallen, was ziehen wir vor, was eskalieren wir?
Mit einem Ziel ist das eine Zehn-Sekunden-Entscheidung: Gefährdet es das Ziel? Dann handeln. Gefährdet es nur ein Randticket? Dann warten. Ohne Ziel wird jede dieser Situationen zu einer Verhandlung — oder schlimmer, jeder entscheidet für sich. Der eine arbeitet weiter am Randticket, die andere springt auf das „Dringende", und am Ende ist von allem achtzig Prozent fertig und nichts ganz. Das ist übrigens einer der Hauptgründe, warum Teams ständig zwischen Aufgaben springen: Wo kein Ziel sagt, was zählt, verteilt sich die Energie wahllos.
Die Forschung dazu ist so alt und so eindeutig, dass man sie fast nicht mehr zitieren mag — aber sie ist der Grund, warum das kein Geschmacksthema ist. Edwin Locke und Gary Latham haben über vier Jahrzehnte und hunderte Studien hinweg gezeigt: Spezifische, anspruchsvolle Ziele führen zu deutlich höherer Leistung als vage „Gib-dein-Bestes"-Vorgaben — und der Effekt gehört zu den robustesten Befunden der gesamten Arbeitspsychologie. Ein Stapel Tickets ist die Arbeitsform von „gib dein Bestes": viel Aktivität, kein Fokus.
Commander's Intent
Das beste Bild für ein echtes Sprintziel kommt aus dem Militär, und Maarten Dalmijn hat es in die Scrum-Welt übersetzt: Commander's Intent.
Militärische Planung kennt ein Grundgesetz: Kein Plan überlebt den ersten Feindkontakt. Deshalb bekommt jede Einheit zwei Dinge — einen Plan und die Absicht dahinter. Wenn der Plan zerbricht (und er zerbricht), handelt die Einheit nicht planlos weiter und wartet auch nicht auf neue Befehle. Sie handelt im Sinne der Absicht.
Dein Sprint Backlog ist der Plan. Das Sprintziel ist die Absicht. Und der Feindkontakt kommt zuverlässig in Woche eins: die geplatzte Schätzung, die kranke Kollegin, die Überraschung in der Legacy-Schicht. Ein Team mit Absicht passt den Plan selbständig an — lässt das Randticket fallen, hilft beim Kernstück, verhandelt mit dem Stakeholder. Ein Team ohne Absicht arbeitet stur die Liste weiter ab oder eskaliert jede Kleinigkeit nach oben.
Dalmijns Formel dafür ist die beste Kurzfassung des Themas: Pläne sind bescheiden zu halten, Absicht ist heilig. Er nennt Sprintziele nicht zufällig das schlagende Herz von Scrum — ohne sie zerfällt der Sprint in Einzelarbeit.
Woran man erkennt, dass es kein Ziel ist
Vier Muster, alle verbreitet, alle verräterisch:
„Das Ziel ist, die geplanten Stories abzuschliessen." Das ist die Todo-Liste als Satz. Test gescheitert: Es gibt kein X, das eintreten soll.
Drei Ziele. Wer drei Ziele hat, hat keines — denn beim ersten Konflikt muss trotzdem jemand entscheiden, welches der drei wichtiger ist. Die Entscheidungsregel, die das Ziel sein sollte, fehlt weiterhin. Ein Ziel pro Sprint. Der Rest ist Beifang, und alle wissen, dass er Beifang ist.
Das Ziel kennt nur der PO. Ein Ziel, das im Planning-Protokoll steht, aber nicht in den Köpfen, existiert nicht. Der Test ist banal: Frag drei Teammitglieder am Tag fünf. Bekommst du drei verschiedene Antworten, hast du keines.
Das Ziel beschreibt Output statt Wirkung. „Login-Seite bauen" ist ein Arbeitspaket. „Neukunden können sich ohne Support-Anruf registrieren" ist ein Ziel — es sagt, woran man den Erfolg erkennt, und lässt offen, wie viel gebaut werden muss, um ihn zu erreichen. Vielleicht ist es weniger, als geplant war. Genau das ist der Punkt.
Und wenn es wirklich kein Ziel gibt?
Der häufigste Einwand kommt aus der Praxis, und er ist berechtigt: „Wir sind im Betrieb. Unser Sprint besteht aus zehn Bugs und Improvements, die nichts miteinander zu tun haben. Die lassen sich nicht unter einen Satz zwingen."
Stimmt. Und die falsche Antwort darauf ist, es trotzdem zu tun. Ein künstlich übergestülptes Ziel — „Qualität verbessern!", „Kunden glücklich machen!" — ist schlimmer als keines, weil es die Idee lächerlich macht und das Team lehrt, das Ziel als Deko zu behandeln.
Drei ehrlichere Wege:
Erst prüfen, ob die Zusammenhanglosigkeit echt ist. Zehn unverbundene Tickets sind manchmal ein Priorisierungs-Symptom: Es wurde gesammelt statt entschieden. Oft steckt doch ein Kern drin — „die drei Bugs, die Kunde X blockieren" ist ein Ziel. Der Rest ist Beifang, und das darf er sein.
Wenn es wirklich Betrieb ist: Das Ziel wird zum Kapazitätsversprechen. Nicht inhaltlich, sondern strukturell — „P1-Störungen in unter vier Stunden beantwortet, zwanzig Prozent Kapazität für den Abbau der Bug-Liste". Das ist ein prüfbares X. Es beschreibt nicht, was gebaut wird, sondern wie verlässlich das Team arbeitet.
Oder zugeben, dass dieser Arbeitsanteil kein Scrum ist. Reiner Betrieb ist Fluss-Arbeit, keine Ziel-Arbeit — dafür gibt es Kanban: Priorität und WIP-Limit ersetzen das Sprintziel als Entscheidungsregel. Viele Teams fahren sauber zweigleisig, Ziel für den Produktanteil, WIP-Limit für den Betriebsanteil, und sind damit ehrlicher unterwegs als mit einem Pseudo-Ziel über allem.
Der Kern bleibt in allen drei Fällen derselbe: Das Sprintziel ist eine Entscheidungsregel. Wo es keines geben kann, muss eine andere Regel her — Priorität, SLA, WIP-Limit. Was nicht geht, ist keine. Denn dann entscheidet der Zufall, und der entscheidet schlecht.
Der eine Eingriff
Wenn du nur eine Sache änderst, dann diese:
Formuliere im nächsten Planning das Sprintziel, bevor eine einzige Story ausgewählt wird — als Antwort auf die Frage: „Was ist am Ende des Sprints anders als heute?"
Die Reihenfolge ist der ganze Trick. Wer erst Stories zieht und dann ein „Ziel" darüberschreibt, bekommt die Inhaltsangabe. Wer erst das Ziel setzt, zieht danach nur die Stories, die darauf einzahlen — und merkt sofort, welche Tickets eigentlich Beifang sind. Das Planning wird dadurch kürzer, nicht länger: Über Beifang muss man nicht diskutieren.
Und ein Nebeneffekt, der sich nach zwei Sprints zeigt: Dein Daily bekommt automatisch eine Frage, die es wert ist, gestellt zu werden — „Was gefährdet unser Ziel bis morgen?" funktioniert nur, wenn es eines gibt.
Ein Sprint ohne Ziel liefert vielleicht trotzdem — aber er liefert, was zufällig fertig wurde, nicht was wichtig war. Die zwei Wochen vergehen so oder so. Die Frage ist nur, ob am Ende jemand sagen kann, wofür sie waren.
Nächste Schritte
Wenn dein Daily nur Statusprosa produziert: Ohne Ziel kann es nichts anderes — es gibt ja nichts, woran man sich ausrichten könnte. → Warum dein Daily nichts bringt - und warum du es trotzdem behalten solltest
Wenn dein Team ständig zwischen Tickets springt: Das ist die direkte Folge fehlender Priorität im Sprint. → Task Switching ist kein Fehler - es ist ein Symptom
Wenn der feste Rhythmus fehlt, in dem Ziele gesetzt und überprüft werden: → Heartbeat im Scrum Team: Warum feste Strukturen der Schlüssen zur Effizienz sind
Probier die umgekehrte Reihenfolge im nächsten Planning aus — Ziel zuerst, Stories danach — und schreib mir, was mit eurem Beifang passiert ist. → Taleon LinkedIn
Quellen
- Locke, E. A.; Latham, G. P. — «Building a Practically Useful Theory of Goal Setting and Task Motivation: A 35-Year Odyssey», American Psychologist, 57(9), 2002, S. 705–717. https://doi.org/10.1037/0003-066X.57.9.705
- Dalmijn, M. — «Driving Value with Sprint Goals: Humble Plans, Exceptional Results», Addison-Wesley Signature Series (Cohn), 2023. https://www.dalmijn.com
- Schwaber, K.; Sutherland, J. — «The Scrum Guide», 2020 (Sprintziel als einziges Objective des Sprints und Commitment des Sprint Backlogs). https://scrumguides.org
