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.
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
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.
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.
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.
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.
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.