Beiträge

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

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.

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.

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.

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.

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.

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.

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

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.