Scrum, ein Management Framework für agile Software Entwicklung, definiert Rollen, Rituale und Artefakte und den Zyklus Plan->Do->Reflect->Improve
Für jeden Zyklus gibt es ein Ritual: Sprint Planning, der Sprint, Sprint Review und Sprint Retrospective.
Die Sprint Retrospective soll reflektieren, wie ein Sprint gelaufen ist. Die Sprint Retrospective wird meistens im Anschluss an den Sprint Review durchgeführt.
Das gesamte Team wird eingeladen, der Product Owner ist anwesend, der Scrum Master moderiert. Andere Stakeholder sind willkommen, allerdings nur als Zuschauer.
Während der Sprint Retrospective sollte das Team:
- Das Product-Burndown Chart auswerten. Wie ist es gelaufen? Hat das Team in diesem Sprint geliefert, was geplant und angenommen wurde? Man kann die aufgewendeten Stunden des Sprints im Vergleich zu den User Stories setzen und mit vorherigen Sprints vergleichen und graphisch darstellen. Das Team sollte Schwankungen im Graph untersuchen und erkennen, ob man besser oder schlechter wird. Das Warum sollte herausgefunden werden.
- Die Team Velocity auswerten. Zur Ermittlung der Velocity (Geschwindigkeit) summiert man alle Story Points des Sprints, die mit DONE abgearbeitet wurden und setzt sie in Relation zu dem Total aller geschätzten Story Points im Product Backlog. Das kann man graphisch darstellen und erhält über mehrere Sprints einen Trend. Dieser Trend ist sehr wichtig für das Sprint Planning. Die Velocity ist ein Anhaltspunkt für die Arbeit, die ein Team für einen Sprint annehmen kann. Das Team sollte auch hier Schwankungen in der Kurve hinterfragen, Überstunden berücksichtigen und den totalen Aufwand errechnen: Wieviel Stunden wurden effektiv aufgewendet? Was wurde geliefert?
- Diskutieren, was gut gelaufen ist. Jedes, wirklich jedes Teammitglied hat Erfahrungen gemacht, die jetzt ausgewertet werden sollten. Positive Punkte werden jetzt hervorgehoben. Es wird sichergestellt, dass diese im nächsten Sprint wiederholt werden können.
- Diskutieren, was nicht so gut gelaufen ist. Punkte, die vom Team in diesem Sprint als nicht so gut erachtet werden, sollten auf den Tisch gebracht werden. Es ist wichtig, das Warum herauszufinden, um die Ursache im kommenden Sprint abzustellen.
- Entscheiden, was im nächsten Sprint verändert wird. Das Team sucht sich ein paar wenige Dinge heraus, die im kommenden Sprint anders gemacht werden sollen. Das sollten aktive und realistische Punkte sein, die auch wirklich in einem Sprint verändert werden können.
Das ist ein
kontinuierlicher Lernprozess.
Die Sprint Retrospective ist kein auferlegtes Muss vom Management. Hier ist das Team auf sich gestellt - selbstorganisierend und selbstregulierend.
