Im Jahr 2015 war ich zum ersten Mal Product-Owner. Im Sprint-Planning verstand ich meine Aufgabe so:
- Den Entwicklern das Ziel für den Sprint vorgeben.
- Den Sprint in Jira mit den passenden User-Stories füllen.
- Den Entwicklern diese Stories im Meeting vorstellen.
- Den Entwicklern ein Versprechen abringen, was sie davon alles erledigen können.
Für die Vorstellung brauchte ich nicht länger als eine halbe Stunde. Die Diskussion, die folgte, dauerte häufig den restlichen Tag.
Vertrauensvoll wandte ich mich an meinen Mentor, unseren damaligen Scrum Master, und bat ihn um Unterstützung.
Ich begriff mich als Kapitän des Schiffs.
Ich war überzeugt, dass ich als Product-Owner der Kapitän des Teams bin. Ich gab die Richtung vor. Ich legte die Geschwindigkeit fest. Und zu jeder Zeit hatte ich das Ruder fest im Griff.
Zunächst bestärkte er mich in meiner Überzeugung.
Er erinnerte mich daran, dass mir in unserer komplizierten Dienstleisterbeziehung mit der Entwicklung wahrscheinlich nichts anderes übrig bleiben würde, als die Arbeit detailliert vorzugeben. Dann warnte er mich aber auch davor, dass diese Vorgehensweise wahrscheinlich dazu führen würde, dass jeder Entwickler nur Dienst nach Vorschrift macht. Und dass wir so niemals ein Team werden würden. Es dauerte ewig, bis ich die Lektion hinter seinem Rat verstand.
Nach 10 Jahren Arbeit in Scrum Teams und mit Sprint-Zielen kann ich Folgendes festhalten:
Lektion #1: Sprint-Ziele werden nicht vom Product-Owner bestimmt
Ich bin nicht der Einzige, der den Product-Owner mit einem Kapitän verwechselte und glaubte, dass er das Sprint-Ziel definieren würde.
Woher kommt dieser Irrglaube?
Der Scrum Guide ist nicht ganz unschuldig daran. Betrachten wir die Version aus dem Jahr 2013. Dort steht im Abschnitt zum Sprint-Planning:
„Das Entwicklungsteam erstellt eine Prognose über die Funktionalität, die im Sprint entwickelt werden soll. Der Product-Owner beschreibt das Ziel, das mit dem Sprint erreicht werden soll, und die Product-Backlog-Einträge, welche – wenn sie in dem Sprint abgeschlossen werden – das Ziel erfüllen.“
Wenn ich ehrlich bin, lese ich diese Version so, dass der Product-Owner das Sprint-Ziel definiert. In der aktuellen Version finde ich es eindeutiger beschrieben. Die Version aus dem Jahr 2020 gibt eine bessere Handlungsempfehlung:
„Der Product-Owner schlägt vor, wie das Produkt im aktuellen Sprint seinen Wert und Nutzen steigern könnte. Das gesamte Scrum Team arbeitet dann zusammen, um ein Sprint-Ziel zu definieren, das verdeutlicht, warum der Sprint für die Stakeholder wertvoll ist.“
Und da nicht wenige Scrum Master und Product-Owner nicht die neueste Version des Guides kennen, hält sich dieser Irrglaube wahrscheinlich so hartnäckig.
Wie schaffst du es als Product-Owner, die Richtung des Sprints vorzugeben und gleichzeitig das „Wir“-Gefühl zu stärken?
Für mich hat es sich bewährt, die Entwickler von Anfang an bei der Definition des Sprint-Ziels miteinzubeziehen.
Ich gehe dabei in vier Schritten vor:
- Jeder im Team nimmt sich Zeit, über ein lohnenswertes Ziel für diesen Sprint nachzudenken.
- Die Mitglieder im Team bilden Paare, dann teilen sie ihre Ideen für ein Ziel. Dabei achten sie auf Gemeinsamkeiten.
- Nun besprechen die Paare in Vierergruppen ihre Ziele und versuchen sie zu verbinden.
- Jedes Quartett teilt seine Ziele und die wichtigsten Erkenntnisse aus der Diskussion mit allen im Team.
Genügt diese Diskussion nicht, um ein gemeinsames Ziel für den Sprint zu finden, dann kann über die Vorschläge mit einem kurzen Dot-Voting abgestimmt werden.
Jeden im Team bei der Definition des Sprint-Ziels einzubeziehen, wird sich lohnen:
Denn wir sollten nicht vergessen, dass Ziele helfen, aus Zusammenarbeit echte Teamarbeit zu machen. Für Sprint-Ziele ist dies sogar wissenschaftlich nachgewiesen. Whitworth und Biddle fanden im Jahr 2007 heraus, dass in agilen Teams das Engagement für Teamziele den Zusammenhalt, die Teameffektivität, den Wissensaustausch und die Feedback-Prozesse erhöht.
Lektion #2: Sprint-Ziele sollten Ergebnisse für Nutzer beschreiben
Seit einigen Jahren ist die „Outcome over Output“-Debatte in der agilen Community in vollem Gang.
Ich beobachte das mit gemischten Gefühlen.
Am liebsten erkläre ich den Unterschied zwischen „Output“ und „Outcome“ mit dem Logik-Modell:
Das Logik-Modell zeigt einen Entwicklungsprozess.
Aus Inputs wird mittels Aktivitäten neuer Output produziert. Für den Erfolg eines Produkts ist Output aber nicht genug. Die Nutzer müssen es auch nutzen wollen. Es muss ein Problem für sie lösen. Das ist mit Outcomes gemeint. Nur Ergebnisse erzeugen Wert für die Nutzer. Und diesen erzeugten Wert beim Kunden müssen wir dann wieder fürs Unternehmen einfangen – etwa indem die Nutzer dafür bezahlen. Das bedeutet dann einen Impact fürs Unternehmen.
Die Befürworter von „Outcome over Output“ argumentieren, dass Scrum Teams sich auf „Outcomes“ konzentrieren müssen. Denn nur Ergebnisse für den Kunden stellen wirklich Wert dar. Dem stimme ich erstmal zu.
Es gab eine Zeit, da bin ich als Scrum Master auch dem „Outcome“-Fanatismus verfallen. Ich habe das Team ständig darauf gedrängt, mehr – oder einzig und allein – über den Outcome nachzudenken. Deshalb musste beim Sprint-Ziel unbedingt auch das „Outcome“, also wozu wir diesen Sprint unternehmen, im Zentrum stehen. Was ich dabei übersehen habe:
Ohne „Output“ kein „Outcome“.
Als Scrum Master müssen wir Teams dort abholen, wo sie sind, und ihnen dann Schritt für Schritt helfen. Und die bittere Wahrheit ist: Ist ein Team nicht in der Lage, zu liefern, dann ist das größte Problem nicht, welches Outcome im Fokus stehen sollte. Oder anders ausgedrückt: Das Sprint-Ziel „75 % der Nutzer nutzen Feature Y“ ist zwecklos, wenn das Team Feature Y am Ende des Sprints nicht ausliefern kann. Dann sollte das Sprint-Ziel besser lauten:
„Feature Y ist in einer Testumgebung nutzbar und kann von Stakeholdern validiert werden.“
Lektion #3: Sprint-Ziele müssen nicht SMART sein
Ziele müssen die SMART-Kriterien erfüllen.
Darüber ist sich auch die agile Community einig. Aber hast du bereits versucht, ein Sprint-Ziel wirklich SMART zu machen? Im Jahr 2019 habe ich in einem Sprint gearbeitet und unser Team wollte eine weitere Funktion zur Bezahlung im Webshop hinzufügen.
Unser Ziel lautete etwa:
„Wir ermöglichen den Nutzern, mit Kreditkarte zu bezahlen.“
Nun lass uns das Ziel gemeinsam SMARTer machen:
- Spezifisch: Das Ziel ist noch recht vage formuliert. Was genau bedeutet „ermöglichen“? Deshalb: „Wir integrieren die Visakartenzahlung über den Zahlungsanbieter XYZ und stellen sicher, dass Kunden damit Bestellungen abschließen können.“
- Messbar: Wie stellen wir fest, dass das Ziel erreicht ist? „Ein Nutzer kann erfolgreich eine Bestellung mit einer Kreditkarte abschließen und die Zahlung wird im System als erfolgreich verbucht.“
- Realistisch: Ist das Ziel im Sprint machbar? Eher nicht. Deshalb: „Wir implementieren die Kreditkartenintegration im Testmodus und führen erfolgreiche Testtransaktionen durch.“
Das SMARTere Sprint-Ziel:
„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 darin liegt meine Kritik an SMART-Zielen: Scrum ist ein Teamsport. Es braucht Spaß, Motivation und Leidenschaft. Deshalb ist die wichtigste Frage bei Sprint-Zielen nicht, ob sie SMART sind, sondern:
Hat unser Sprint-Ziel einen lustigen oder zumindest einprägsamen Titel? Wer hat Bock, daran zu arbeiten?
Deshalb kann ich mich nicht mehr an den Kreditkarten-Sprint erinnern. Sehr wohl aber an den Sprint während der Weihnachtsferien 2018 bei der Bundesagentur für Arbeit. Unser Ziel lautete:
„Keep the lights on“
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.
Suchst du noch weitere pragmatische Tipps für Sprint-Ziele? Willst du den nächsten Schritt deiner Product-Owner-Karriere gehen?
Dann besuche unser nächstes „Professional Scrum Product Owner – Advanced“-Training. Dort unterstützen Peter und ich dich auf deinem Weg, ein besserer Product-Owner zu werden.