SCRUM Events: Welche SCRUM Events gibt es?

Im SCRUM Prozess finden für gewöhnlich fünf Events statt: das Sprint Planning, das Daily SCRUM, die Sprint Review, die Retrospektive und der Sprint selbst. Sie wiederholen sich in jedem Sprint und sind notwendig für das beste Outcome eines mit SCRUM gemanagten Projektes.

 

Events gemäß SCRUM finden für gewöhnlich (und unter normalen Umständen) in persönlicher Form statt. Sie erfolgen regelmäßig, um kontinuierlich überprüfen und anpassen zu können. Alle Events haben ein festes Zeitfenster. Dieses Zeitfenster wird auch Timebox genannt. Das bedeutet, dass für jedes Event ein Zeitrahmen vorgegeben ist, der auf jeden Fall eingehalten werden muss. Die Einhaltung dieses Zeitfensters ist Aufgabe des SCRUM Masters. Gibt es dennoch mehr Themen als es die Zeit des Events hergibt, so werden diese Themen auf das nächste Event verschoben.

Die Charakteristiken von SCRUM Events

Events nach SCRUM haben eine ganz spezielle Charakteristik, die sie erst „typisch SCRUM“ werden lassen.

Regelmäßigkeit

Um den iterativen Charakter von SCRUM sicherzustellen, finden die Events bei SCRUM regelmäßig statt. Es gibt eine feste Frequenz, in denen die Events stattfinden. Diese Frequenz wird nicht verändert oder angepasst. Sie wird während des gesamten Projekts konsequent verfolgt. Auch der Ort der jeweiligen Events sollte immer der gleiche sein. Diese Regelmäßigkeit und die klare Definition von Frequenz und Ort stellen den Fluss und die Effizienz des SCRUM-Prozesses sicher.

Timebox

Für jedes Event nach SCRUM ist ein fester Zeitrahmen vorgegeben. Das bedeutet, bereits in der Planung des Projektes, Zeitfenster festgelegt wurden. Diese müssen unbedingt eingehalten werden. Wenn das Zeitfenster abgelaufen ist, ist das Event beendet und es gibt keine Verlängerung. Themen, die noch offen sind, werden erst im nächsten Event besprochen und bis dahin verschoben.

Die fünf SCRUM Events

Nach SCRUM gibt es genau fünf Events, die im Rahmen eines nach SCRUM gemanagten Projektes stattfinden. Die Anzahl und Art dieser Events sind klar vorgegeben!

Dennoch haben in den letzten Jahren mehrere Autoren und Praktiker in ihren Veröffentlichungen weitere Events für sinnvoll erkannt. Diese sind jedoch nicht offiziell Teil von SCRUM und werden deshalb nicht weiter erwähnt. Die beiden SCRUM-Gründer Ken Schwaber und Jeff Sutherland betonen im SCRUM Guide, dass jede Abwandlung und Ergänzung des von ihnen definierten „Kerns“ von SCRUM den Erfolg und die Effizienz der Methode mindern.

Die fünf offiziellen SCRUM Events sind:

• Der Sprint

• Das Sprint Planning

• Das Daily SCRUM

• Die Sprint Review

• Die Retrospektive

Wenn du zum SCRUM-Profi werden möchtest, lade dir doch unser kostenloses SCRUM Playbook herunter!

1. Der Sprint

Im Sprint sollen die Ziele, beziehungsweise das jeweilige Ziel, das sich das Development Team für die Iteration vorgenommen hat, erreicht werden. Konkret sind die im Rahmen des Sprints umzusetzenden Produkteigenschaften in Sprint Backlog festgehalten. Im Grunde ist der Sprint selbst kein eigenständiges Event, sondern die Klammer um mehrere Events, die innerhalb des Sprints stattfinden. Insofern gibt es keine konkrete Form, wie der Sprint selbst stattfindet.

Die Events, die innerhalb des Sprints festgelegt sind, sind: Sprint Planning, Daily SCRUM, die Entwicklungsarbeit, die Sprint Review und die Retrospektive.

Teilnehmende innerhalb des Sprints sind der Product Owner, der SCRUM Master, das Entwicklungsteam und die SCRUM Stakeholder. Also alle, am Projekt-beteiligten Personen.

Der Sprint selbst wird nicht moderiert, da er wie schon erwähnt eine Klammer, beziehungsweise einen Container um mehrere Events darstellt. Insofern gibt es auch keine Agenda des Sprints selbst. Während des Sprints werden keine Änderungen vorgenommen, die das Sprint-
Ziel gefährden. Eine Änderung wäre nur möglich, wenn das Sprintziel während des Sprints obsolet geworden ist.

Der Anspruch an die Qualität der Arbeit darf nicht geändert werden. Der Scope des Sprints kann zwischen dem Product Owner und dem Entwicklungsteam verhandelt werden, wenn er dem Lernen dient.

Abarbeitung des Backlogs

Die Agenda des Sprints ist quasi die Abarbeitung des Sprint Backlogs. Innerhalb des Sprints haben die beteiligten Rollen die Aufgaben, Kompetenzen und Verantwortungen, die ihnen auch grundsätzlich gemäß ihrer Rollendefinition zugrunde liegen. Das Ergebnis des Sprints ist die vollständige Abarbeitung der für den Sprint vorgesehen Produkteigenschaften gemäß dem Product Backlog.

Die Dauer des Sprints ist unterschiedlich. Ein Sprint kann von wenigen Tage bis hin zu einem Monat andauern. Die maximale Dauer des Sprints beträgt also vier Wochen, beziehungsweise einen Monat. Wichtig ist, dass die Sprints immer die gleiche Dauer haben. Auf diese Weise ist erwiesenermaßen die Leistungsfähigkeit des Sprint Teams am höchsten. Grundsätzlich kann man sagen, dass Sprints immer so kurz wie nur möglich sein sollten. Wenn ein Sprint zu Ende ist, beginnt schon der nächste. Es gibt demnach keine Pause zwischen den einzelnen Iterationen. Auf den vergangenen Sprint folgt sofort der nächste.

Wie viele Sprints innerhalb eines SCRUM-Projektes stattfinden, ist ebenso unterschiedlich und Projekt-abhängig. Letztendlich finden Sprints so lange statt bis das Produkt, oder die Dienstleistung fertig entwickelt ist und besteht.

Die Struktur innerhalb eines Sprints ist immer die gleiche. Ein Sprint beginnt immer mit dem Sprint Planning als erstem Event.

2. Das Sprint Planning

Das Ziel des Sprint Plannings ist, den kommenden Sprint zu planen und Ziele zu setzen. Der Sprint erfolgt (in der Regel) in Form eines Präsenz-Events, das immer als allererstes Event eines Sprints stattfindet. Das Sprint Planning findet einmal pro Sprint zu Beginn dieses statt.

Am Sprint Planning nimmt das gesamte SCRUM-Team teil, also der Product Owner, der SCRUM Master und das Entwicklungsteam. Das Planning dauert bei einem Sprint von vier Wochen maximal acht Stunden. Dauert der Sprint weniger als vier Wochen, passt sich die Dauer des Sprint Plannings auch entsprechend proportional an und ist kürzer. So hätte es bei einem Sprint mit einer Länge von 2 Wochen nur eine Dauer von 4 Stunden.

Der SCRUM Master ist dafür verantwortlich, dass das Sprint Planning stattfindet und dass alle Mitglieder des SCRUM-Teams verstehen, was das Ziel dieses Events und die Anforderungen an sie darin sind. Er ist zudem dafür verantwortlich, das Planning innerhalb des angesetzten Zeitfensters abzuhalten und die Dauer nicht zu überziehen.

3. Das Daily SCRUM

Nachdem das Sprint Planning abgeschlossen ist, beginnt das Entwicklungsteam seine Arbeit. Konkret bedeutet das, dass es die Aufgaben, die im Sprint Planning definiert wurden, im Team selbstorganisiert bearbeitet. Wichtig ist hierbei, dass das Entwicklungsteam die Aufgaben nacheinander abarbeitet und im Idealfall gemeinsam und gleichzeitig am gleichen Backlog Item arbeitet. Während dieser Entwicklungsarbeit trifft sich das SCRUM-Team (wenn möglich physisch) einmal täglich zum Daily SCRUM.

Dieses findet immer zur selben Zeit am selben Ort statt. Dadurch werden organisatorischer Aufwand der Eventplanung und Komplexität reduziert. Die Dauer des Daily SCRUM ist auf maximal 15 Minuten beschränkt. Sinn des Daily SCRUM ist, die Möglichkeit zur Abstimmung und Synchronisierung des Entwicklungsteams.

Bei jedem Daily SCRUM plant das Team die Entwicklungsarbeit für die nächsten 24 Stunden. Hierbei berichtet das Team immer zuerst über die Arbeit der letzten 24 Stunden und gibt einen Ausblick auf die kommenden 24 Stunden. Das Entwicklungsteam bespricht hierbei den Fortschritt des Vortages in Hinblick auf das Sprint-Ziel.  Zudem analysiert es, wie fortgeschritten die Abarbeitung der Items im Product Backlog und Sprint Backlog ist. Hauptziel des Daily SCRUM ist es, die Wahrscheinlichkeit zu maximieren, dass das Entwicklungsteam das Sprint-Ziel auch erreicht.

Die Agenda des Events wird vom Entwicklungsteam selbst festgelegt. Es gibt keine konkreten Vorgaben gemäß SCRUM, wie das Daily SCRUM strukturiert werden soll, so lange alles darauf abzielt, dass das Sprint-Ziel erreicht wird.

Für einen strukturierten Ablauf des Daily SCRUMS können festgesetzte Fragen verwendet werden:

• Was habe ich gestern für das Entwicklungsteam getan, um das Sprint-Ziel zu erreichen?

• Was werde ich heute für das Entwicklungsteam tun, um das Sprint-Ziel zu erreichen?

• Gibt es irgendwelche Hindernisse, die mich und/oder das Entwicklungsteam daran hindern, das Sprint-Ziel zu erreichen?

Andere Entwicklungsteams hingegen nutzen das Daily SCRUM für ausführliche Diskussionen. Die genaue Agenda des Daily SCRUM ist dem SCRUM-Team letztlich freigestellt, so lange es darum geht, das Sprint-Ziel zu erreichen und die maximale Dauer von 15 Minuten eingehalten wird.

4. Sprint Review

Die Sprint Review findet immer am Ende der Entwicklungsarbeit statt. Sie dient dazu, die wichtigsten Ergebnisse aus dem Sprint zu präsentieren, zu überprüfen und gegebenenfalls anzupassen. So wird der neueste Stand des Produktinkrements transparent gemacht und das Product Backlog entsprechend aktualisiert.

Die Sprint Review findet normalerweise in Form eines physischen Events statt. Der Product Owner lädt zu dem Event ein und das gesamte SCRUM-Team ist beim Sprint Review anwesend. Zudem sind auch die Stakeholder mit eingeladen. So erhalten sie einen Überblick zu dem neuesten Stand der Entwicklungsarbeit und können dem Entwicklungsteam gleichzeitig Feedback geben.

Die Präsentation der Ergebnisse des Sprints dient im Wesentlichen dazu, Feedback zu ermöglichen und die Zusammenarbeit zu fördern. Die Sprint Review dauert maximal vier Stunden bei einem Sprint, der vier Wochen dauert. Wenn die Dauer des Sprints kürzer ist, dann sollte auch die Sprint Review entsprechend angepasst werden: Bei einem Sprint mit der Länge von beispielsweise zwei Wochen dauert die Review nur zwei Stunden.

Der SCRUM Master ist dafür verantwortlich, dass das Event stattfindet und dass alle den Grund des Events kennen. Zudem unterstützt der SCRUM Master dabei, dass jeder, der am Event teilnimmt, dazu beiträgt, das Event in dem festgelegten Zeitrahmen zu behalten.

Die Sprint Review hat typischerweise die folgende Agenda:

• Das Entwicklungsteam stellt die Arbeit vor, die erledigt, also „Done“ ist und beantwortet Fragen über das Produktinkrement.

• Der Product Owner erläutert, welche Items des Product Backlog erledigt, also „Done“ sind und welche nicht.

• Der Product Owner diskutiert das Product Backlog in seinem aktuellen Stand. Er gibt einen Ausblick auf künftige Lieferdaten und Ziele basierend auf dem aktuellen Fortschritt (sofern dies notwendig ist).

• Die gesamte Gruppe (SCRUM-Team und Stakeholder) arbeitet zusammen daran, was als nächstes zu tun ist, damit die Review einen wertvollen Input für das nächste Sprint Planning liefert.

• Eine Überprüfung, wie sich der Markt oder der potenzielle Einsatzbereich des Produkts geändert haben könnte und Optionen für mögliche Änderungen.

• Eine Überprüfung des Zeitplans, des Budgets, der potenziellen Ressourcen und des Marktes für das nächste anstehende Release bezüglich der Funktionen und capabilities des Produkts.

Das Ergebnis der Sprint Review ist ein überarbeitetes Product Backlog. Das Product Backlog lässt sich auch grundlegend anpassen, wenn sich neue Möglichkeiten ergeben.

5. Retrospektive

Das Ziel der Sprint-Retrospektive ist, Feedback einzuholen, um den Entwicklungsprozess organisatorisch und strukturell zu verbessern. Es geht also nicht um Feedback zur erzielten Arbeit wie beim Sprint Review, sondern um die Arbeitsweise. Wie war sie und wie kann sie verbessert werden?  Im Kern geht es darum, Verbesserungspotenzial in Bezug auf Menschen, Interaktionen, Prozesse und Werkzeuge zu identifizieren.

Die Retrospektive findet immer nach der Sprint Review und vor den kommenden Sprint Planning statt. Das Event erfolgt in Form eines Präsenz-Events, an dem das gesamte SCRUM Team teilnimmt. Allerdings nicht die Stakeholder! Dies liegt daran, dass die Sprint Retrospektive sich auf eine Verbesserung der Entwicklungsarbeit hinzielt, also die Art und Weise, wie das Entwicklungsteam gemeinsam mit den anderen Mitgliedern des SCRUM-Teams zusammengearbeitet hat. Der Fokus der Stakeholder liegt nur auf dem Ergebnis dieses Prozesses, also dem Produkt. Die Dauer des Events ist auf maximal drei Stunden begrenzt bei einem Sprint mit einer Dauer von vier Wochen. Bei einem kürzeren Sprint dauert die Sprint Retrospektive entsprechend kürzer. Also beispielsweise bei einem 2-wöchigen Springt nur 1 1/2 Stunden.

Der SCRUM Master ist für die Organisation des Events zuständig. Zudem muss er dafür sorgen, dass alle Teilnehmenden den Grund des Events kennen. Er nimmt an dem Event teil, da er für die Einhaltung der SCRUM-Regeln verantwortlich ist. Die Sprint-Retrospektive ist eines der wesentlichsten Events, in denen der SCRUM Master die Einhaltung der SCRUM-Regeln überprüfen und eventuell coachend aktiv werden kann. Er hat auch dafür Sorge zu tragen, dass das Event produktiv und positiv verläuft. Zudem sollte er alle Teilnehmenden dazu anhalten, dass das Event im geplanten Zeitrahmen bleibt.

Die folgenden Ziele des Events bestimmen seine Agenda:

• Überprüfung, wie der letzte Sprint gelaufen ist, mit Fokus auf die Menschen, Beziehungen, Prozesse und Tools.

• Identifikation und Strukturierung der Themen, die gut gelaufen sind, und potenzieller Verbesserungsfelder.

• Erstellung eines Plans, wie die Verbesserungsfelder umgesetzt werden können, so dass das SCRUM-Team seine Arbeit am besten erledigen kann.

Im Rahmen der SCRUM-Retrospektive nutzt der SCRUM Master verschiedene Methoden, um Feedback einzuholen. Die einfachste Art und Weise ist es, eine Metaplanwand in drei Felder zu teilen: Liked, Learned, Lacked. Jedes Mitglied des SCRUM-Teams schreibt auf eine Metaplankarte, was ihm zu diesen drei Punkten einfällt, und pinnt seine Punkte an die Wand. Der SCRUM Master stellt die Ergebnisse vor und erarbeitet mit dem Team das mögliche Verbesserungspotenzial und einen Plan, wie es umgesetzt werden kann.

Mit einem zweitägigen (Online-)Training bei den Agile Heroes, bestehst du mühelos deine Prüfung zum SCRUM Master, oder Product Owner! 

Die SCRUM Events sollten nicht angepasst werden

Nach den SCRUM Gründern Ken Schwaber und Jeff Sutherland sollten die von ihnen vorgegeben Richtlinien eines SCRUM Projektes genauso eingehalten werden. Dazu gehören die Charakteristika der Events. Nur so sei der Erfolg, den die SCRUM Methode verspricht, möglich.

Mehr zu den SCRUM Events und Agilität auf YouTube

Mit kurzen, spannenden Erklärvideos sind die Agile Heroes auch auf YouTube auf Mission, die Welt um ein großes Stück agiler zu machen! Schaut vorbei und lernt mehr zu den SCRUM Events, Rollen, anderen agilen Methoden und mehr! Wir freuen uns auf euren Besuch!