Kämpft dein Scrum Team damit, sich Ziele zu setzen?
Anfang 2019 stieß ich zu einem Scrum Team, welches das ganze letzte Jahr damit verbracht hatte, die Infrastruktur und Backend-Services für eine neue Versicherungsplattform zu entwickeln. Zu meinem Erschrecken hatten sie bis dato noch nichts geliefert, was ein Kunde wirklich nutzen konnte.
Mein Ansatz, um das zu ändern, lautete: Sprint-Ziele
Anfang 2020 hatten wir über 20 Produktinkremente ausgeliefert, die die Nutzer auch verwendeten.
Der Schlüssel dazu waren Sprint-Ziele, die
- auf Ergebnisse fokussiert waren,
- alle Beteiligten miteinbezogen,
- spezifisch und
- messbar waren.
Wenn dein Team auch Probleme damit hat, gute Sprint-Ziele zu formulieren, dann lass mich dir mein Rezept geben. Es wird dir eine Menge Zeit ersparen.
Punkt 1: Auf Ergebnisse fokussieren
Ein Sprint-Ziel, das keinen Output beschreibt, sondern ein Outcome, ändert alles!
Damit sich unser Team nicht mehr nur auf die Umsetzung technischer Features wie Datenverwaltung, Skalierbarkeit, Ausfallsicherheit, Monitoring und Logging konzentrierte, musste ich ein Bewusstsein für Wert schaffen. In allen Köpfen musste sich verankern, dass die Entscheidung, ob unsere Arbeit wertvoll ist, ausschließlich der Nutzer oder der Kunde trifft.
Wie erreichen wir eine solche Mindset-Änderung?
Mein bewährtes Mittel sind Ziele, welche eine konkrete Veränderung im Nutzerverhalten beschreiben und keine Funktionalität. Der Unterschied an einem Beispiel erklärt: Ein Ziel, was lediglich einen Output beschreibt, lautet: Erstelle eine Log-in-Funktionalität. Ein Ziel, welches hingegen ein Outcome beschreibt, lautet: Der Nutzer hat sich am System angemeldet.
Nachdem jedem im Team bewusst war, was am Ende des Sprints für unseren Nutzer anders sein sollte, mussten alle dafür motiviert werden, daran mitzuarbeiten.
Punkt 2: Alle Beteiligten miteinbeziehen
Menschen sind motiviert, wenn sie das Ziel mitgestalten können.
Um das zu erreichen, sollte sich die Erstellung eines Sprint-Ziels keinesfalls nur auf das Sprint Planning beschränken oder nur vom Product Owner vorgenommen werden. Ein gutes Sprint-Ziel zu finden, beginnt bereits im Sprint Review. Nach dem Ausprobieren des aktuellen Inkrements, der Analyse der aktuellen Marktsituation und der Vorstellung des Product Backlogs ist es hilfreich, die Stakeholder zu fragen, was aus ihrer Sicht ein lohnendes nächstes Ziel sei. Eine gute Frage hierfür lautet: „Basierend auf der aktuellen Situation – welche Frage sollten wir im nächsten Sprint unbedingt beantworten?“ Diesen Prototyp eines Sprint-Ziels haben wir dann im Sprint Planning in unserem Team weiter verfeinert. Die Verfeinerung ging so lange, bis das Ziel für die Entwickler machbar erschien.
Erst wenn die Richtung für das nächste Sprint-Ziel mit den Stakeholderwünschen abgeglichen und die Machbarkeit von den Entwicklern bestätigt wurde, ziehen alle Beteiligten wirklich an einem Strang.
Punkt 3: Ziele müssen spezifisch sein
Bei der Beschreibung von Sprint-Zielen sollte der Pragmatismus stets die Oberhand behalten.
Es gibt viele Philosophien, wie ein Team gute Ziele setzt. SMART, 4DX, FAST, HEART, OKRs oder Goal-Canvas sind nur einige prominente Beispiele. Was im Sprint Planning aber wirklich hilft, ist die einfache und praktische Umsetzbarkeit. Dabei hat sich für unser Team bewährt, dass ein effektives Sprint-Ziel eine Sache auszeichnet:
Es ist spezifisch.
Dies lässt sich einfach erreichen, wenn das Ziel eine konkrete beobachtbare Veränderung im Verhalten eines Nutzers beschreibt. Zum Beispiel: „Nachdem sich der Benutzer am System angemeldet hat, erhält er eine Mitteilung, dass die Anmeldung erfolgreich war.“ Dieses Sprint-Ziel ist konkreter als „der Nutzer hat sich am System angemeldet“.
Ich habe folgende Beobachtung gemacht: Je spezifischer ein Ziel vom Team formuliert werden kann, desto besser wurde es verstanden.
Punkt 4: Der Erfolg muss messbar sein
Woran erkennen das Scrum Team und die Stakeholder, dass das Ziel erreicht wurde?
Daran, dass es messbar ist.
Ich muss gestehen, anfangs haben wir gemessen, ob ein Sprint-Ziel erreicht wurde oder nicht, indem wir ein Daumen-Voting im Team gemacht haben. Ein objektiverer Ansatz ist es, das Ziel messbar zu formulieren. In unserem Beispiel könnte es so lauten: „Bis zum nächsten Sprint Review haben sich mindestens 10 Nutzer erfolgreich System angemeldet.“ Ob dieses Ziel erreicht wurde, lässt sich jetzt einfach im Sprint Review gemeinsam mit den Stakeholdern überprüfen.
Wichtig hierbei ist, dass das Messkriterium das Ergebnis – die beobachtbare Verhaltensänderung beim Nutzer – widerspiegelt.
Wert entsteht erst dann, wenn die entwickelten Features wirklich von Nutzern verwendet werden. Bis dahin verursacht alles, was wir in der Produktentwicklung tun, nur Kosten. Es beruht rein auf der Hoffnung, dass es sich lohnen wird.
Als wir angefangen haben, diese 4 Punkte bei der Formulierung der Sprint-Ziele konsequent umzusetzen, hat sich ein Verständnis für Wert in unserem Team etabliert.
Dadurch habe ich gelernt, dass die Fokussierung auf einige kleine Details große Veränderungen bewirken kann. Wir müssen lediglich konsequent in deren Umsetzung bleiben.
Möchtest Du mehr erfahren?
Hoffentlich war dieser Artikel nützlich für Dich. Wie man das Sprint-Ziel definiert, ist eines der vielen interessanten Themen, die in meinen Professional Scrum Trainings behandelt werden.
Wenn du keinen neuen Beitrag mehr verpassen willst, dann abonniere meinen Newsletter, dort wirst du als Erster über neue Beiträge informiert.
👉 Hier geht zur Anmeldung.