Das Verständnis der vier wesentlichen agilen Meetings ist der schnellste Weg, um die Arbeitsweise eines Scrum-Teams zu verbessern. Jede Zeremonie hat einen bestimmten Zweck, eine andere Zielgruppe und eine andere Definition von Erfolg. Führen Sie sie gut durch, und sie wirken sich positiv aus. Führen Sie sie schlecht durch oder verwechseln Sie sie miteinander, und Sie werden feststellen, dass sich der gleiche Reibungspunkt Sprint für Sprint wiederholt.
Dieser Leitfaden behandelt die Sprint-Planung, das tägliche Standup, das Sprint-Review und die Sprint-Retrospektive: wofür jedes einzelne da ist, wie man es effektiv durchführt und welche häufigen Fehler vermieden werden sollten.
Die vier Arten von agilen Meetings
| Meeting | Wann | Dauer | Wer moderiert |
|---|---|---|---|
| Sprint-Planung | Zu Beginn jedes Sprints | 1–2 Stunden | Scrum Master |
| Tägliches Standup | Jeden Tag | 15 Minuten | Team (selbstmoderiert) |
| Sprint-Review | Am Ende des Sprints | 1–2 Stunden | Product Owner |
| Sprint-Retrospektive | Am Ende des Sprints (nach dem Review) | 1–2 Stunden | Scrum Master |
1. Sprint-Planung
Was es ist
Die Sprint-Planung eröffnet jeden Sprint. Das Team überprüft gemeinsam mit dem Product Owner das Produkt-Backlog, einigt sich auf ein Sprint-Ziel und wählt die Arbeiten aus, die sie in den nächsten ein bis vier Wochen liefern werden.
Das Sprint-Ziel ist der wichtigste Output. Eine Liste von Tickets ist kein Sprint-Ziel. Ein Sprint-Ziel bietet dem Team etwas, worauf sie sich konzentrieren können, wenn sich die Prioritäten mitten im Sprint verschieben.
Wie gut aussieht
- Das Sprint-Ziel wird vereinbart, bevor das Meeting endet; nicht "wir werden es im Laufe der Zeit herausfinden."
- Backlog-Items sind gut verfeinert; das Team verbringt in der Planung nicht die Zeit damit, ein Ticket zu entschlüsseln.
- Jedes ausgewählte Element hat eine gemeinsame Definition von Fertig und eine realistische Schätzung.
- Der Arbeitsaufwand berücksichtigt die tatsächliche Kapazität: Feiertage, Bereitschaftsdienste, Überträge vom letzten Sprint.
Häufige Fehler
Übercommitment. Teams, die ihr Sprint-Ziel konsequent verfehlen, versuchen in der Regel zu viel zu tun, nicht zu langsam zu arbeiten. Verwenden Sie Geschwindigkeitsdaten und eine ehrliche Kapazitätsplanung anstelle von Optimismus.
Vermeidung der Verfeinerung. Wenn die Sprint-Planung regelmäßig lange dauert, liegt das Problem meist an unzureichend verfeinerten Backlog-Items. Zu viele Unbekannte im Raum verlangsamen alles.
Kein Sprint-Ziel. Ohne ein gemeinsames Ziel optimiert das Team für einzelne Tickets statt für kollektive Ergebnisse. Wenn etwas Unerwartetes mitten im Sprint auftaucht, fehlt ein Nordstern für Triage-Entscheidungen.
2. Tägliches Standup
Was es ist
Das tägliche Standup ist ein 15-minütiges tägliches Treffen zur Koordination der Teamarbeit und zum Aufdecken von Blockaden. Es ist kein Statusbericht für den Scrum Master; es ist ein Team-zu-Team-Gespräch.
Die klassischen drei Fragen:
- Was habe ich gestern gemacht?
- Was werde ich heute tun?
- Gibt es irgendetwas, das mich blockiert?
Wie gut aussieht
- Das Meeting beginnt und endet jeden Tag pünktlich.
- Blockaden werden klar benannt, nicht versteckt. Eine unaufgedeckte Blockade am Ende des Tages ist weit teurer als 60 Sekunden kurzzeitiger Unbequemlichkeit beim Standup.
- Das Team spricht miteinander, nicht mit dem Scrum Master.
- Tiefere Diskussionen werden sofort nach dem Meeting offline geführt, nicht in Echtzeit erörtert.
Häufige Fehler
Es in einen Statusbericht verwandeln. Wenn der Scrum Master die Fragen stellt und die Teammitglieder an ihn berichten, ist es zu einer Reporting-Zeremonie geworden, anstatt eines Koordinationsinstruments.
Mehr als 15 Minuten dauert. Wenn Standups regelmäßig zu lange dauern, liegt das Problem meist an Updates, die in ein separates Meeting gehören. Wenden Sie die Regel "Lösen Sie es offline" konsequent an.
Blockaden werden nur optional erwähnt. Teams, die konsequent "keine Blockaden" sagen, obwohl offensichtlich Blockaden existieren, haben ein Problem mit psychologischer Sicherheit, nicht mit dem Standup. Gehen Sie es in der Retrospektive an.
3. Sprint-Review
Was es ist
Das Sprint-Review findet am Ende des Sprints statt. Das Team demonstriert abgeschlossene Arbeiten gegenüber Stakeholdern und dem Product Owner, und das Backlog wird basierend auf dem, was gebaut und welche Rückmeldungen erhalten wurden, angepasst.
Das Sprint-Review ist der Feedback-Loop zwischen dem Team und dem Unternehmen. Ohne es arbeitet das Team im Vakuum.
Wie gut aussieht
- Es werden nur Arbeiten demonstriert, die die Definition von "Fertig" erfüllen. Teilweise abgeschlossene Arbeiten werden nicht gezeigt.
- Stakeholder sind aktiv beteiligt: Fragen stellen und Feedback geben, anstatt nur eine Präsentation anzusehen.
- Der Product Owner passt das Backlog basierend auf dem, was er sieht und hört, an, nicht erst später in der Woche, wenn der Moment verstrichen ist.
- Die Diskussion konzentriert sich auf das Produkt, nicht auf den Prozess des Teams (dafür ist die Retrospektive gedacht).
Häufige Fehler
Demonstrieren von Arbeiten, die nicht fertig sind. Dies untergräbt das Vertrauen in die Definition von "Fertig" und lehrt Stakeholder, ein ungefähres anstelle eines geprüften Outputs zu erwarten.
Einseitige Präsentation. Wenn Stakeholder passive Beobachter sind, funktioniert das Review nicht. Der ganze Punkt ist es, Feedback zu bekommen, das ändert, was das Team als Nächstes baut. Gestalten Sie die Sitzung, um einen Dialog zu schaffen.
Keine Stakeholder anwesend. Ein Sprint-Review nur mit dem Entwicklungsteam ist eine Probe, kein Review.
4. Sprint-Retrospektive
Was es ist
Die Sprint-Retrospektive ist der Raum des Teams, um über ihre Arbeitsweise nachzudenken, nicht über das, was sie gebaut haben. Sie folgt auf das Sprint-Review und konzentriert sich auf Prozess, Zusammenarbeit und kontinuierliche Verbesserung.
Drei Fragen rahmen die meisten Retrospektiven:
- Was lief gut?
- Was könnte verbessert werden?
- Was werden wir im nächsten Sprint anders machen?
Die dritte Frage ist die wichtigste. Eine Retrospektive ohne konkrete Maßnahmen ist nur ein Gespräch.
Wie gut aussieht
- Maßnahmen aus der vorherigen Retrospektive werden zu Beginn überprüft.
- Das Team ist ehrlich, was psychologische Sicherheit erfordert.
- Die Sitzung ergibt zwei oder drei spezifische, verantwortete Maßnahmen, nicht eine Wunschliste von zehn.
- Das Format variiert von Sprint zu Sprint. Wechselnde Retrospektivformate halten das Gespräch frisch.
TeleRetro bietet über 50 Retro-Formate und Vorlagen, die zu verschiedenen Teamstimmungen und Sprinttypen passen. TeleRetros Retro-Bot kann ein Format vorschlagen, wenn Sie nicht wissen, wo Sie anfangen sollen.
Häufige Fehler
Gleiches Format in jedem Sprint. Vertrautheit führt zu Antworten im Autopilot. Versuchen Sie den Wechsel zwischen Lean Coffee, Mad Sad Glad oder Segelboot, um neue Aspekte aufzudecken.
Maßnahmen ohne Verantwortliche. "Wir sollten die CI-Pipeline verbessern" ist keine Aktion. "Priya wird bis nächsten Donnerstag untersuchen, wie die Testsuite parallelisiert werden kann" ist es.
Stakeholder oder Manager im Raum. Retrospektiven sind für das Team. Externe Anwesenheit ändert, was Leute sagen. Begrenzen Sie die Teilnahme auf das Team und den Scrum Master als Standard.
Wie die vier Meetings verbunden sind
Die vier Zeremonien bilden einen Zyklus. Die Sprint-Planung setzt die Richtung. Standups halten die Koordination aufrecht. Das Sprint-Review prüft das Ergebnis anhand der Produktvision. Die Retrospektive verbessert die Arbeitsweise des Teams, damit der nächste Zyklus besser ist als der letzte.
Wenn eine Zeremonie schwach ist, belastet sie die anderen. Teams mit schlechter Sprint-Planung neigen dazu, chaotische Standups zu haben. Teams ohne effektive Retrospektiven wiederholen immer wieder die gleichen Probleme von Sprint zu Sprint. Die vier Meetings als verbundenes System zu behandeln, anstatt als vier separate Verpflichtungen, ist das, was die agile Rhythmus wirklich zum Funktionieren bringt.
Häufig gestellte Fragen
Sind alle vier Meetings in Agile erforderlich?
Speziell im Scrum ja: alle vier Zeremonien sind im Scrum Guide definiert. In Kanban oder anderen Frameworks ist die Struktur flexibler. Viele Kanban-Teams führen ein tägliches Standup und eine regelmäßige Retrospektive durch, überspringen jedoch die Sprint-Planung und das Sprint-Review in ihrer traditionellen Form. Was zählt, ist, dass die zugrunde liegenden Zwecke erfüllt werden: Koordination, Feedback und kontinuierliche Verbesserung.
Was ist der Unterschied zwischen einem Sprint-Review und einer Sprint-Retrospektive?
Das Sprint-Review dreht sich um das Produkt: was gebaut wurde, ob es die Definition von "Fertig" erfüllt und was die Stakeholder denken. Die Retrospektive dreht sich um das Team: wie ihr zusammengearbeitet habt, was euch verlangsamt hat und was zu ändern ist. Unterschiedliche Meetings, unterschiedliche Teilnehmer, unterschiedliche Ergebnisse.
Wer sollte an jedem Meeting teilnehmen?
- Sprint-Planung: Das Entwicklungsteam, der Scrum Master und der Product Owner.
- Tägliches Standup: Das Entwicklungsteam. Der Scrum Master kann anwesend sein, sollte es aber nicht leiten.
- Sprint-Review: Das Entwicklungsteam, Scrum Master, Product Owner und eingeladene Stakeholder.
- Sprint-Retrospektive: Das Entwicklungsteam und der Scrum Master. Der Product Owner kann teilnehmen, wenn das Team ihn einlädt, es ist aber optional und sollte die Wahl des Teams sein, nicht standardmäßig.
Wie lange sollte jedes Meeting dauern?
Der Scrum Guide verbindet die Dauer mit der Sprint-Länge. Für einen zweiwöchigen Sprint: Sprint-Planung bis zu vier Stunden, Sprint-Review bis zu zwei Stunden, Sprint-Retrospektive bis zu 1,5 Stunden. In der Praxis führen erfahrene Teams oft kürzer. Standups dauern immer 15 Minuten, unabhängig von der Sprint-Länge.
Aktualisiert
Erlebe ein besseres Retro
Erstelle ein Retro in Sekunden & überzeuge dich selbst.