Scrum Ceremonies: Ein vollständiger Leitfaden zu allen 5 Events

Illustriertes Entwicklerteam, das sich um ein Scrum Board mit Haftnotizen versammelt und verschiedene Meeting-Formate in einem farbenfrohen agilen Arbeitsbereich durchläuft Scrum definiert genau fünf Events. Nicht vier, nicht sechs. Jedes einzelne existiert aus einem bestimmten Grund, und das Auslassen eines davon hinterlässt eine Lücke in der Feedbackschleife, die Scrum zum Funktionieren bringt. Hier erfahren Sie, wofür jedes Event da ist, wer teilnimmt, wie lange es dauert und welche Fehler Teams schleichend aus der Bahn werfen.

Der Sprint

Der Sprint ist der Rahmen für alles andere. Jedes andere Scrum Event findet innerhalb eines Sprints statt. Es ist eine feste Timebox, in der Regel ein bis vier Wochen, in der das Team ein potenziell auslieferbares Inkrement des Produkts erstellt. Wichtige Details:

Länge: 1-4 Wochen (2 Wochen sind am häufigsten)
Wer ist beteiligt: Das gesamte Scrum Team
Ergebnis: Ein fertiges Inkrement

Sprints werden nicht verlängert. Wenn das Team nicht alles fertigstellen kann, wandern die Aufgaben zurück ins Backlog. Diese Beschränkung ist der Sinn der Sache. Sie erzwingt frühzeitig schwierige Gespräche über Umfang und Priorität, anstatt Deadlines stillschweigend verstreichen zu lassen. Kürzere Sprints (ein oder zwei Wochen) reduzieren das Risiko, weil man schneller Feedback bekommt. Längere Sprints bieten mehr Raum für komplexe Arbeit. Die meisten Teams landen bei zwei Wochen und schauen nie zurück.

Wann Sie Ihren Sprint verkürzen sollten

Wenn Ihr Team regelmäßig unfertige Arbeit in den nächsten Sprint mitnimmt, probieren Sie kürzere Sprints. Es ist einfacher, für eine Woche genau zu planen als für vier, und Sie erkennen Umfangsprobleme früher.

Sprint Planning

Das Sprint Planning eröffnet jeden Sprint. Das Team entscheidet, was gebaut wird und wie es gebaut wird. Wichtige Details:

Timebox: Bis zu 8 Stunden für einen 4-Wochen-Sprint (proportional herunterskaliert, also ~2 Stunden für einen 2-Wochen-Sprint)
Wer ist beteiligt: Product Owner, Scrum Master, Entwicklungsteam
Ergebnis: Das Sprint-Ziel und das Sprint Backlog

Das Meeting hat zwei Teile. Zuerst präsentiert der Product Owner die Backlog-Einträge mit der höchsten Priorität und das Team bespricht, was machbar ist. Dann teilen die Entwickler diese Einträge in Aufgaben auf und klären das Vorgehen. Das Sprint-Ziel ist wichtiger als die einzelnen Einträge. Es gibt dem Team eine Richtung und die Flexibilität, den Umfang zu verhandeln, wenn Überraschungen während des Sprints auftreten.

Wie Planning Poker ins Bild passt

Viele Teams verwenden Planning Poker während oder vor dem Sprint Planning, um Backlog-Einträge zu schätzen. Jedes Teammitglied schätzt unabhängig Story Points, dann diskutiert die Gruppe größere Abweichungen. Das deckt Annahmen und Missverständnisse auf, bevor die Arbeit beginnt. Erfahren Sie mehr darüber, wie Planning Poker funktioniert und welche Story-Point-Skalen Teams verwenden.

Häufiger Fehler

Lassen Sie das Sprint Planning nicht zu einer Backlog-Grooming-Sitzung werden. Einträge sollten bereits verfeinert und geschätzt sein, bevor sie ins Planning kommen. Wenn die Hälfte des Meetings damit verbracht wird, Anforderungen zu klären, muss Ihr Refinement-Prozess verbessert werden.

Daily Scrum

Das Daily Scrum (oder Daily Standup) ist ein 15-minütiger Sync für das Entwicklungsteam. Es ist kein Statusbericht an das Management. Wichtige Details:

Timebox: 15 Minuten, jeden Tag zur gleichen Zeit am gleichen Ort
Wer ist beteiligt: Entwicklungsteam (Scrum Master moderiert bei Bedarf, Product Owner optional)
Ergebnis: Gemeinsames Verständnis von Fortschritt und Blockern

Das klassische Format sind drei Fragen: Was habe ich gestern gemacht? Was mache ich heute? Was blockiert mich? Aber dieses Format kann sich abnutzen. Manche Teams gehen stattdessen das Board durch und konzentrieren sich auf Tickets statt auf Personen. Andere nutzen asynchrone Formate für verteilte Teams. Das Daily Scrum existiert, um Entwicklern bei der Koordination zu helfen. Wenn jemand feststeckt, findet das Team gemeinsam eine Lösung. Wenn zwei Personen an widersprüchlichen Änderungen arbeiten, fangen sie das hier auf, statt in einem Merge-Konflikt.

Die asynchrone Standup-Alternative

Für Remote- und verteilte Teams ersetzen asynchrone Standups das traditionelle Morgen-Meeting. Teammitglieder posten Updates in ihrem eigenen Rhythmus, und das gesamte Team bleibt informiert, ohne mit Zeitzonen-Mathematik zu kämpfen. Wenn Sie auf Asynchron umsteigen, ist das Schreiben von Updates, die auch tatsächlich gelesen werden, eine Fähigkeit, die sich zu entwickeln lohnt. Lesen Sie dazu wie Sie Standup-Updates schreiben, die gelesen werden.

Illustrierter Splitscreen, der auf der einen Seite einen traditionellen Standup-Kreis zeigt und auf der anderen Seite Teammitglieder, die von verschiedenen Standorten aus asynchrone Updates posten, verbunden durch fließende Linien

Sprint Review

Das Sprint Review findet am Ende des Sprints statt. Das Team demonstriert, was es gebaut hat, und sammelt Feedback von Stakeholdern. Wichtige Details:

Timebox: Bis zu 4 Stunden für einen 4-Wochen-Sprint (~1-2 Stunden für einen 2-Wochen-Sprint)
Wer ist beteiligt: Scrum Team + Stakeholder (Nutzer, Management, andere Teams)
Ergebnis: Feedback zum Inkrement, aktualisiertes Product Backlog

Dies ist keine formelle Präsentation. Es ist eine Arbeitssitzung, bei der Stakeholder das tatsächliche Produkt nutzen, Fragen stellen und mitteilen, was ihrer Meinung nach geändert werden sollte. Der Product Owner nutzt dieses Feedback, um das Backlog anzupassen. Teams, die Sprint Reviews auslassen oder halbherzig durchführen, tendieren dazu, sich von dem zu entfernen, was Nutzer tatsächlich brauchen. Man kann nur begrenzt im Vakuum planen, bevor man das Falsche baut.

Sprint Review vs. Sprint Demo

Diese Begriffe werden oft synonym verwendet, aber der Scrum Guide beschreibt eine kollaborative Arbeitssitzung, keine einseitige Demo. Der Unterschied ist wichtig. Eine Demo ist passiv. Ein Review ist interaktiv. Stakeholder sollten das Meeting mit Meinungen verlassen, und das Team sollte mit Informationen gehen, auf deren Basis es handeln kann.

Wer sollte dabei sein?

Laden Sie alle ein, die sich für das Produkt interessieren. Engineering-Leads, Designer, Customer Success, sogar echte Kunden, wenn möglich. Je vielfältiger das Feedback, desto besser wird Ihr nächster Sprint.

Sprint Retrospektive

Die Retrospektive ist der Ort, an dem sich das Team selbst reflektiert. Was lief gut? Was nicht? Was sollte sich ändern? Es ist das einzige Event, das sich ausschließlich darauf konzentriert, wie das Team arbeitet, und nicht darauf, was es baut. Wichtige Details:

Timebox: Bis zu 3 Stunden für einen 4-Wochen-Sprint (~90 Minuten für einen 2-Wochen-Sprint)
Wer ist beteiligt: Scrum Master, Entwicklungsteam (Product Owner optional, aber empfohlen)
Ergebnis: Maßnahmen für den nächsten Sprint

Eine gute Retro bringt ein oder zwei konkrete Maßnahmen hervor. Keine Wunschliste. Keine vagen Verpflichtungen wie "besser kommunizieren." Spezifische, zuweisbare Änderungen, die das Team auch tatsächlich umsetzt. Für einen tieferen Einblick lesen Sie unseren Leitfaden zur Durchführung einer effektiven Retrospektive. Wenn sich Ihre Retros repetitiv anfühlen, probieren Sie ein neues Format mit frischen Retrospektive-Ideen oder beginnen Sie mit Eisbrecherfragen, um die Teilnehmer vor der eigentlichen Diskussion aufzuwärmen.

Illustriertes Team, das im Kreis sitzt, mit Gedankenblasen, die grüne Häkchen und rote Flaggen enthalten, und über Haftnotizen an einem Board abstimmt

Retros sicher gestalten

Retrospektiven funktionieren nur, wenn sich die Teilnehmer sicher fühlen, ehrlich zu sein. Anonymes Feedback und Abstimmungen helfen dabei. Ebenso hilft es, zu Beginn Grundregeln aufzustellen: keine Schuldzuweisungen, keine Unterbrechungen, alle Perspektiven sind willkommen. Wenn Teammitglieder sich zurückhalten, wird die Retro zur Formalität statt zum Werkzeug. Kollabes Retrospektive-Boards unterstützen standardmäßig anonyme Beiträge und Abstimmungen, was ruhigeren Teammitgliedern hilft, ohne Druck beizutragen.

Verfolgen Sie Ihre Maßnahmen

Der größte Retro-Killer ist das Nicht-Nachverfolgen von Maßnahmen. Wählen Sie ein oder zwei Änderungen pro Sprint und weisen Sie jeder eine bestimmte Person zu. Überprüfen Sie die Maßnahmen des letzten Sprints zu Beginn jeder Retro.

Wie die fünf Events zusammenhängen

Diese Events sind keine isolierten Meetings. Sie bilden einen Kreislauf:

Event	Input	Ergebnis
Sprint Planning	Verfeinertes Backlog, vorheriges Feedback	Sprint-Ziel + Sprint Backlog
Daily Scrum	Fortschritt von gestern, Plan für heute	Koordination, Blocker-Lösung
Sprint Review	Fertiges Inkrement	Stakeholder-Feedback, Backlog-Updates
Sprint Retrospektive	Beobachtungen des Teams	Prozessverbesserungen
Sprint	Alles oben Genannte	Auslieferbares Inkrement

Feedback aus dem Sprint Review fließt in die Backlog-Priorisierung ein. Maßnahmen aus der Retrospektive verändern, wie der nächste Sprint abläuft. Daily Scrums bringen Probleme an die Oberfläche, die noch am selben Tag behoben werden. Entfernen Sie ein beliebiges Event und der Kreislauf bricht zusammen.

Häufige Fehler bei allen Ceremonies

😴Nur die Bewegungen durchgehen

Events abhalten, weil Scrum es vorschreibt, ohne echtes Engagement. Wenn niemand aufpasst, ist das Meeting Verschwendung.

⏰Timeboxen ignorieren

Ein 15-minütiges Standup, das 45 Minuten dauert, ist kein Standup. Timeboxen existieren, um Fokus zu erzwingen. Nutzen Sie einen Timer.

🚫Events auslassen, wenn es stressig wird

Der Sprint, in dem Sie "keine Zeit für eine Retro haben," ist der Sprint, der eine am meisten gebraucht hätte.

👥Falsche Teilnehmer

Stakeholder im Daily Scrum, Entwickler fehlen beim Sprint Review. Jedes Event hat aus gutem Grund eine definierte Teilnehmergruppe. Lesen Sie unseren Leitfaden darüber, wer an einer Retrospektive teilnehmen sollte.

Kurzübersicht

Event	Timebox (2-Wochen-Sprint)	Teilnehmer	Häufigkeit
Sprint	2 Wochen	Gesamtes Scrum Team	Fortlaufend
Sprint Planning	~2 Stunden	PO, SM, Entwicklungsteam	Beginn des Sprints
Daily Scrum	15 Minuten	Entwicklungsteam	Jeden Tag
Sprint Review	~1-2 Stunden	Scrum Team + Stakeholder	Ende des Sprints
Sprint Retrospektive	~90 Minuten	SM, Entwicklungsteam, PO (optional)	Ende des Sprints, nach dem Review

Zusammenfassung

Scrum Ceremonies funktionieren als System. Jedes Event speist das nächste, und zusammen bilden sie eine Schleife aus Planen, Bauen, Feedback einholen und Anpassen. Verstehen Sie jedes einzelne für sich, aber achten Sie darauf, wie sie zusammenhängen. Wenn Sie bessere Tools für Ihre Ceremonies wollen, bietet Kollabe Schätzung, Retrospektiven und Standups an einem Ort.

Ja. Der Scrum Guide verwendet "Events" als offiziellen Begriff, aber "Ceremonies" wird in der Praxis häufig verwendet. Beide bezeichnen die gleichen fünf Aktivitäten: den Sprint, Sprint Planning, Daily Scrum, Sprint Review und die Sprint Retrospektive.

Jedes Event hat eine bestimmte Rolle im Inspect-and-Adapt-Zyklus. Lassen Sie Sprint Reviews aus und Sie bauen das Falsche. Lassen Sie Retros aus und Prozessprobleme werden nie behoben. Lassen Sie das Planning aus und niemand ist sich über das Ziel einig. Sie funktionieren als Gesamtpaket.

Das Daily Scrum lässt sich am einfachsten asynchron gestalten, besonders für verteilte Teams. Sprint Planning und Retrospektiven profitieren von Echtzeit-Diskussionen, können aber hybride Ansätze nutzen, bei denen Beiträge asynchron gesammelt und Entscheidungen synchron getroffen werden. Sprint Reviews sind am schwierigsten asynchron durchzuführen, da Live-Feedback der Kernzweck ist.

Größere Organisationen, die Frameworks wie SAFe oder LeSS verwenden, fügen zusätzliche Koordinations-Events zu den fünf Kern-Events hinzu. Aber auf der Ebene des einzelnen Teams bleiben die Ceremonies gleich. Jedes Scrum Team (idealerweise 3-9 Personen) führt seinen eigenen Satz von Events durch, unabhängig von der Unternehmensgröße.

Zuletzt aktualisiert am 09/02/2026