In Kürze: Kein Sprint-Ziel
In einem Scrum-Projekt gibt es viele Möglichkeiten des Scheiterns. Angesichts der Umstand, dass Scrum ein Rahmenwerk mit einem angemessenen, aber kurzen „Handbuch“ ist, sollte dieser Effekt niemanden überraschen. Was ist zum Beispiel, wenn es kein Sprint-Ziel gibt – Sprint für Sprint? Was ist, wenn das Scrum-Team immer nur an einer zufälligen Auswahl von Aufgaben arbeitet, die zum Zeitpunkt der Sprintplanung am dringendsten zu sein scheinen?
Erfahren Sie in weniger als zwei Minuten, wie wichtig das Sprint-Ziel für die sinnvolle Arbeit in einem Scrum-Team ist.
🗳 Update: Join the poll and its lively discussion on LinkedIn.
🗞 Soll ich Sie über Artikel wie diesen informieren? Großartig! Sie können sich hier für den Newsletter „Food for Agile Thought“ anmelden und sich über 35.000 Abonnenten anschließen.
🎓 Nehmen Sie an einer von Stefans kommenden Professional Scrum-Schulungen teil!
📅 🎓 💯 🇩🇪 Garantierte Professional Scrum Master Schulung mit PSM I Zertifikat: 29. und 30. August 2022
📈 🔬 Join 450-plus peers and contribute to the anonymous poll for the upcoming Free ‘Product Owner and Product Manager Salary Report 2022!’
Der Zweck des Sprint-Ziels laut Scrum Guide
Laut dem Scrum Guide dient das Sprint-Ziel dem folgenden Zweck:
The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.
The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog. As the Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.”
Quelle: Scrum Guide 2020.
Das Sprintziel ist für das Scrum-Team vieles: ein Leuchtfeuer, das den Weg weist, wie man mehr Wert für die Kunden und das Unternehmen schaffen kann, ein Aufruf, als Team zusammenzuarbeiten, und ein Maßstab, um herauszufinden, ob der Sprint erfolgreich war.
Die erfolgreiche Festlegung des Sprint-Ziels ist daher ein entscheidender Schritt für jedes Scrum-Team. Das Sprintziel macht einen Sprint zu einer Teamaufgabe, die auf Zusammenhalt, Zusammenarbeit und Selbstmanagement beruht. Alles andere ist nur „Fließbandarbeit“, die wahrscheinlich dazu führt, dass das Team zu einer Feature-Fabrik wird.
Gründe, kein Sprint-Ziel zu haben
Meiner Erfahrung nach gibt es drei Hauptgründe, warum ein Scrum-Team nicht in der Lage ist, ein Sprintziel während der Sprintplanung zu formulieren:
- Konzentration auf die dringendsten Aufgaben: Der Product Owner schlägt eine Richtung für den kommenden Sprint vor, die einer willkürlichen Zusammenstellung von Aufgaben gleicht und keinen Zusammenhang erkennen lässt: „Wir müssen an 123, 426, 637, 845 und 343 arbeiten.“ (Möglicherweise hat das Scrum-Team kein Produktziel; es geht nur darum, den Betrieb aufrechtzuerhalten zu halten. Andererseits ist das Produkt vielleicht in einem so schlechten Zustand, dass es nur noch um die „Brandbekämpfung“ geht. Was auch immer der Grund ist, diese Anwendungsfälle eignen sich weniger gut für Scrum als ein Framework für die Produktentwicklung im komplexen Umfeld.)
- Produkt-Backlog auf den letzten Drücker erstellen: Der Product Owner und der Rest des Scrum-Teams investieren nicht ausreichend in die Erstellung und Verfeinerung des Produkt-Backlogs. Folglich versuchen sie, das Produkt-Backlog unmittelbar vor der Sprintplanung zu befüllen, um sicherzustellen, dass es genug Arbeit für den kommenden Sprint gibt. (Garbage in, garbage out. Dieser Ansatz deutet auf ein grundlegendes Missverständnis oder Unwissenheit in Bezug auf den Zweck von Scrum hin: a), wann es eingesetzt werden soll und b), was die kritischen Erfolgsfaktoren von Scrum sind, die für alle Beteiligten einen Mehrwert schaffen.)
- Jemand setzt ein Sprint-Ziel fest: Das Scrum-Team entscheidet nicht gemeinsam über das Sprint-Ziel, sondern ein Einzelner zwingt dem Team seine Vorstellung von einem Sprint-Ziel auf, z. B. ein externer Stakeholder. (Dies mag ein Sonderfall sein. Allerdings verstößt dies ebenfalls gegen die ersten Prinzipien von Scrum, da Scrum ein Framework ist, das auf Pull und nicht auf Push basiert. Das Scrum-Team ist keine interne Agentur, sondern eine sich selbst managende Einheit, die die Aufgabe hat, Kundenprobleme zu lösen.)
Die Konsequenzen: Wenn Ihre Sprint-Planung typischerweise nicht mit der Festlegung eines Sprint-Ziels endet, so haben Sie Scrum wahrscheinlich als Framework nie angenommen. Oder Sie haben die Nützlichkeit von Scrum als Framework für Ihre Produktentwicklung bereits hinter sich gelassen. In letzterem Fall könnte sich Kanban je nach Reifegrad Ihres Produkts als bessere Lösung erweisen. Andernfalls könnte die Willkür in Hinblick auf das Sprintziel auf schwache Product Owner hindeuten, die zu sehr auf die Stakeholder hören, anstatt sich um die Erreichung des Produktziels zu kümmern und das Produkt-Backlog entsprechend zusammenzustellen und zu ordnen.
Die Lösung: Gehen Sie zurück zu den Grundlagen des Frameworks, indem Sie das ursprüngliche Ziel der Sprintplanung verfolgen: Abstimmung zwischen den Entwicklern und dem Product Owner darüber zu erzielen, was als Nächstes gebaut werden soll, um den Kunden den größtmöglichen Nutzen zu bieten. Hierzu verweist der Product Owner zunächst auf das Produktziel des Teams und stellt das wirtschaftliche Ziel des bevorstehenden Sprints vor. Das Scrum Team erstellt dann gemeinsam ein Sprint-Ziel, wobei es berücksichtigt, wer verfügbar ist und welches Ziel das Team erreichen soll. Als Nächstes prognostizieren die Entwickler die Arbeit, die zur Erreichung des Sprintziels erforderlich ist, indem sie die richtigen Elemente aus dem Product Backlog auswählen und sie in das Sprint-Backlog übertragen. Außerdem müssen die Entwickler einen Plan erstellen, wie sie ihre Prognose verwirklichen wollen. Das hört sich zwar einfach an, aber es kann einige Zeit in Anspruch nehmen, bis das Scrum Team so weit ist. Zunächst müssen Sie ein Produktziel und anschließend das korrespondierende Produkt-Backlog erstellen. (Niemand hat behauptet, dass die Einführung von Scrum für Ihr Team einfach sein würde.)
📖 Kein Sprint-Ziel — Weitere Lektüre
27 Sprint Anti-Patterns Holding Back Scrum Teams
Fixing Your Scrum: A Forensic Product Backlog Analysis (Part 1)
Overruling the Product Owner? — Making Your Scrum Work #21
27 Product Backlog Anti-Patterns
27 Sprint Anti-Patterns Holding Back Scrum Teams
20 Sprint Planning Anti-Patterns
24+2 Daily Scrum Anti-Patterns
15 Sprint Review Anti-Patterns
21 Sprint Retrospektive Anti-Patterns
Download the Scrum Anti-Patterns Guide for free
✋ Nicht versäumen: Lernen Sie mehr über Sprintziele im 12.000-köpfigen „Hands-on Agile Slack Team“
Ich lade Sie ein, sich dem „Hands-on Agile“ Slack-Team anzuschließen und die Vorteile einer schnell wachsenden, lebendigen Gemeinschaft von agilen Praktikern aus der ganzen Welt zu genießen.
Wenn Sie jetzt beitreten möchten, müssen Sie nur noch Ihre Anmeldeinformationen über dieses Google-Formular angeben, und ich werde Sie anmelden. Die Mitgliedschaft ist kostenlos.
Der Artikel Kein Sprint-Ziel — Making Your Scrum Work #26 erschien zuerst auf Berlin-Product-People.com.