Schwierigkeiten bei der Einführung von Sprint-Zielen? 5 Methoden, die den Einstieg erleichtern

Jeder Scrum Master weiß um die Vorteile von Sprint-Zielen:

• Mit Sprint-Zielen wird der Zweck der Scrum Events viel klarer.
• Sprint-Ziele geben dem Team eine Richtung vor, aber erlauben gleichzeitig Flexibilität, wenn Hindernisse auftreten.
• Sie motivieren zur Zusammenarbeit zwischen den Teammitgliedern.
• Erst ein gemeinsames Ziel macht aus einer Gruppe von Experten ein wirkliches Team.
• Jeder Sprint bekommt eine eigene Bedeutung und unterscheidet sich somit vom letzten Sprint.

Allerdings nutzen nur wenige Teams Sprint-Ziele.

Viele Scrum Master stehen immer noch vor der Herausforderung, Sprint-Ziele in ihrem Team einzuführen. Dies wurde mir wieder einmal bewusst, als ich am 17. Mai ein Webinar zu den „17 Mythen über Scrum und wie du sie widerlegst“ hielt und es die meisten Rückfragen zu dem Mythos 3 gab: „Sprint-Ziele sind optional in Scrum.“

Die häufigsten Probleme, die Scrum Master davon abhalten, Sprint-Ziele einzuführen:

• Das Product Backlog besteht aus unterschiedlichen Themen.
• Es lassen sich nicht alle Einträge des Sprint Backlogs mit einem gemeinsamen Ziel vereinen.
• Im Sprint kommt es immer wieder zu ungeplanten Arbeiten.
• Es gibt mehrere Product Owner im Scrum Team und diese sehen unterschiedliche Prioritäten für den Sprint.
• Das Scrum Team hat keinen Kontakt zu echten Nutzern, da sie nur eine Komponente für ein anderes Team bereitstellen.

Wenn dir eine dieser Situationen bekannt vorkommt und du dir die Frage stellst: „Wie helfe ich meinem Team ein Sprint-Ziel zu definieren?“, dann lautet die bittere Wahrheit: Du musst einfach anfangen!

Diese Antwort ist erst einmal unbefriedigend. Allerdings gilt in der Produktentwicklung das Gesetz:

Perfektion ist das Gegenteil von Fortschritt.

Darauf zu warten, dass alle Arbeiten im Sprint auf ein Ziel einzahlen, dass es einen Grund gibt, wozu das Team diese Arbeiten durchführen will, dass es nur einen Product Owner gibt, der dafür die Verantwortung trägt, und dass jeder im Team Kontakt zu wirklichen Nutzern hat, – also, dass alles perfekt nach dem Scrum Guide läuft, bedeutet Stillstand.

Wenn du diese bittere Wahrheit akzeptierst, bist du bereit für die Verantwortung, die ein Scrum Master trägt.

Du übernimmst diese Verantwortung, indem du hilfst, den Ist-Zustand transparent zu machen. Eines der besten Werkzeuge dafür sind Sprint-Ziele. Sie machen viele Probleme transparent. Erst, wenn die Probleme transparent sind, können sie vom Team inspiziert und, wenn notwendig, gelöst werden. Darum geht es letztlich bei Empirie.

Konkret bedeutet Empirie:

1. Hilf dem Team, ein Sprint-Ziel zu definieren, auch wenn es nicht perfekt ist.
2. Unterstütze das Team dabei, seine Arbeit im nächsten Sprint ein wenig besser zu machen, indem du das Sprint-Ziel zum Gegenstand der Sprint Retrospektive machst.
3. Hilf dem Team im nächsten Sprint Planning wieder ein Sprint-Ziel zu definieren.

Diese Schritte wiederholen sich endlos. Das bedeutet kontinuierliche Verbesserung und ist bereits im Agilen Manifest für Softwareentwicklung als Prinzip festgehalten:

„In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an.“

Aus eigener Erfahrung weiß ich, wie schwierig es ist „einfach anzufangen“. Es erfordert viel Mut, dich all diesen Schwierigkeiten zu stellen. In den vergangenen 5 Jahren als Scrum Master haben mir folgende Methoden stets geholfen, das Gespräch im Sprint Planning auf Sprint-Ziele zu lenken und ein – häufig nicht perfektes – Sprint-Ziel mit dem Team zu definieren:

Methode 1: Kraftvolle Fragen stellen

Kraftvolle Fragen zeigen Möglichkeiten auf und laden zum Entdecken ein.

Meine bewährte kraftvolle Frage, die zur Definition eines Sprint-Ziels einlädt, lautet:

„Was soll nach diesem Sprint für unsere Nutzer anders sein?“

Immer wenn ich diese Frage bisher gestellt habe, hat sie ein Gespräch entfacht, welche Einträge im Backlog zusammengefasst und umgesetzt einen sichtbaren Unterschied für die Nutzer machen.

Hier eine weitere kraftvolle Frage. Sie stammt von Nicole aus der Q&A meines letzten Webinars:

„Ich frage den PO immer: Wenn morgen nur ein Entwickler da ist und dir eine Sache fertigstellen kann, – welche Sache soll er dir fertigstellen? Das ergibt das Sprint-Ziel. Die anderen Themen werden dann untergeordnet bearbeitet.“

Diese Frage ist super, da sie unterstreicht, dass nicht alle Arbeiten im Sprint Backlog auf das Sprint-Ziel einzahlen müssen.

Methode 2: Termineinladung formulieren

„Start with the end in mind.“

Dieser Gedanke hilft auch bei der Definition von Sprint-Zielen. Lade dein Team ein, am Anfang des Sprint Plannings eine Meeting-Einladung für das Sprint Review zu verfassen. Die Frage, von der du dich hier leiten lassen kannst, lautet:

„Wozu sollen die Stakeholder zum Review-Termin kommen? Was wird sie erwarten oder auf was können sie sich freuen?“

Dieses konkrete Meeting liefert dem Team ein Ziel, worauf die Teammitglieder in diesem Sprint hinarbeiten können.

Methode 3: Presseerklärung verfassen

Diese Methode stammt von der „Working backwards“-Philosophie von Amazon. Bei Amazon werden neue Initiativen häufig damit begonnen, dass ein Produktmanager eine interne Pressemitteilung verfasst, in der er das fertige Produkt ankündigt.

Eine typische Pressemitteilung beantwortet dabei:

• Wie lautet der Name des neuen Produkts?
• Was ist der Markt des Produkts und welchen Nutzen hat es?
• Welches Kundenproblem löst das Produkt?
• Auf welche elegante oder neue Art und Weise löst das Produkt dieses Problem?
• Wie lautet eine zitierfähige Aussage über das Produkt von einem Sprecher des Unternehmens?
• Wie würde ein Zitat von einem hypothetischen Kunden lauten, der den Nutzen des Produkts für sich feiert?
• Was soll der Leser der Mitteilung nun tun?

Wenn du jetzt mit deinem Team das Wort „Produkt“ durch „Sprint“ ersetzt, hast du eine wunderbare Methode, um das Ziel dieses Sprints ausführlich zu beschreiben.

Methode 4: Sprint-Goal-Canvas verwenden

Visualisierung der Arbeit ermöglicht Zusammenarbeit.

Das gilt auch für Sprint-Ziele. Eine bewährte Methode, ein Sprint-Ziel zu visualisieren, ist das Sprint-Goal-Canvas von Roman Pichler. Romans Canvas hilft, die Antworten auf die Fragen für jeden sichtbar festzuhalten:

• Warum lohnt es sich, diesen Sprint durchzuführen?
• Woran erkennen wir, dass der Sprint erfolgreich war?

Du findest den Canvas hier zum Download.

Methode 5: Stakeholder um Hilfe bitten

Dass Product Owner im Stillen perfekte Sprint-Ziele ausformulieren, die sie dann im Sprint Planning dem Team präsentieren, ist ein Irrglaube.

Der Scrum Guide schreibt:

„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.“

Das bedeutet zum einen, dass der Product Owner nur einen Vorschlag machen muss, und zum anderen, dass der Sprint für die Stakeholder wertvoll sein sollte. Der zweite Teil ist aus meiner Sicht eine Einladung, die Stakeholder zu fragen, was den Sprint für sie wertvoll machen würde. Diese Frage lässt sich gut im Sprint Review stellen: „Nachdem ihr den aktuellen Zustand des Produkts kennt, welche Richtung sollten wir als Nächstes verfolgen?“

Fabian hat dies in der Q&A im letzten Webinar schön auf den Punkt gebracht:

„[Das Sprint-Ziel] könnte auch eher gröber formuliert ein Ziel mit Visionscharakter sein.“

Als Scrum Master kannst du nun deinem Scrum Team helfen, die Antwort der Stakeholder zu konkretisieren, und erhältst ein Sprint-Ziel.

Welche Methode bevorzugst du? Ich freue mich auf deine Antwort in einem Kommentar!