Organisiert man Arbeitsabläufe nach dem Prinzip von Scrum, gibt es bestimmte Ereignisse, die regelmäßig eintreffen. Da es sich bei Scrum um einen iterativen Prozess handelt, vollzieht sich die Arbeit in wiederholenden Zyklen: Jedes Ereignis findet bei jeder Wiederholung erneut statt. Die Häufigkeit der Scrum-Ereignisse bewirkt, dass außerplanmäßige Meetings selten bis gar nicht stattfinden. Alle Ereignisse haben zudem einen festen Zeitrahmen.
Den Zyklus selbst nennt man Sprint. Dieser beschreibt den Zeitraum einer Entwicklungsphase. Am Ende eines Sprints wird vom Entwicklerteam ein fertiges Produktinkrement ausgeliefert. Das heißt, die Entwicklung muss zu einem Produkt geführt haben, das potenziell ausgeliefert werden kann. Somit hat jeder Sprint eine konkrete Mission, die man am Ende als „fertig“ kennzeichnet. Der Zeitrahmen für einen Sprint wird im Vorfeld festgelegt, sollte aber nicht mehr als 30 Tage betragen. Bei der Festlegung der Zeitspanne sollte man folgende Faktoren berücksichtigen: Ein Sprint darf weder verlängert noch verkürzt werden, und auch die kommenden Sprints des Projekts sollten die gleiche Dauer haben.
Sprints werden bewusst kurz gehalten, damit man bei der Formulierung der Ziele nicht zu kompliziert denkt. Die kurze Dauer sorgt auch dafür, dass mindestens einmal im Monat eine Überprüfung der Entwicklung stattfindet. Nur in wenigen Ausnahmefällen darf ein Product Owner (und auch nur dieser) einen Sprint abbrechen. Möglich ist der Abbruch zum Beispiel, wenn das Ziel nicht mehr erreicht werden muss, weil das Unternehmen inzwischen eine andere Zielsetzung hat. Grundsätzlich sollten Sprints aber nicht abgebrochen werden, weil dies die Produktivität stark mindert.
Ein Sprint beginnt mit dem Sprint Planning: An diesem Ereignis sind alle Rollen des Scrum-Teams beteiligt. Während eines maximal acht Stunden andauernden Meetings besprechen die Beteiligten das anstehende Produktinkrement: Was soll im Inkrement enthalten sein und wie möchte man das Ergebnis erreichen? Ausgangspunkt für die Planung ist der Product Backlog. Das Entwicklerteam und der Product Owner verständigen sich gemeinsam darauf, welche Ziele im kommenden Monat erreicht werden können. Daraufhin bespricht das Entwicklerteam, wie die Aufgaben bewältigen werden soll. Am Ende des Meetings sollten die Entwickler ihren Plan mit dem Product Owner und dem Scrum Master besprechen können.
Innerhalb des Sprints findet jeden Tag ein Daily Scrum statt – immer zum gleichen Zeitpunkt und am gleichen Ort, denn das spart Organisationsaufwand. Bei dem 15-minütigen Meeting bespricht das Entwicklerteam, welche Aufgaben an diesem Tag anstehen und was man am vergangenen Tag erreicht hat. Auch die Entwickler beurteilen den allgemeinen Fortschritt des Projekts: Wie weit ist man bei der Abarbeitung der Backlog-Einträge vorangekommen? Der tägliche Abgleich stellt sicher, dass alle Beteiligten die Ziele im Blick behalten, wodurch letztlich auch die Produktivität gesteigert wird.
Der Scrum Master sorgt zwar dafür, dass ein Daily Scrum stattfindet, den Ablauf des Meetings machen aber die Entwickler untereinander aus. Sie legen fest, welche Themen besprochen werden. Solange es inhaltlich um die Erreichung des Sprint-Ziels geht und die 15 Minuten nicht überschritten werden, mischt sich der Scrum Master nicht ein. Er achtet auch darauf, dass andere Personen, die dem Daily Scrum beiwohnen, die Entwickler nicht bei ihrer Arbeit stören.
Wenn ein Sprint zu Ende ist, folgt ein Sprint-Review: Dabei wird das Produktinkrement überprüft. Gemeinsam mit Personen, die nicht Teil des Scrum-Teams sind, aber dennoch ein wichtiges Interesse an dem Produkt haben, wie zum Beispiel Unternehmenseigentümer oder Kunden (bei Scrum gesammelt als Stakeholder bezeichnet), werden die Ergebnisse ausgewertet. Dabei spricht man auch über den Arbeitsprozess als solchen, geht auf Probleme bei der Entwicklung ein und tauscht sich über Herausforderungen aus. Dies hat auch Einfluss auf die weitere Planung, denn der Product Owner nutzt die Gelegenheit, auf den Fortschritt des Backlogs einzugehen. Die Erkenntnisse des Sprints beeinflussen die Prognose für die kommenden Leistungen.
Einfluss auf den Backloghat auch die jeweilige Marktsituation: Insbesondere bei langfristigen Projekten können sich im Laufe der Zeit Prioritäten verschieben und Budgets ändern. Auch solche Themen werden im Sprint-Review beachtet und verändern die zukünftige Vorgehensweise. Bei einem einmonatigen Sprint sollte man für das Review nicht mehr als vier Stunden einplanen.
Auf das Sprint-Review folgt ein weiter Rückblick: die Sprint-Retrospektive. Innerhalb eines maximal dreistündigen Meetings setzt sich das gesamte Scrum-Team (also inklusive Product Owner und Scrum Master, aber ohne Stakeholder) für eine Feedback-Runde zusammen. Während beim Review vor allem das Produkt und das Voranschreiten des Projekts im Zentrum stehen, geht es bei der Retrospektive überwiegend um die Teamarbeit. Ziel dieses zweiten Rückblicks ist es, die Arbeit untereinander zu verbessern und interne Probleme aus dem Weg zu schaffen. Sobald ein Sprint beendet ist, beginnt der nächste erneut mit dem Sprint Planning.