Nachdem wir im ersten Teil dieser Reihe die verschiedenen Rollen eines Scrum Teams beleuchtet haben, geht es hier um die Ereignisse in Scrum, die sogenannten Events. Diese sorgen in Scrum für einen regelmäßigen Ablauf und verringern automatisch die Anzahl von weiteren Besprechungen.  

Alle Scrum Events haben eine sogenannte Time Box, also eine festgelegte maximale Dauer. Maximal bedeutet: Wenn ihr Zweck erfüllt ist, können sie auch früher enden. Events sind grundsätzlich dafür da, Transparenz zu schaffen und eine Überprüfung und Anpassung zu ermöglichen. Wird ein Event im Sprint weggelassen, führt das zu weniger Transparenz und dadurch zu einer Möglichkeit weniger, auf den aktuellen Stand zu reagieren. Für die Events gibt es innerhalb eines Sprints eine festgelegte Aufgabe und eine zeitliche Reihenfolge, in der sie stattfinden sollen. 

Die Aufgaben des Scrum Masters sind bei allen Events gleich, er 

• erstellt den Termin und sorgt damit für das Zustandekommen des Events, 
• gewährleistet, dass die Teilnehmer den Zweck des Events verstehen, 
• bringt dem Scrum Team bei, wie es erfolgreich die Time Box eines Events einhalten kann.

Was ist eigentlich ein Sprint? 

Ein Sprint wird im Scrum Guide als Container für die anderen Events beschrieben. Er umfasst einen Zeitraum (Time Box) von maximal einem Monat, in dem ein potenziell auslieferbares Produktinkrement (ein Teil des Gesamtproduktes) erstellt wird. Während eines Sprints möchte man also das erreichen, was zuvor im Sprint-Ziel festgelegt wurde. Idealerweise sind alle Sprints gleich lang, um eine Regelmäßigkeit herzustellen. Ein neuer Sprint beginnt sofort, wenn der vorherige Sprint abgeschlossen ist. Nur der Product Owner kann einen Sprint abbrechen, bevor die Time Box erreicht wird –wenn das Sprint-Ziel obsolet wird, weil sich zum Beispiel technische Rahmenbedingungen geändert haben.  

Events in einem Sprint sind: 

• Sprint Planning 
• Daily Scrum 
• Refinement 
• Sprint Review 
• Sprint Retrospektive 

Sprint Planning 

Mit diesem Event beginnt jeder Sprint. Hier wird festgelegt, was während des Sprints getan werden soll, also welchen Umfang er hat. An diesem Event nimmt das gesamte Scrum Team teil: Product Owner, Scrum Master und das Development Team. Die Time Box für das Planning sieht maximal acht Stunden bei einem vierwöchigen Sprint vor. Wenn der Sprint kürzer ist, passt sich die Time Box üblicherweise an.  

Bei einem Planning stellt sich das Scrum Team zwei Fragen: 

1. Was kann in diesem Sprint fertiggestellt werden? 

Hier beschreibt der Product Owner, was sein Ziel für den Sprint ist und welche Product-Backlog-Einträge dafür nötig sind. Das gesamte Team erarbeitet sich ein Verständnis von den anstehenden Aufgaben, das Development Team erstellt eine Prognose über die Funktionalität, die in diesem Sprint erreicht werden soll. Wichtige Faktoren sind dabei der aktuelle Stand des Produktes, die Kapazität des Development Teams und dessen bisherige Leistung. Die endgültige Entscheidung, welche Aufgaben in den Sprint genommen werden und welche nicht (Sprint Backlog), trifft allein das Development Team. Danach wird das Sprint-Ziel endgültig formuliert. 

2. Wie wird die ausgewählte Arbeit erledigt? 

Nachdem das Sprint-Ziel neu definiert und an den Sprint Backlog angepasst wurde, setzt sich das Development Team damit auseinander, wie das Produktinkrement des Sprints erstellt werden soll. Der Product Owner kann bei Unklarheiten helfen, und das Development Team kann mit ihm verhandeln wenn es feststellt, dass es sich doch zu viel Arbeit vorgenommen hat.  

Am Ende des Sprint Plannings sollte das Development Team in der Lage sein zu erklären, wie es selbstorganisiert das Produktinkrement des Sprints erreichen wird.  

Daily Scrum 

Das Daily Scrum hat eine Time Box von 15 Minuten pro Tag. Ausschließlich das Development Team nimmt daran teil, wobei der Scrum Master optional als Moderator dazukommen kann. Der Zweck des Events ist die Synchronisierung der Arbeit und der Planung für die nächsten 24 Stunden. Das Daily Scrum sollte täglich zur gleichen Uhrzeit und am gleichen Ort stattfinden, um Komplexität zu reduzieren. Das Event wird von drei Fragen bestimmt, die jede Person des Development Teams beantwortet: 

• Was habe ich gestern erledigt, um im Development Team das Sprint-Ziel zu erreichen? 
• Was werde ich heute tun, um im Development Team das Sprint-Ziel zu erreichen? 
• Sehe ich irgendwelche Hindernisse, die uns vom Erreichen des Sprint-Ziels abhalten bzw. die mich persönlich von der Erledigung meiner Aufgaben abhalten? 

Auf diese Weise wird der Fortschritt beim Erreichen des Sprint Ziels überprüft. Detailliertere Diskussionen sollten nicht im Daily Scrum geführt werden, da dies die Time Box gefährdet.  

Refinement 

Das Refinement ist die Hauptaufgabe des Product Owners. Es hat keine feste Time Box und findet laufend im Sprint statt. Das Ziel sind genügend Product-Backlog-Einträge, die in den nächsten ein bis zwei Sprints abgearbeitet werden können. Das Refinement umfasst die Erweiterung der Product-Backlog-Einträge um weitere Details, eine Schätzung oder eine neue Priorisierung. Hier findet eine kontinuierliche Verfeinerung statt, bei der sich der Product Owner die Hilfe des Development Teams holen darf. Allerdings sollten die Developer nicht mehr als 10 % ihrer Zeit in das Refinement investieren. Schätzungen sind ausschließlich vom Development Team zu machen.  

Sprint Review 

Die Review dient der Überprüfung des Produktinkrements. Teilnehmer sind das Scrum Team und ggf. Stakeholder, die der Product Owner eingeladen hat. Die Time Box beträgt vier Stunden für einen vierwöchigen Sprint.  

In der Sprint Review bekommt das Development Team den Raum, sein Inkrement zu präsentieren und Fragen dazu zu beantworten. Der Product Owner nimmt die jeweiligen Bestandteile ab, wenn er sie als fertig („done“) einschätzt oder nimmt sie nicht ab, wenn er noch nicht zufrieden ist. Daraufhin aktualisiert er den Sprint Backlog. Hier kann auch über die nächsten Schritte gesprochen werden. 

Sprint Retrospektive 

Bei der Retrospektive erhält das Scrum Team die Gelegenheit, sich selbst zu überprüfen und die eigenen Prozesse zu verbessern. An diesem Event nimmt das gesamte Scrum Team teil. Es hat eine Time Box von drei Stunden bei einem vierwöchigen Sprint. 

Der Scrum Master nimmt hier die Rolle des Moderators ein, er bereitet die Retrospektive vor und führt sie durch. Dabei kann er selbst das Team während des Sprints beobachten und Dinge, die ihm aufgefallen sind, zur Sprache bringen. Aber auch das restliche Scrum Team bringt Input mit. Dieser kann sich zum Beispiel auf die Personen, Beziehungen, Prozesse und Werkzeuge beziehen. Um die Arbeit weiter zu verbessern, werden in einer Retrospektive konkrete Maßnahmen für den nächsten Sprint ausgearbeitet.

Scrum Events im Agenturalltag 

Die Events in Scrum müssen also regelmäßig, mit den richtigen Leuten, zur richtigen Zeit, zu einem berechtigten Anlass sowie im richtigen (zeitlichen) Rahmen stattfinden (Time Boxing). Im Agenturalltag sehen wir allerdings öfter, dass es Zeit braucht, bis ein Team sich auf die Scrum Events eingestellt hat und diese die Arbeit effizienter machen. In einem unserer aktuell laufenden Projekte wurde zum Beispiel das Team komplett neu aufgestellt, sodass es zuerst zusammenfinden musste. Inzwischen haben sich die Events quasi verselbstständigt: Jeder und jede weiß genau, was die Aufgaben einer Rolle sind. Gemeinsam haben wir einen Weg gefunden, innerhalb der Events zu agieren, was uns zum Beispiel dabei hilft, die Time Box einzuhalten. Also nicht entmutigen lassen, wenn nicht sofort im ersten Sprint das gewünschte Arbeitsergebnis erreicht wird! Wir haben die Erfahrung gemacht, dass ein neues Team zwei oder drei Sprints benötigt, um sich einzuspielen.

Mit diesem Tipp verabschieden wir uns bis zum nächsten Beitrag zum Thema Scrum und wünschen viel Erfolg beim Ausprobieren.   

(Foto: unsplash/youxventures)