Scrum - Die 5 Ereignisse

Sutherland und Schwaber bezeichnen die Scrum-Timeboxen als Ereignisse (Events).

• Sprint
• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospektive
• (Product Backlog Refinement)

Es gibt eine Ereignisse, die Scrum definiert, die nicht als Event bezeichnet wird, und das ist die Product Backlog Refinement. Das Product Backlog Refinement findet nur statt, wenn Scrum-Teams es für notwendig erachten.

In Scrum spricht man von Ereignissen statt von Meetings, um klarzustellen, dass es sich um Arbeit handelt. Alle Ereignisse von Scrum haben feste Zeitfenster (timeboxed Events), die nicht überschritten werden sollen.

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

#Sprint

In Scrum ist ein Sprint eine feste Periode, also eine zeitlich begrenztes Container. Die Sprint-Timebox darf nicht länger als 4 Wochen sein, wobei kürzere Timeboxen gegenüber längeren Timeboxen (2-4 Wochen) bevorzugt werden. Scrum-Teams entscheiden selbst, wie lang ihre Sprints sein werden.

Sprint ist ein Container-Ereignis in Scrum, in das vier andere Scrum-Ereignisse eingeordnet werden. Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospective.

#Generelle Regeln

• Die Anwesenheit des Developer ist bei jedem Scrum-Event obligatorisch.
• In jedem Sprint erstellen die Developer ein fertiges Produkt Increment. In Scrum gibt es kein Konzept der teilweisen Erstellung des Produktinkrements. Man streben immer die Erstellung von freigebbarem Code an, auch "Shippable Code" bezeichnet. Dieser freizugebende Code sollte die Definition of done erfüllen.
• Im Laufe der Zeit baut ein Scrum-Team sein Produkt inkrementell auf, jedes Inkrement wird so gebaut, dass es in der Produktionsumgebung vollständig nutzbar ist.
• Product Owner werden das neue Produktinkrement erst dann für die Produktionsumgebung freigeben, wenn sie feststellen, dass das Inkrement sowohl brauchbar als auch nützlich ist. Andere Product Owner hingegen unterstützen die kontinuierliche Bereitstellung in ihrer Produktionsumgebung.
• Sobald ein Sprint endet, beginnt sofort ein neuer Sprint. Jeder Sprint hat ein Sprint Goal, das der Arbeit des Entwicklungsteams Kohärenz verleiht.

#Während des Sprints:

• Es werden keine Änderungen vorgenommen, die das Sprint Goal gefährden würden.
• Die Qualität wird nicht verringert
• Das Product Backlog wird nach Bedarf verfeinert
• Der Umfang kann geklärt und mit dem Product Owner neu verhandelt werden, wenn neue Erkenntnisse vorliegen.

#Sprint Planning

Die Sprint-Planungssitzung findet zu Beginn des Sprint statt und beantwortet diese zwei Fragen:

• Was kann im kommenden Sprint entwickelt werden?
• Wie wird die Arbeit im kommenden Sprint erledigt?

Die Auswahl des Sprint-Ziels ergibt sich aus der Auseinandersetzung mit dem Thema, was kann in diesem Sprint getan werden?

"the selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together, rather than on separate initiatives." Scrum Guide

Die Developer bewertet ihre Kapazität, bevor sie mit der Auswahl der zu erledigenden Arbeit aus dem Product Backlog beginnen können.

#Zeit und Teilnehmer

Für einen 4-wöchigen Sprint sollte das Sprint Planning Event nicht länger als 8 Stunden dauern. Bei einem 2-wöchigen Sprint sollte die Sprintplanungsveranstaltung nicht länger als 4 Stunden dauern. Bei einem 1 Woche langen Sprint nicht länger als 2 Stunden.

Beim Springt Planning müssen alle Mitglieder des Scrum-Teams teilnehmen. Die einzigen optionalen Teilnehmer sind diejenigen, die über technisches oder fachliches Wissen verfügen und von den Developern eingeladen wurden, um bei der Sprintplanung zu helfen.

#Was kann im Sprint entwickelt werden?

Der Product Owner stellt den Developer die im Product Backlog festgehaltenen Features in der zuvor priorisierten Reihenfolge vor. Das Product Backlog sollte im Sprint zuvor im Product Backlog Refinement so weit vorbereitet worden sein, dass es geordnet, gefüllt und die Einträge für den nächsten Sprint geschätzt sind.

Das gesamte Scrum Team plant für die im Sprint zu erledigende Arbeit. Der Product Owner einigt sich mit den Developer auf die Kriterien, die am Ende des Sprints darüber entscheiden, ob die neue Funktionalität fertig ist oder nicht. Ziel ist die Fertigstellung eines auslieferbaren Produkts: ein Product Increment, das getestet und integriert ist, um für den Benutzer freigegeben werden zu können.

Anschließend prognostiziert das Developer Team die Anzahl der Product-Backlog-Einträge, die es im nächsten Sprint liefern kann. Die Entscheidung, wie viele Einträge im nächsten Sprint umgesetzt werden, liegt alleine beim Team, während die Entscheidung über die Reihenfolge alleine beim Product Owner liegt. Deshalb müssen beide konstruktiv zusammenarbeiten. Aus den ausgewählten Product-Backlog-Einträgen formuliert das Scrum Team gemeinsam ein Sprint Goal (Sprintziel).

#Wie wird im Sprint entwickelt?

Im zweiten Teil der Sprint Planung plant die Developer im Detail, welche Aufgaben (Tasks) zum Erreichen des Sprintziels und zur Lieferung der prognostizierten Product-Backlog-Einträge notwendig sind. Diese Planung macht das Entwicklungsteam, wobei der Product Owner für Fragen in Reichweite sein sollte. Oftmals bilden sich zur Beantwortung der Wie-Frage Kleingruppen, in denen verschiedene Aspekte wie z. B. Architektur, Datenelemente und Schnittstellen geklärt werden.

Ergebnis ist das Sprint Backlog: der detaillierte Plan für den nächsten Sprint. Er enthält die für den Sprint geplanten Product-Backlog-Einträge und die Aufgaben zu deren Umsetzung.

• Die Developer erstellen Sprint Backlog
• Technische Diskussion
• detaillilerte Arbeitspaketet zur Realisierung der zugesicherten Features
• Die Developer schätzt Aufwände für Arbeitspakete
• Arbeitspakete sollten nicht länger als 1 Tag dauern

#Daily Scrum

Daily Scrum ist eine auf maximal 15 Minuten beschränkte Besprechung, die an jedem Arbeitstag am selben Ort zur selben Zeit stattfindet. Die Developer sind die einzigen Pflichtteilnehmer für das tägliche Scrum.

Daily ist ein wichtiges Inspektions- und Anpassungs-Meeting, bei dem das Team inspiziert, was es geschafft hat und was noch zu tun ist, und ermöglicht neu zu planen, um das Sprint-Ziel zu erreichen.

Der Scrum Guide schreibt nicht vor, dass diese drei Fragen während des täglichen Dailies verwenden werden müssen. Die drei Fragen sind als Vorschlag gedacht, nicht als Vorschrift.

1. Was habe ich seit gestern erreicht?
2. Bin ich auf irgendwelche unerwarteten Probleme oder Hindernisse gestoßen?
3. Was plane ich für heute?

Der Product Owner und Scrum Master sind optionaler Teilnehmer. Der Product Owner kann helfen, das Ziel zu schärfen bzw. bei der Entscheidung helfen. Der Scrum Master hat die Verantwortung sicherzustellen, dass die Developer einen Daily Scrum halten und die 15-Minuten-Zeitbox nicht überschreiten. Andere Personen können am Daily Scrum teilnehmen, aber nur als als Beobachter, es sei denn, sie können helfen, ein Hindernis im Team zu beseitigen.

Das Daily Scrum ist die Gelegenheit für den Scrum Master, den Developer zu helfen, indem diese über Impediment (Hindernisse) erfährt, die das Team selbst nicht beseitigen kann.

Es ist möglich, das Daily Scrum für 30 Minuten einzuplanen, so dass, nachdem das Daily Scrum in den ersten 15 Minuten beendet ist, wenn es eine Diskussion gibt, die zwischen einigen Mitgliedern des Entwicklungsteams abseits des Daily Scrums stattfinden muss, sie diese Diskussion sofort, nach dem Daily, führen können.

#Sprint Review

Am Ende des Sprints steht die Review an. Hier überprüft das Scrum Team das Inkrement, um das Product Backlog bei Bedarf anzupassen. Das Entwicklungsteam präsentiert seine Ergebnisse und es wird überprüft, ob das zu Beginn gesteckte Ziel erreicht wurde. Das Scrum Team und die Stakeholder besprechen die Ergebnisse und was als Nächstes zu tun ist.

Es ist Aufgabe des Product Owners, die entwickelten Funktionalitäten zu begutachten. Anhand der im Sprint Planning festgelegten Bedingungen entscheidet er, ob sie abgenommen werden können oder nicht. Ein Team hat auch dann sein Ziel verfehlt, wenn es eine „fast fertige“, aber noch nicht getestete Funktionalität liefert. In diesem Fall kehren die nicht fertiggestellten User Stories in das Product Backlog zurück und werden vom Product Owner neu priorisiert. Die Abnahme ist aber nicht primärer Gegenstand vom Sprint Review, bei dem es vorrangig um das Feedback der Stakeholder geht. Die Abnahme der Funktionalitäten des Produktinkrements wird daher häufig im Rahmen des Sprints umgesetzt.

Das Sprint-Review dauert maximal 1 Stunde je Sprint-Woche, maximal 4 Stunden für einen 1-monatigen Sprint. Dabei geht es darum:

• Der Developer demonstriert die vollständige Funktionen, die im Sprint fertiggestellt wurden
• Feedback von Mitarbeiter und Stakeholder einzuholen

Alle Scrum-Team-Mitglieder sind obligatorische Teilnehmer an den Veranstaltungen Sprint Planning, Sprint Review und Sprint Retrospective. Andere externe Stakeholder können an einem Sprint Review teilnehmen, wenn der Product Owner sie einlädt.

Der Product Owner sollte nicht einfach jemanden aus Höflichkeit einladen. Es sollte einen Grund geben, dieser Grund ist, dass jede Person das Produktinkrement inspizieren und dem Product Owner bei der Anpassung des Product Backlogs helfen kann.

Die Rolle des Product Owners im Sprint Review ist es, allen zu erklären, was im Sprint getan und was nicht getan wurde. Die Developer erklären, was während des Sprints gut gelaufen ist, auf welche Probleme sie gestoßen sind, wie sie mit diesen Problemen umgegangen sind und was sie daraus gelernt haben.

#Sprint Retrospektive

Die Sprint Retrospektive steht am Ende eines Sprints. Hierbei überprüft das Scrum Team seine bisherige Arbeitsweise, um sie in Zukunft effizienter und effektiver zu machen. Alle Scrum-Team-Mitglieder sind Pflichtteilnehmer. Wenn das Scrum Team einverstanden ist, dann dürfen anderes Personen teilnimmt, wie z.B. ein Agile Coach oder vielleicht nur jemand, der wissen möchte, was in einer Sprint Retrospektive passiert.

Das Team soll seine Arbeitsweise offen und ehrlich überprüfen können. Dazu müssen Kritik und unangenehme Wahrheiten offen geäußert werden können. Die Retrospektive soll daher in einem geschützten Raum ablaufen. Stakeholder dürfen nur auf Einladung dazukommen.

Die Sprint-Retrospektive dauert 45 min je Sprint-Woche, also max. drei Stunden für einen 4-Wochen-Sprint.

Mögliche Fragen könnten sein,

• "Was lief gut für uns?"
• "Was ist nicht gut gelaufen?"
• "Wie können wir unsere Arbeitsweise verbessern?".

#Product Backlog Refinement

Product Backlog Refinement, das auch als Backlog Grooming bezeichnet wird. Der Zweck des Meetings ist es, Details und Schätzungen hinzuzufügen und die Product Backlog Items zu priorisieren. Der Scrum Guide sagt einfach, dass dies eine laufende Ereignisse für das Team ist. Wie das Team das macht, ist ihnen überlassen. Hierzu gehören:

• Ordnen der Einträge
• Löschen von Einträgen, die nicht mehr wichtig sind
• Hinzufügen von neuen Einträgen
• Detaillieren von Einträgen
• Zusammenfassen von Einträgen
• Schätzen von Einträgen
• Planung von Releases

Für die Gestaltung des Produkts und des Product Backlogs können Stakeholder wertvolle Informationen liefern, indem sie dem Scrum Team erklären, wie sie sich eine Funktionalität im alltäglichen Gebrauch wünschen. Daher gibt es meistens auch Product-Backlog-Refinement-Treffen zusammen mit ausgewählten Stakeholdern.

Das Product Backlog Refinement sollte nicht mehr als 10 % der Zeit des Entwicklungsteams in Anspruch nehmen.

Scrum bezieht sich auf Backlog Refinement als eine Aktivität, nicht als ein Ereignis. Der Unterschied ist, dass Scrum-Ereignisse nach den Regeln von Scrum regelmäßig stattfinden müssen. Backlog Refinement muss überhaupt nicht stattfinden, wenn es nicht benötigt wird. Backlog Refinement kann in der Häufigkeit stattfinden, die das Scrum Team für notwendig hält. Es ist die flexibelste Scrum Aktivität, die es gibt. Wenn Backlog Refinement stattfindet, sollte das Scrum Team nicht mehr als 10% der Kapazität des Entwicklungsteams in einem Sprint aufwenden.