Was macht ein Sprintziel wirklich gut?
Nach über 10 Jahren Scrum habe ich viele Templates ausprobiert. Heute will ich 3 davon bewerten und mit dir besprechen. Bereit?
Dann lass uns loslegen:
Template #1: SMARTe Ziele
Bis zum Jahr 2019 war ich überzeugt, dass Sprintziele SMART sein sollten.
Hierbei steht SMART für:
- Spezifisch (Was genau wollen wir in diesem Sprint erreichen?)
- Messbar (Woran merken wir, dass das Sprintziel erreicht wurde?)
- Attraktiv (Wie motivierend ist es für das Team, dieses Ziel zu verfolgen?)
- Realistisch (Ist die Zielerreichung in diesem Sprint realistisch?)
- Terminiert (Bis wann muss es erreicht sein?)
Das letzte Kriterium sollte sich eigentlich erübrigen, da ein Sprintziel für einen Sprint gilt.
So die Theorie.
Ich will ehrlich mit dir sein: Dies war nicht immer der Fall. Deshalb bin ich sehr froh, dass im Jahr 2020 Produkt-Ziele offizieller Bestandteil von Scrum wurden. Seither muss ich mir weniger Gedanken machen, wenn das Ziel des Teams mal für drei Sprints gilt.
Hast du bereits versucht, ein Sprintziel wirklich SMART zu machen?
Im Jahr 2019 habe ich in einem Team gearbeitet, das eine weitere Bezahlfunktion im Webshop hinzufügen wollte. Unser Ziel lautete etwa:
„Wir ermöglichen den Nutzern, mit Kreditkarte zu bezahlen.“
Wenn wir dieses Ziel SMART machen, erhalten wir:
„Bis zum Ende des Sprints integrieren wir die Visakartenzahlung über den Anbieter XYZ, sodass Nutzer im Testsystem erfolgreich eine Zahlung durchführen können.“
Und jetzt mal Hand aufs Herz: Wie motivierend ist dieses Ziel?
Genau. Nicht sonderlich. Und deshalb nutze ich seither immer weniger die SMART-Kriterien, um Sprintziele zu formulieren.
Template #2: FOCUS von Maarten Dalmijn
„Keep the lights on!“
So lautete ein Sprintziel über die Weihnachtsferien 2018 in einem Scrum Team bei der Bundesagentur für Arbeit.
Nicht SMART. Dafür motivierend.
Denn die primäre Aufgabe unseres Teams bestand darin, den Betrieb sicherzustellen und die Infrastruktur zu entwickeln. Und über die Weihnachtstage wollten zwei Entwickler noch einige Aufräumarbeiten abschließen. Das Team stimmte dem zu, allerdings nur unter der Bedingung: Sie durften nichts kaputt machen. Niemand hatte Lust, vorzeitig aus dem Urlaub zurückzukommen, nur weil die Systeme nicht mehr online waren.
Rückblickend hätte mir damals ein praktisches Hilfsmittel geholfen, damit ich auch motivierende Sprintziele klar formulieren konnte. Genau ein solches Hilfsmittel habe ich später bei Maarten Dalmijn entdeckt. In seinem Buch „Driving Value with Sprint Goals“ schlägt er die FOCUS-Kriterien vor.
Wie INVEST für User-Stories funktioniert, hilft FOCUS, Sprintziele solide zu formulieren.
- Fun: Hat unser Sprintziel einen lustigen Titel oder zumindest einen einprägsamen Titel?
- Outcome-orientiert: Können wir verschiedene Wege finden, um dasselbe Ergebnis zu erreichen?
- Kollaborativ: Haben wir das Sprintziel gemeinsam mit dem gesamten Team festgelegt?
- Ultimativ: Ist der relevante Kontext gegeben, der deutlich macht, warum das Ziel wichtig ist?
- Spezifisch: Handelt es sich um ein einziges Ziel und nicht um eine Liste von (unzusammenhängenden) Zielen?
Seitdem ich sein Buch gelesen habe, nutze ich seine Kriterien.
Template #3: Nach dem Outcome fragen
Ein Satz hat meine Gedanken über Scrum verändert:
„Wie können uns Sprints eine Reihe von Hypothesen und Experimenten vorstellen, die alle darauf abzielen, ein Outcome zu erzielen?“
Ich glaube, es war Jeff Gothelf, von dem ich die Frage gehört habe.
Was meinte er hier mit Outcome?
Ergebnisse lassen sich in drei Kategorien einteilen, die aufeinander aufbauen. Dies lässt sich gut anhand des Logik-Modells zeigen:
- Outputs sind die greifbaren Ergebnisse der geleisteten Arbeit. Beispiele: ein neues Dashboard-Feature, ein verbesserter Onboarding-Prozess, ein überarbeitetes Interface, ein Release-Update.
- Outcomes beschreiben beobachtbare Verhaltensänderungen bei Nutzern durch den Output. Beispiele: 70 % der Nutzer nutzen das neue Dashboard täglich, 40 % schließen den Onboarding-Prozess schneller ab.
- Impacts drücken die Wirkung der Outcomes auf das Unternehmen aus. Beispiele: steigende Nutzerbindung, höhere Conversion-Rate, reduzierte Supportanfragen.
Was macht ein Produkt erfolgreich?
Wenn ein Impact für das Unternehmen erzeugt werden kann. Allerdings stellt sich ein Impact nur ein, wenn wir ein entsprechendes Ergebnis (Outcome) für unsere Nutzer erzielen. Nach Jeff Gothelf sollte das unser Ziel sein. An diese Denkweise versuche ich auch alle Teams heranzuführen. Eine Möglichkeit besteht darin, Sprintziele so zu formulieren, dass sie den Outcome für unsere Nutzer und Kunden beschreiben.
Hierzu nutze ich diese Frage:
„Was soll nach diesem Sprint für unsere Nutzer anders sein?“
Diese Frage führt das Team weg von den Features oder Einträgen des Product-Backlogs, welche sie diesen Sprint entwickeln wollen – also dem Output –, hin zu dem Outcome, den sie damit ihren Nutzern ermöglichen wollen.
Drei Erkenntnisse über die Jahre mit dieser Frage:
- Der Outcome muss sich nicht direkt im Sprint einstellen. Bis Nutzer das Feature wirklich nutzen und ein Outcome gemessen werden kann, dauert es häufig länger als zwei Wochen. Deshalb auch die Formulierung „nach diesem Sprint“.
- Je spezifischer, desto besser: „Für unsere Nutzer“ ist hier als Platzhalter gedacht. Welche Nutzer? Neukunden, langjährige Premium-Kunden oder inaktive Nutzer?
- Das Wort „anders“ macht den Unterschied. Hier beschreiben wir den Outcome, also eine Verhaltensänderung, die wir bei unseren Nutzern messen können. Etwa: „15 % schließen den Onboarding-Prozess schneller ab“.
Wenn du dir jetzt denkst: „Nutzer? Mein Team kennt seine Nutzer nicht“, dann habe ich noch ein weiteres Template für dich:
Bonus-Template: Die Einladungen
Ich will ehrlich mit dir sein.
Mit outcome-orientierten Sprintzielen wie:
„Nach diesem Sprint sollen Neukunden den Onboarding-Prozess um 15 % schneller abschließen“,
zu arbeiten, sollte das Ziel jedes Scrum Teams sein. Allerdings weiß ich auch, dass solche Ziele für viele Teams noch ein weiter Weg sind. Ich habe mit Teams gearbeitet,
- die noch nie mit einem Nutzer gesprochen haben,
- ihre Kunden nicht kannten oder
- jeden Sprint nur ein Sammelsurium von Bugs, Anfragen und Features für unterschiedlichste Projekte umgesetzt haben.
Hätte ich ihnen die Frage gestellt:
„Was soll nach diesem Sprint für unsere Nutzer anders sein?“,
hätte ich wahrscheinlich sofort ihr Vertrauen in mich verloren. Zu Recht hätten sie gesagt: „Sprintziele funktionieren hier nicht.“
In solch einer Situation braucht es mehr Fingerspitzengefühl.
Wenn Nutzer und Kunden (noch) außerhalb der Reichweite des Teams liegen, dann stelle ich erst einmal nur diese Frage:
„Wozu sollen die Stakeholder zum Review-Termin kommen? Was wird sie erwarten oder worauf können sie sich freuen?“
Hier die Frage als Template zum Ausfüllen im Sprint-Planning:
Ich gehe meist einen Schritt weiter und bitte das Team,
- eine Einladung (mit Agenda) zu formulieren,
- diese in MS Outlook einzustellen und
- die Kollegen einzuladen, die kommen sollen.
Jetzt kennst du meine Templates, um Sprintziele zu formulieren.
Sind Sprintziele nicht das einzige Problem deines Scrum Teams?
Dann empfehle ich dir das „Professional Scrum Master – Advanced“-Training.
Dort lernst du:
- wie du die Definition-of-Done nutzt, um Risiken in der Softwareentwicklung frühzeitig zu erkennen,
- Strategien, die Product-Ownern in jeder erdenklichen Misslage helfen werden,
- ein Vorgehen, mit dem du mit jedem Stakeholder Gespräche über Veränderung strukturiert durchführst,
- mit welchen Metriken du den Erfolg deines Teams quantifizieren kannst
- und noch viel mehr.
Neugierig, wie das Training abläuft? Dann wirf doch einen Blick hierauf:
271 Scrum Master sind meiner Empfehlung bereits gefolgt – vielleicht lernen wir uns auch bald persönlich im Training kennen?
Marc und ich freuen uns schon.
Bis dahin … Scrum on.