cartoon_settingtheperfectsprintgoalIn vielen Teams sehe ich entweder überhaupt kein klar definiertes Sprintziel oder eines, das man sich auch hätte sparen können. Warum wird dieser so wichtige Punkt so oft ignoriert, und worin liegt eigentlich die Schwierigkeit, ein gutes Sprintziel zu formulieren?

Vielleicht muss ich mit meinen Überlegungen ein wenig früher ansetzen und mich zuerst einmal fragen, warum ein Sprintziel so ungemein wichtig ist. In der täglichen Arbeit vieler Teams, in Gesprächen und auch in großen Teilen der Literatur wird dieses Thema leider sehr stiefmütterlich behandelt. Ich kann nur darüber spekulieren, warum das so ist, aber die Gründe sind eigentlich auch (schnurzpiep-)egal. Ich bin der festen Überzeugung, dass die Formulierung eines konkreten Sprintziels für unser Agiles Vorgehen von immenser Bedeutung ist.

Betrachten wir uns einfach einmal, was allzu häufig passiert, wenn ich auf ein Sprintziel verzichte: Product Owner und Team neigen dann dazu, den Sprint mit Dingen zu füllen, um ihn zu füllen. Das mag eine sehr harte Formulierung sein, aber ich habe die Beobachtung gemacht, dass viele Product Owner den Sprint zu einem guten Teil mit Anforderungen füllen, die aus einem Epic stammen und damit zusammengehören. So weit, so gut. Oder auch nicht. Überprüfen Sie sich und Ihr Team einmal kritisch, ob Sie wirklich nach jedem Sprint ein Inkrement shippen können.

Die Gefahr ist groß, dass man Anforderungen auswählt, die zwar irgendwie thematisch zueinander passen, zusammen aber kein Inkrement ergeben, weil man vielleicht nach Entwicklungsgesichtspunkten auswählt. Unsere Kollegen schildern uns (plausibel), dass es sinnvoll ist, jetzt die eine Sache gemeinsam mit der anderen zu tun. Dabei verlieren wir jedoch den Blick des Anwenders und nehmen die Position des Entwicklers ein. Was ist dabei das Problem?

Der Punkt ist, dass es dem Anwender vollkommen gleichgültig ist, was die Entwickler denken. Wenn dieser zwei Wochen länger auf die Verbesserung in der Software warten muss, weil es für uns leichter/angenehmer/einfacher war, etwas zu entwickeln, was nicht ihm sondern uns hilft, dann machen wir ihn damit nicht unbedingt glücklicher.

An dieser Stelle müssen wir natürlich vorsichtig sein. Selbstverständlich gibt es auch die Fälle, in denen es unsinnig wäre, einen in die Zukunft greifenden »Entwicklertask« nicht zu machen. Ich möchte nur darauf hinweisen, dass diese Dinge eine bewusste Entscheidung sein müssen. Unser Fokus liegt darauf, dem Anwender regelmäßig nutzbare Verbesserungen in der Anwendung zu geben. Wenn wir dies über allem stehende Ziel einen Sprint zurückstellen, müssen wir uns aktiv dafür entscheiden. Es sollte nicht automatisch geschehen.

Aber zurück zum Sprintziel. Vielleicht denken Sie, dass ich ein wenig vom Thema abgekommen bin, aber wir sind mittendrin. Einer der Hauptgründe für ein Sprintziel ist die Fokussierung auf ein kleines zu shippendes Softwareinkrement. Genau das definiere ich mit meinem Ziel.

Noch schlimmer ist es, wenn man sich keine Gedanken über Sprintziel und Softwareinkrement gemacht hat, und den Rest des Sprintbacklogs mit den schimmeligen Stories füllt, die irgendwo rumgammeln, damit man den Sprint nach der zu erwartenden Velocity gefüllt hat.

Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen

Was ist der Grund für eine einzelne Anforderung im Sprintbacklog? Sie ist klein genug, dass sie noch hineinpasst? Jede einzelne Anforderung in unserem Sprint muss sich darauf überprüfen lassen, ob sie unserem Ziel und damit dem nächsten Inkrement dient. Das kann ich jedoch nur tun, wenn ich mir über mein Ziel im Klaren bin. Und ich kann es auch nur dann tun, wenn ich mein Ziel konkret genug formuliert habe. Ziele wie »Feature XYZ vorantreiben« sind vollkommen sinn- und wertfrei. Anhand eines solchen Ziels kann ich nicht bei einer einzigen Anforderung überprüfen, dass sie einem kleinen scharf umrissenen Inkrement dient. Ich kann in diesem Fall lediglich prüfen, ob sie Teil meines Epics ist. Ein Epic ist in aller Regel jedoch viel mehr als ein einzelnes kleines Inkrement. Wenn ich nur auf Epic-Ebene denke, dann werde ich nur einmal alle paar Sprints etwas an meine Anwender geben können.

Sie sehen schon, wie diese Dinge ineinander greifen.

Ich muss mit meinen Überlegungen also noch ein wenig früher ansetzen. Wie oft will ich meinen Anwendern etwas geben? Nach jedem Sprint? Oder genügt es mir, wenn ich alle 3 oder 4 Sprints etwas an meine Anwender gebe? Habe ich diese Entscheidung überhaupt bewusst gefällt? Wenn nicht, dann möchte ich Sie bitten, das schnellstens zu tun. Ein zielgerichtetes Vorgehen wird Ihnen sonst sehr schwer fallen, weil Sie Ihre eigenen Rahmenbedingungen nicht definiert haben.

Haben wir uns darauf verständigt, dass es das Ziel ist, so oft wie möglich Verbesserungen zu shippen (im Idealfall jeden Sprint, in Ausnahmen auch erst nach zwei Sprints), dann habe ich die damit verbundene Aufgabe, eben diese Verbesserungen klar zu definieren. Und genau hier bin ich bei meinem Sprintziel angekommen. Und genau jetzt wird auch klar, warum ein Sprintziel eindeutig und kantenscharf umrissen sein muss. Mein Sprintziel definiert mein nächstes Softwareinkrement.

In Ausnahmen kann ich auch ein anderes Ziel definieren, z.B. wenn ich für ein größeres Feature zunächst eine bestimmte Infrastruktur herstellen muss und noch nicht soweit bin, dass ich nach einem Sprint etwas shippen kann. In diesem Fall definiere ich genau das als mein Ziel (vorausgesetzt ich kann dies auch in einem Sprint abarbeiten).

Was geschieht eigentlich, wenn mein Sprintziel zu groß ist?

Vollkommen egal, ob ich während des Plannings bemerke, dass ich mich übernehmen würde, oder ob ich bereits im Vorfeld erkenne, dass ein Inkrement auf zwei Sprints verteilt werden muss, ich werde im ersten Sprint nicht in der Lage sein, ein Ziel zu definieren, dass in ein Softwareinkrement mündet. Wir haben nun zwei Möglichkeiten: Zum einen könnten wir ein Ziel für zwei Sprints definieren, was das Problem mit sich bringt, dass es uns recht schwer fallen würde, uns während des ersten Sprint zu orientieren, ob wir noch on track sind. Zum anderen könnten wir das eigentliche Ziel splitten. Das Zweite ist die Fertigstellung und Auslieferung, das Erste ist ein Mini-Meilenstein auf dem Weg dahin. Wir brauchen das, damit wir immer überprüfen können, ob wir noch auf dem richtigen Weg sind, und ob wir schnell genug laufen. Dieser Mini-Meilenstein sollte sorgfältig gewählt werden. Eine 10%-90% Verteilung bringt und nicht wirklich voran. Aber auch eine Aufteilung »dann ist die Hälfte der Arbeit getan« ist nur bedingt sinnvoll. Orientieren Sie sich an den Anforderungen und versuchen Sie, Cluster zu bilden. Drei Anforderungen, die eng zusammenstehen, sind vielleicht das Ziel des ersten Sprints, zwei weitere bilden den Abschluss. Tiefer kann ich hier leider kaum einsteigen, da das Setting immer wieder unterschiedlich ist. Ich kann nur sagen, dass man auch diese Entscheidung bewusst fällen sollte.

Der wichtigste Punkt: Ein Sprintziel ist überprüfbar. Am Ende des Sprints kann ich anhand meiner umgesetzten Anforderungen eindeutig sagen, ob ich mein Ziel erreicht habe oder nicht. »Feature XYZ vorantreiben« bietet mir diese Möglichkeit nur sehr eingeschränkt. Habe ich es jetzt weiter gebracht, wenn ich diese drei Anforderungen umgesetzt habe? Was bedeutet das Ziel überhaupt? Was bedeutet »vorantreiben«?

Ein Sprintziel kann übrigens sehr gut als Userstory formuliert werden. »X kann Y tun, weil Z« gibt mir nicht nur einen ganz klaren Scope, es liefert sogar auch noch die Motivation, warum ich etwas tue. Mit einem so formulierten Ziel kann ich jede Anforderung meines Backlogs darauf checken, ob sie eben diesem Ziel dient und für dessen Erreichung notwendig ist. Einzelne Anforderungen würden das Verhalten der Software verbessern, sind aber vielleicht nicht zwingend notwendig, um eine Funktionalität zu nutzen. Ein klar formuliertes Sprintziel hilft uns also auch dabei, uns zu fokussieren und die wichtigen von den unwichtigen Dingen zu trennen.

Folgt mir auf twitter, um keine neuen Beiträge zu verpassen.

twitterrssyoutube
Facebooktwitterredditpinterestlinkedintumblr