Verzichtet dein Scrum Team auf Sprint-Ziele? 3 konkrete Tipps, wie du dies ändern kannst

Engagiert sich dein Scrum Team nicht in den Scrum Events? Fühlt sich jedes Event im Sprint gleich an, nur mit dem Unterschied, dass sich die Nummer des Sprints geändert hat?

Dafür kann es viele Gründe geben: Der Product Backlog enthält Arbeiten an unterschiedlichen Produkten. Dem Product Backlog fehlt es an Struktur. Der Product Owner beschreibt die Product-Backlog-Einträge nicht ausführlich. Die Stakeholder ändern ständig ihre Meinung, was die höchste Priorität für das Scrum Team haben sollte.

Ein Ratschlag, den ich in dieser Situation immer zu hören bekomme, lautet: Dein Team muss sich Ziele für den Sprint setzen. Selbst erfahrene Agile Coaches glauben, dass sich Sprint-Ziele magisch am Ende des Sprint Plannings von selbst ergeben. In meiner über 7-jährigen Arbeit mit Scrum Teams kann ich dir versichern, dass dem nicht so ist. Sprint-Ziele erfordern harte Arbeit und Hingabe von dir als Scrum Master! Mehr noch: Damit Scrum Teams effektiv mit Sprint-Zielen arbeiten, erfordert es nicht selten eine Transformation von dir als Scrum Master. Weg vom reinen Moderator der Scrum Meetings hin zu einem Scrum Master, der aktiv die Verantwortung für die Effektivität des Teams übernimmt und auch auf Stakeholder zugeht. 

Hier 3 Tipps, wie du diese Reise starten kannst und deinem Team hilfst, auf ein Ziel im Sprint hinzuarbeiten. Das Ergebnis wird nicht nur ein engagierteres Team sein, sondern auch mehr Transparenz in den Fragen: Was ist der Schnitt des Produkts? Wie sollte das Product Backlog strukturiert sein? Woran sollte das Scrum Team als Nächstes arbeiten?

Tipp #1: Bitte die Stakeholder im Sprint Review um Input

Der nächste Sprint beginnt nicht mit dem Sprint Planning, sondern bereits mit dem Sprint Review.

Das Sprint Review hilft Scrum Teams, auf das Ergebnis des Sprints zurückzusehen und die Zukunft des Produkts zu planen. Deshalb ist bei erfolgreichen Scrum Teams dieses Event keine Präsentation, in welcher das Team vorstellt, an welchen Tickets es im Sprint gearbeitet hat, sondern ein Arbeitstermin. Um diesen Arbeitstermin so produktiv wie möglich zu gestalten, hat es sich für mich bisher immer bewährt, neben dem Ausprobieren der aktuellen Version des Produkts, der Besprechung des Product Backlogs und Einschätzung der Marktsituation auch über das Ziel des nächsten Sprints mit den Teilnehmenden zu sprechen. 

Bitte etwa die anwesenden Stakeholder, folgende Frage zu beantworten:  „Angenommen, du wärst Product Owner im nächsten Sprint, welches Ziel würdest du für das Team ausgeben? Und was würde es unseren Nutzern ermöglichen?“

Tipp #2: Beginne die Sprint Planung mit der Findung eines Sprint-Ziels

Laut Scrum Guide sollen im Sprint Planning folgende drei Themen behandelt werden:

• Thema eins: Warum ist dieser Sprint wertvoll?

• Thema zwei: Was kann in diesem Sprint abgeschlossen (Done) werden?
• Thema drei: Wie wird die ausgewählte Arbeit erledigt?

Der Scrum Guide spricht hier explizit von drei Themen und nicht von drei Schritten, um festzuhalten, dass das Sprint-Ziel und die gewählte Arbeit während der Planung des Sprints angepasst werden können.

Mein Tipp lautet hier, das Rad nicht neu zu erfinden. Folge dem Scrum Guide und beginne die Sprint Planung mit der Definition des Sprint-Ziels. Neben dem Input von möglichen Sprint-Zielen der Stakeholder kannst du dein Team auch mit folgender Frage auffordern, einen Kandidaten für ein Ziel zu finden: „Wenn wir das Ziel dieses Sprints erreicht haben, wie hat sich dann unser Produkt aus der Sicht unserer Nutzer verändert?“

Um die Antwort festzuhalten, ist folgendes Template hilfreich: 

In diesem Sprint liegt unser Fokus auf <Ergebnis>.

Wir glauben, dass es <Nutzen> für <Nutzer> bringt.

Tipp #3: Überprüfe, ob das Sprint-Ziel einen Fokus für das Scrum Team ermöglicht

Nachdem ein Sprint-Ziel definiert wurde und passende Einträge aus dem Product-Backlog gewählt wurden, die es realisieren können, dann hilft es noch, zwei abschließende Tests zu machen. 

Der Erste lautet:

„Wenn wir plötzlich nur die Hälfte unseres Teams zur Verfügung hätten und wir deshalb nur die Hälfte der Arbeit, die für die Erreichung des Sprint-Ziels nötig ist, erledigen könnten, was sollte unbedingt erledigt werden und was könnten wir weglassen, um trotzdem das Ziel zu erreichen?“

Der zweite Test: 

„Sollte unser Sprint-Ziel ein ‚und‘ enthalten: Was müssten wir dann zuerst machen, wenn wir wählen müssten? Und was wäre unwiederbringlich verloren, wenn wir das andere erst im nächsten Sprint erledigen würden?“

Diese Tests helfen nicht nur „Stelle Item 1, 2 und 3 fertig“-Ziele zu entlarven, sondern sie helfen dem Team auch, noch mal zu überprüfen, ob ihr Ziel so gewählt ist, dass es Fokussierung im Sprint erlaubt. Am Ende sollten wir nicht vergessen, dass das Sprint-Ziel den Teammitgliedern zu jedem Zeitpunkt die Frage beantworten sollte: „Was ist im Moment das Wichtigste, an dem ich arbeiten sollte?“

Wenn du diese Tipps beherzigst, dann hilfst du deinem Team, Sprint-Ziele nicht als bedeutungslose Überschrift des Sprint Backlogs zu sehen, sondern als eine konkrete Manifestierung der Scrum-Werte Fokus und Commitment. Ich möchte aber ehrlich zu dir sein: Die Diskussion, welche du durch die Fragen nach den Tipps auslöst, wird nicht einfach werden. Allerdings wirst du dich, wenn du dich nicht entmutigen lässt und nicht aufgibst, die Wichtigkeit von Sprint-Zielen stets in den Fokus deines Scrum Teams und seiner Stakeholder zu rücken, von einem Meeting-Moderator-Scrum-Master, welcher für das Ergebnis des Teams keine Verantwortung übernimmt, zu einem effektiven Scrum Master wandeln. Einem Professional Scrum Master.