Scrum Events

Der Sprint ist ein Container für alle anderen Events. Jedes Event in Scrum ist
eine formelle Gelegenheit, Scrum-Artefakte zu überprüfen und anzupassen. Diese
Events sind speziell darauf ausgelegt, die erforderliche Transparenz zu
ermöglichen. Wenn ein Event nicht wie vorgeschrieben durchgeführt wird,verpasst
man die Gelegenheit, zu überprüfen und anzupassen. Events werden in Scrum
verwendet, um Regelmäßigkeit zu schaffen und die Notwendigkeit von Meetings, die
in Scrum nicht definiert sind, zu minimieren. Optimalerweise werden alle Events
zur selben Zeit und am selben Ort abgehalten, um die Komplexität zu reduzieren.

Der Sprint

Sprints sind der Herzschlag von Scrum, wo Ideen in Wert umgewandelt werden. Es
sind Events mit fester Länge von einem Monat oder weniger, um Konsistenz zu
schaffen. Ein neuer Sprint beginnt unmittelbar nach dem Abschluss des vorherigen
Sprints. Alle Arbeiten, die notwendig sind, um das Produkt-Ziel zu erreichen,
einschließlich Sprint Planning, Daily Scrums, Sprint Review und Sprint
Retrospective, finden innerhalb der Sprints statt. Während des Sprints

■werden keine Änderungen vorgenommen, die das Sprint-Ziel gefährden würden;
■nimmt die Qualität nicht ab;
■wird das Product Backlog nach Bedarf verfeinert; und
■kann der Scope (Inhalt und Umfang) geklärt und mit dem:der Product Owner:in neu
vereinbart werden, sobald mehr Erkenntnisse vorliegen.

Sprints ermöglichen Vorhersagbarkeit, indem sie mindestens jeden Kalendermonat
eine Überprüfungund Anpassung der Fortschritte in Richtung eines Produkt-Ziels
gewährleisten. Wenn der Horizont eines Sprints zu lang ist, kann das Sprint-Ziel
hinfällig werden, die Komplexität kann steigen und das Risikokann zunehmen.
Kürzere Sprints können eingesetzt werden, um mehr Lernzyklen zu generieren und
das Risiko von Kosten und Aufwand auf einen kleineren Zeitrahmen zu begrenzen.
Jeder Sprint kann als einkurzes Projekt betrachtet werden. Es gibt verschiedene
Vorgehensweisen, um den Fortschritt vorherzusagen, wie Burn-Down-Charts, Burn-
Up-Charts oder Cumulative-Flow-Diagramme. Diese haben sich zwar als nützlich
erwiesen, ersetzen jedoch nicht die Bedeutung der Empirie. In komplexen
Umgebungen ist unbekannt, was passieren wird. Nur was bereits geschehen ist,
kann für eine vorausschauende Entscheidungsfindung genutzt werden. Ein Sprint
könnte abgebrochen werden, wenn das Sprint-Ziel obsolet wird. Nur der:die
Product Owner:inhat die Befugnis, den Sprint abzubrechen.

Sprint Planning

Das Sprint Planning initiiert den Sprint, indem es die für den Sprint
auszuführenden Arbeiten darlegt. Dieser resultierende Plan wird durch die
gemeinschaftliche Arbeit des gesamten Scrum Teams erstellt. Der:die Product
Owner:in stellt sicher, dass die Teilnehmenden vorbereitet sind, die wichtigsten
Product-Backlog-Einträge zu besprechen, und wie sie dem Produkt-Ziel zuzuordnen
sind. Das ScrumTeam kann zu Beratungszwecken auch andere Personen zur Teilnahme
am Sprint Planning einladen. Das Sprint Planning behandelt die folgenden
Themen:Thema Eins: Warum ist dieser Sprint wertvoll? Der:die Product Owner:in
schlägt vor, wie das Produkt im aktuellen Sprint seinen Wert und Nutzen steigern
könnte. Das gesamte Scrum Team arbeitet dann zusammen, um ein Sprint-Ziel zu
definieren, das verdeutlicht, warum der Sprint für die Stakeholder:innen
wertvoll ist. Das Sprint-Ziel muss vor dem Ende des Sprint Plannings finalisiert
sein. Thema Zwei: Was kann in diesem Sprint abgeschlossen (Done) werden? Im
Gespräch mit dem:der Product Owner:in wählen die Developer:innen Einträge aus
dem ProductBacklog aus, die in den aktuellen Sprint aufgenommen werden sollen.
Das Scrum Team kann dieseEinträge während dieses Prozesses verfeinern, was
Verständnis und Vertrauen erhöht. Die Auswahl, wie viel innerhalb eines Sprints
abgeschlossen werden kann, kann eine Herausforderungdarstellen. Je mehr die
Developer:innen jedoch über ihre bisherige Leistung, ihre zukünftige
Kapazitätund ihre Definition of Done wissen, desto sicherer werden sie in ihren
Sprint-Vorhersagen sein. Thema Drei: Wie wird die ausgewählte Arbeit
erledigt?Für jeden ausgewählten Product-Backlog-Eintrag planen die
Developer:innen die notwendige Arbeit, um ein Increment zu erstellen, das der
Definition of Done entspricht. Dies geschieht oft durch Zerlegung von Product-
Backlog-Einträgen in kleinere Arbeitseinheiten von einem Tag oder weniger. Wie
dies geschieht,liegt im alleinigen Ermessen der Developer:innen. Niemand sonst
sagt ihnen, wie sie Product-Backlog-Einträge in Increments von Wert umwandeln
sollen. Das Sprint-Ziel, die für den Sprint ausgewählten Product-Backlog-
Einträge und der Plan für derenLieferung werden zusammenfassend als Sprint
Backlog bezeichnet.Das Sprint Planning ist zeitlich beschränkt auf maximal acht
Stunden für einen einmonatigen Sprint. Beikürzeren Sprints ist das Event in der
Regel kürzer.

Daily Scrum

Der Zweck des Daily Scrums besteht darin, den Fortschritt in Richtung des
Sprint-Ziels zu überprüfen unddas Sprint Backlog bei Bedarf anzupassen, um die
bevorstehende geplante Arbeit zu justieren. Das Daily Scrum ist ein 15-minütiges
Event für die Developer:innen des Scrum Teams. Um die Komplexität zu reduzieren,
wird es an jedem Arbeitstag des Sprints zur gleichen Zeit und am gleichenOrt
abgehalten. Falls der:die Product Owner:in oder der:die Scrum Master:in aktiv an
Einträgen des Sprint Backlogs arbeitet, nimmt er:sie als Developer:in teil. Die
Developer:innen können Struktur und Techniken beliebig wählen, solange ihr Daily
Scrum sich aufden Fortschritt in Richtung des Sprint-Ziels fokussiert und einen
umsetzbaren Plan für den nächstenArbeitstag erstellt. Das schafft Fokus und
fördert Selbstmanagement.Daily Scrums verbessern die Kommunikation,
identifizieren Hindernisse, fördern die schnelle Entscheidungsfindung und
eliminieren konsequent die Notwendigkeit für andere Meetings. Das Daily Scrum
ist nicht die einzige Gelegenheit, bei der die Developer:innen ihren Plan
anpassen dürfen. Sie treffen sich oftmals während des Tages für detailliertere
Diskussionen zur Anpassung oder Neuplanung der restlichen Arbeit des Sprints.

Sprint Review

Zweck des Sprint Reviews ist es, das Ergebnis des Sprints zu überprüfen und
künftige Anpassungenfestzulegen. Das Scrum Team stellt die Ergebnisse seiner
Arbeit den wichtigsten Stakeholder:innen vor,und die Fortschritte in Richtung
des Produkt-Ziels werden diskutiert.Während des Events überprüfen das Scrum Team
und die Stakeholder:innen, was im Sprint erreichtwurde und was sich in ihrem
Umfeld verändert hat. Auf der Grundlage dieser Informationen arbeitendie
Teilnehmenden gemeinsam daran, was als Nächstes zu tun ist. Auch kann das
Product Backlogangepasst werden, um neue Möglichkeiten wahrzunehmen. Das Sprint
Review ist ein Arbeitstermin, unddas Scrum Team sollte vermeiden, es auf eine
Präsentation zu beschränken.Das Sprint Review ist das vorletzte Event des
Sprints und ist für einen einmonatigen Sprint auf maximalvier Stunden zeitlich
beschränkt. Bei kürzeren Sprints ist das Event in der Regel kürzer.

Sprint Retrospective

Der Zweck der Sprint Retrospective ist es, Wege zur Steigerung von Qualität und
Effektivität zu planen.Das Scrum Team überprüft, wie der letzte Sprint in Bezug
auf Individuen, Interaktionen, Prozesse,Werkzeuge und seine Definition of Done
verlief. Die überprüften Elemente variieren oft je nachArbeitsdomäne. Annahmen,
die das Team in die Irre geführt haben, werden identifiziert und ihreUrsprünge
erforscht. Das Scrum Team bespricht, was während des Sprints gut gelaufen ist,
auf welcheProbleme es gestoßen ist und wie diese Probleme gelöst wurden (oder
auch nicht).Das Scrum Team identifiziert die hilfreichsten Änderungen, um seine
Effektivität zu verbessern. Diewirkungsvollsten Verbesserungen werden so schnell
wie möglich in Angriff genommen. Sie können sogarin das Sprint Backlog für den
nächsten Sprint aufgenommen werden.Die Sprint Retrospective schließt den Sprint
ab. Sie ist für einen einmonatigen Sprint auf maximal dreiStunden beschränkt.
Bei kürzeren Sprints ist das Event in der Regel kürzer.