Die Scrum Events

Im Scrum Guide sind insgesamt fünf sogenannte Events definiert: der Sprint, das Sprint Planning, das Daily Scrum, das Sprint Review und die Sprint Retrospektive. Diese Events sind notwendig dafür, das beste Outcome in einem agilen Projekt zu erreichen. Sie erfolgen regelmäßig, um kontinuierlich überprüfen und anpassen zu können. Die Scrum Events darauf ausgelegt:

  • Transparenz der Arbeitsschritte und der Zwischenergebnisse
  • Fördern der Kommunikation zwischen den Beteiligten
  • Ermöglichen von Feedbackschleifen
  • Erkennung und Korrektur von Abweichungen

Der Ablauf von Scrum ist darauf ausgerichtet, Einfachheit und Übersichtlichkeit zu schaffen. Es gibt klare Regelungen zum Vorgehen, zu Inhalten und zum Umfang von den Events. Die Planung soll so schlank und einfach wie möglich gehalten werden, damit die Teams sich nur auf den eigentlichen Zweck und die Implementierung von Inkrementen konzentrieren können.

Charakteristiken der Scrum Events

Regelmäßigkeit

Scrum Events sorgen dafür, dass der iterative Charakter von Scrum sichergestellt wird. Diese finden bei Scrum regelmäßig statt, um die Notwendigkeit von Meetings, die in Scrum nicht definiert sind, zu minimieren. Darüber hinaus bieten die Events die formale Gelegenheit, um die Scrum Artefakte zu überprüfen und anzupassen. Es gibt klare Definition in Bezug auf Frequenz und Ort des jeweiligen Events – diese sollen optimalerweise zur selben Zeit und am selben Ort abgehalten werden, um die Komplexität zu reduzieren.

Timeboxing

Jedes der Scrum Events definiert ein festes Zeitfenster, welches auch Timeboxing genannt wird. Diese müssen unbedingt eingehalten werden. Der zentrale Grund dafür ist die Konzentration auf das Wesentliche. Die Überwachung und Einhaltung der Zeitfenster ist die Aufgabe von dem Scrum Master. Wenn das festgelegte Zeitfenster abgelaufen ist, dann wird das Event beendet und es gibt auch keine Verlängerung. Im Fall, dass noch Themen offen sind, werden diese erst im nächsten Event besprochen. Die Dauer der jeweiligen Zeitfenster der Events innerhalb des Sprints hängt unmittelbar von der Länge des Sprints ab. Nur die Dauer vom Daily Scrum bleibt immer konstant bei 15 Minuten.

Event / Sprint-Dauer 4 Wochen 3 Wochen 2 Wochen 1 Woche
Sprint Planning 8 Std. 6 Std. 4 Std. 2 Std.
Daily Scrum 15 Min. 15 Min. 15 Min. 15 Min.
Sprint Review 4 Std. 3 Std. 2 Std. 1 Std.
Sprint Retrospektive 3 Std. 2 Std. 15 Min. 1 1/2 Std. 3/4 Std.

1. Event: Sprint

Die Grundidee von Scrum ist die Entwicklung von Produkten in kurzen Zyklen bzw. Inkrementen. Diese Zyklen nennt man Sprint. Der Sprint ist das Herzstück von Scrum. Das Ziel jedes Sprints ist es, ein potentiell auslieferbares Inkrement zu liefern. Ein Sprint ist quasi die Abarbeitung des Sprint Backlogs. Die einzelnen Inkremente, die Sprint für Sprint ausgeliefert werden, bilden später Stück für Stück das Endprodukt.

Im Grunde ist der Sprint an sich kein eigenständiges Event, sondern eine Art Klammer um mehrere weitere Scrum-Events, die innerhalb eines Sprints stattfinden, wie Sprint Planning, Daily Scrum, Entwicklungsarbeit, Sprint Review und die Sprint Retrospektive. Aus diesem Grund gibt es keine konkrete Form, wie der Sprint selbst stattfindet. Innerhalb eines Sprints gibt es folgende Teilnehmer: Product Owner, Scrum Master, Entwicklungsteam und die Stakeholder, kurz gesagt alle Projekt-Beteiligten.

Jeder Sprint muss ein Sprint-Ziel haben. Der Schwerpunkt des Sprints bzw. Sprint-Ziel kann zwischen dem Product Owner und dem Entwicklungsteam verhandelt werden. Wenn ein Sprint zu Ende ist, dann beginnt schon der nächste, somit gibt es keine Pause zwischen den einzelnen Sprints bzw. Iterationen. Die Dauer der Sprints ist unterschiedlich. Ein Sprint kann wenige Tage bis hin zu einem Monat dauern. Die Anzahl der Iterationen im Scrum-Projekt hängt von dem Projekt selbst ab – es kommt auf die Komplexität und weitere Optimierungen des Endproduktes an.

Bei einem Sprint ist es wichtig, dass die Dauer des Sprints immer konstant bleibt.  Innerhalb einer Organisation mit mehreren Scrum-Teams, die parallel an einem Produkt arbeiten, sollte darauf geachtet werden, dass die Sprints synchron zueinander verlaufen, so dass es nicht zu unnötigen Wartezeiten zwischen den Teams kommt.

Auch wenn die Arbeitsweise nach Scrum offen für Neues und Änderungen ist, gilt es innerhalb des laufenden Sprints Änderungen an den Backlog-Items zu vermeiden. Werden beispielsweise einzelne Backlog-Items nicht innerhalb des Sprints realisiert, so wird der Sprint nicht verlängert, sondern die betroffenen Items für einen der nachfolgenden Sprints eingeplant. Dabei ist es nicht nötig, die Qualitäts- und Akzeptanzkriterien anzupassen oder gar neu zu definieren. Nur wenn die Verlegung der Backlog-Items auf einen anderen Sprint das Sprint-Ziel obsolet macht, kann der Product Owner einen Sprint auch abbrechen.

2. Event: Sprint Planning

Zu Beginn jedes einzelnen Sprints findet erst das Sprint Planning statt. Bei diesem Treffen ist das Hauptziel die Planung der Anforderungen und Arbeitspakete, die im aktuell geplanten Sprint umgesetzt werden sollen. Die Mitglieder des Scrum-Teams müssen alle an dem Event teilnehmen, das vom Product Owner organisiert und vom Scrum Master moderiert wird. Die Aufgabe des Scrum Masters beim Planning ist, dafür zu sorgen, dass das Event stattfindet und alle Mitglieder des Scrum-Teams verstehen, was das Ziel des Events und die Anforderungen an sie darin sind. Auch sorgt der Scrum Master dafür, dass das Timeboxing eingehalten und auf gar keinen Fall überschritten wird.

Für die optimale Durchführung des Meetings sollte ein priorisierter und bereits geschätzter Product Backlog vorliegen. Die am höchsten priorisierten Features aus dem Backlog müssen klein genug sein, damit diese in einem Sprint umgesetzt werden können. Die einzelnen Backlog-Items sollten im Sprint Planning dem Entwicklungsteam auch bereits bekannt und von dem Team geschätzt sein. Die Schätzung von Items, sowie die Erläuterung des Umfangs findet im Backlog Refinement statt, welches fortlaufend stattfinden muss.

Das Sprint Planning teilt sich in zwei Phasen auf:

Sprint Planning 1

In der ersten Phase werden die Fragen nach dem “Was” und dem “Warum” besprochen, kurzum warum der kommende Sprint wertvoll ist und was genau realisiert werden soll. Der Product Owner präsentiert dabei die am höchsten priorisierten Items aus dem Product Backlog. Nun entscheidet das Team, ob und in welchem Umfang die Anforderungen umgesetzt werden können. Zu beachten ist während dieser Phase, dass hier zwei unterschiedliche Interessenlagen aufeinander treffen. Der Product Owner möchte so viele Anforderungen wie möglich umsetzen lassen und das Entwicklungsteam ist eher daran interessiert, ausreichend Zeit für die Umsetzung zu haben. Nach der beidseitigen Einigung folgt dann das Formulieren von einem gemeinsamen Sprint-Ziel und jeder aus dem Team verpflichtet sich, die gemeinsam vereinbarten Anforderungen im kommenden Sprint umzusetzen.

Sprint Planning 2

In der zweiten Phase wird das “Wie” von den Entwicklern geklärt, genauer gesagt wie das Team die Anforderungen realisieren möchte und definieren dabei die einzelnen Arbeitspakete und Tasks. Die Planung des Sprints erfolgt durch das Entwicklungsteam und die Ergebnisse der Planung werden im Sprint Backlog festgehalten. Die Verantwortung für das Sprint Backlog liegt komplett bei dem Entwicklungsteam, ähnlich wie das Product Backlog  beim Product Owner. Auch die finale Entscheidung über die Anforderungen im Rahmen der Vorgaben (Anforderungen, Akzeptanzkriterien und Definition of Done). Am Ende dieser Phase soll der Plan für die Umsetzung des Sprint-Ziels aussehen wird.

3. Event: Daily Scrum

Nach dem Sprint Planning beginnt das Entwicklungsteam seine Arbeit. Aufgaben, die im Sprint Planning definiert wurden, werden nun im Team selbstorganisiert bearbeitet. Wichtig ist, dass die Aufgaben nacheinander abgearbeitet werden. Bei dem Event Daily Scrum handelt es sich um ein tägliches Standup Meeting, zu dem sich das Team trifft, um sich zu synchronisieren. Dabei wird der Fortschritt, die anstehenden Tasks und mögliche Probleme thematisiert. Im Idealfall findet dieses Meeting immer zur selben Zeit am selben Ort statt.

Für die Entwickler ist dieses Event verpflichtend, zusätzlich kann der Scrum Master und der Product Owner teilnehmen. Das Daily Scrum ist auf maximal 15 Minuten beschränkt. Durch diesen Austausch innerhalb des Teams werden Redundanzen vermieden. Folgende Fragen können als Hilfe für das Daily Scrum mit dem Hinblick auf die Erreichung des Sprint-Ziels verwendet werden:

  • Was habe ich seit gestern getan, um dem Team zu helfen, dass Sprint-Ziel zu erreichen?
  • Was habe ich gestern für das Entwicklungsteam getan, um das Sprint-Ziel zu erreichen?
  • Was mache ich bis morgen, um das Team beim Erreichen des Sprint-Ziels zu unterstützen?
  • Was werde ich heute für das Entwicklungsteam tun, um das Sprint-Ziel zu erreichen?
  • Was hindert mich oder das Team daran, das Sprint-Ziel zu erreichen?
  • Gibt es irgendwelche Hindernisse, die mich und/oder das Entwicklungsteam daran hindern, das Sprint-Ziel zu erreichen?

Im Fall, dass sich während des Dailys Diskussionsbedarf entsteht, so sollen diese Themen zwischen den direkt Beteiligten nach dem Daily Scrum separat besprochen werden. Dadurch wird sichergestellt, dass nicht das ganze Team durch Diskussionen entsprechend Zeit verliert. Sollten im Laufe des Daily Scrums Hindernisse oder Probleme mitgeteilt werden, so ist es primär die Aufgabe des Scrum Masters, dafür zu sorgen, dass diese entsprechend gelöst werden.

4. Event: Sprint Review

Am Ende eines Sprints findet das Event Sprint Review statt. Dieser dient als eine Art Inspektion der erledigten Arbeit in Bezug auf das vereinbarte Sprint-Ziel. Beim Sprint Review wird sichtbar, welche der geplanten Anforderungen im Sprint tatsächlich umgesetzt wurden. Es werden ausschließlich Inkremente gezeigt, die vollständig fertiggestellt wurden. Dazu gehören auch alle in der „Definition of Done“ definierten Punkte.

Zum Sprint Review lädt der Product Owner ein und gesamte Scrum Team mit allen beteiligten Mitarbeitern nimmt daran teil. Der Scrum Master ist dafür verantwortlich, dass dieses Event tatsächlich stattfindet und allen der Grund bekannt ist. Weitere Teilnehmer können beispielsweise auch Stakeholder, Endanwender, Manager und andere Bereichsvertreter sein – all die Personen, die Interesse an den Sprint-Ergebnissen haben. Durch die Teilnahme des gesamten Scrum Teams und der Stakeholder kann somit ein direktes Feedback, Kritik, Verbesserungen usw. eingesammelt und bei Bedarf vom Product Owner in den Backlog aufgenommen werden. Dieses Event ist keine «Marketing-Show».

Sprint Review kann folgende Agenda haben:

  • Das Entwicklungsteam stellt alle Inkremente vor, die „Done“ sind und steht für die eventuelle Fragen zur Verfügung.
  • Der Product Owner stellt den aktuellen Status aller Backlog-Items vor, nicht nur die Items, die „Done“ sind, sondern noch offene. Hier gilt die 100%-Regel – ein Item kann nur dann auf „Done“ gesetzt werden, wenn alle definierten Akzeptanzkriterien zu 100% erfüllt sind, sonst werden sie zurück in den Product Backlog gestellt.
  • Der Product Owner stellt den aktuellen Stand des Product Backlogs vor und gibt einen Ausblick für die Zukunft.
  • Alle Teilnehmer (Scrum Team und Stakeholder) arbeiten und diskutieren daran, was als nächstes zu tun ist, damit aus diesem Event heraus ein Input für das nächste Sprint Planning geliefert werden kann.
  • Alle Teilnehmer (Scrum Team und Stakeholder) sollen nochmal den Zeitplan, das Budget, die potentiellen und verfügbaren Ressourcen und die aktuelle Marktsituation überprüfen und ggf. berücksichtigen.

5. Event: Sprint Retrospektive

Bei der Retrospektive, oder auch Retro genannt, handelt es sich um ein regelmäßiges Meeting. Dabei trifft sich das Scrum Team und betrachtet den zurückliegenden Sprint, um so die zukünftige Zusammenarbeit im Team zu optimieren. Die Retro findet immer nach dem Sprint Review und vor dem kommenden Sprint Planning statt. Teil nimmt das gesamte Scrum-Team teil, ohne die Stakeholder, da es sich bei diesem Event um ein rein internes Event handelt.

Es werden Prozesse, Fähigkeiten, Werkzeuge, Interaktionen, Herausforderungen, Beziehungen und Erfahrungen reflektiert und ggf. identifiziert. Das Feedback aus dem Team soll somit die Chancen für das Team selbst als auch für jeden einzelnen bieten, die Zusammenarbeit zu optimieren. Ziele der Retrospektive sind:

  • Verbesserung der Zusammenarbeit im Team
  • Verbesserung von Abläufen und Inhalten
  • Festlegung / Überprüfung von Maßnahmen
  • Festlegung von „Dos“ und „Dont’s“
  • Raum für offenes Feedback – kein Raum für Schuldzuweisungen!

Nach dem Ende der Sprint-Retrospektive fängt dann der nächste Sprint an. Es ist wichtig, dass die in der Retro getroffenen Vereinbarungen gleich umgesetzt werden.

Organisiert wird das Event von dem Scrum Master. Auch zu seinen Aufgaben gehört, dafür zu sorgen, dass der Grund des Events allen Teilnehmern bekannt ist. Die Retro ist ein wesentliches Event bei Scrum, in dem der Scrum Master die Einhaltung der Scrum-Regeln überprüfen und ggf. aktiv nachsteuern kann.

Zusammenfassung

Die oben beschriebenen Events können alternativ wie folgt bezeichnet werden:

  • Ereignisse,
  • Meetings,
  • Rituale,
  • Aktivitäten oder
  • Zeremonien.

Begriffe wie „Scrum Meeting“ oder auch „Scrum Event“ werden häufig in unterschiedlichen Rahmen verwendet, da es sich um verschiedene Formate und unterschiedliche Teilnehmer handeln kann.

Alle  Scrum Events dienen dazu, den Scrum Teams kontinuierliche Verbesserungen hinsichtlich des Scrum Prinzips “Inspect & Adapt” zu ermöglichen:

Event Inspection / Überprüfung Adaption / Anpassung
Sprint Planning
  • Produkt Backlog
  • Zusagen bzw. Commitments aus der Retrospektive
  • “Definition of Done”
  • Sprint Ziel
  • Prognose
  • Sprint Backlog
Daily Scrum
  • Fortschritt in Richtung Sprint Ziel
  • Sprint Backlog
  • Daily-Plan
Sprint Review
  • Produkt Inkrement
  • Produkt Backlog
  • Marktwirtschaftliche Bedingungen
  • Produkt Backlog
Sprint Retrospective
  • Team-Arbeit
  • Technologie und Entwicklung
  • “Definition of Done”
  • Umgesetzte Verbesserungen

Können wir Ihnen helfen?

Können wir Ihnen helfen?

Palina Vorobeva

Beitrag teilen:

Mehr Informationen, einen Austausch oder konkrete Unterstützung im Projekt?

Anfrage senden

Nach oben scrollen