Die meisten Tools am Markt bieten wenig oder keine Unterstützung für die wichtigen Scrum Events Sprint Review und Retrospektive. An einfachen Beispielen möchten wir Ihnen in diesem Artikel zeigen, wie Azure DevOps mit kleinen Erweiterungen großen Mehrwert für Ihre Organisation bieten kann.
Mit jedem Sprint wird ein potenziell auslieferbares Produktinkrement geliefert. Das bedeutet, dass das Team am Ende jedes Sprints ein entwickeltes, getestetes und nutzbares Stück Software produziert hat.
Am Ende eines jeden Sprints wird ein Sprint Review abgehalten. Während dieses Meetings zeigt das Scrum-Team, was es während des Sprints erreicht hat. Typischerweise erfolgt dies in Form einer Demo der neuen Funktionen. Es handelt sich hierbei um ein informelles Treffen, nicht um ein Statusmeeting. Die Präsentation des Inkrements soll Rückmeldungen hervorrufen und die Zusammenarbeit fördern. Ein Sprint Review ist ein natürliches Ergebnis des Sprints. Zu den Teilnehmern am Sprint Review gehören in der Regel der Product Owner, das Scrum-Team, der Scrum Master, das Management, Kunden und Entwickler aus anderen Projekten.
Während des Sprint Reviews wird das Projekt anhand des Sprint-Ziels bewertet, das während des Sprint-Planungstreffens festgelegt wurde. Im Idealfall hat das Team jedes Sprint-Backlog-Element, das in den Sprint gebracht wurde, abgeschlossen. Es ist aber wichtiger, dass das Gesamtziel des Sprints erreicht wurde.
Azure DevOps bietet vielfältige Möglichkeiten dieses Meeting zu unterstützen:
Es bietet sich an, zunächst das zu Sprintbeginn festgelegte Sprint-Ziel erneut zu betrachten, um anschließend die Erreichung dessen innerhalb des Review Meetings bewerten zu können. Eine gute Möglichkeit, um dies direkt in Azure DevOps zu hinterlegen, bietet das kostenlose Add-On Sprint Goal.
Als nächstes kann das Burndown Chart betrachtet werden, um einen Eindruck davon zu bekommen, ob die für den Sprint geplante Arbeit erledigt werden konnte oder ob noch Restarbeiten ausstehen. Diese offenen Themen in Form von Stories können dann bspw. zurück ins Product Backlog verschoben und ggf. für den nächsten Sprint eingeplant werden.
Nach dem allgemeinen Überblick über die Sprintperformance demonstriert das Team die Sprintergebnisse. Hier können verschiedene Modi sinnvoll sein – entweder geht man im Team 1:1 die Sprint Backlog Items (User Stories) durch und zeigt deren Implementierung oder es wird sich auf die Kernfunktionalität im Allgemeinen fokussiert, die möglicherweise mehrere Stories verbindet in Form von Features (rote durchgehende Box, Details per User Story gestrichelte Box).
In jedem Fall ist es wichtig, pro Story zu dokumentieren, ob die Definition of Done erfüllt und die Story formal vom Product Owner abgenommen ist. Idealerweise hat der Product Owner die umgesetzten Funktionen schon vor dem offiziellen Review Termin gesehen. Der Status abgenommener und getesteter User Stories wird somit während des Meetings auf Closed gesetzt, ggf. neu aufkommende Anforderungen werden im Product Backlog aufgenommen.
Sollten für den Sprint geplante User Stories nicht abgeschlossen worden sein oder die Erwartungen umgesetzter Stories wurden nicht erfüllt, wandern diese zurück ins Product Backlog, wo sie nochmal überarbeitet und für einen nächsten Sprint eingeplant werden können.
Retrospektiven haben die kontinuierliche Verbesserung der Teamzusammenarbeit zum Ziel. Typischerweise findet auch dieses Meeting am letzten Sprinttag statt, nach dem Sprint Review. Jedes Teammitglied hat innerhalb der Retrospektive die Möglichkeit Feedback zu geben. Die Diskussion im Team soll zur Verbesserung der Effizienz, Produktivität, Qualität und Zufriedenheit des Teams führen. Die Ergebnisse dieses Meetings sind somit essenziell für das agile Prinzip eines selbstorganisierten Teams.
Wir empfehlen vor allem, Retros vor Ort durchzuführen. Ist dies nicht oder zumindest nicht immer möglich, bietet Azure DevOps das hilfreiche Add-On Retrospectives. Die von uns empfohlene Agenda einer Retrospektive entspricht den Themenblöcken Set the stage, Gather Data, Generate Insights, Decide what to do und Close the retrospective, wie es u.a. auch vom PMI skizziert wird (vgl. hierzu: https://retromat.org/en/?id=3-93-55-100-16).
Einleitung durch den Scrum Master / Product Owner.
Feedback zu folgenden Fragen sammeln und dokumentieren:
Gruppieren des gesammelten Feedbacks.
Vote: Festlegung einer Gewichtung des gesammelten (gruppierten) Feedbacks.
Definieren von Handlungsmaßnahmen zur Verbesserung der gefundenen Issues durch direktes Erstellen von Handlungsmaßnahmen (bspw. in Form einer User Story für den nächsten Sprint) aus den gruppierten Feedback-Items.
Die somit direkt in der Retrospektive identifizierten und als Items angelegte Maßnahmen können bspw. per Tagging im Reporting-Dashboard nachverfolgt werden.
Nicht immer lassen sich interaktive Workshops unter idealtypischen Bedingungen vor Ort durchführen. Ist es einmal nicht möglich alle Teilnehmer an einem Ort zu versammeln, unterstützt Azure DevOps die erfolgreiche Durchführung von Sprint Reviews und Retrospektiven. Für den Scrum Master bieten insbesondere kleine, kostenlose Erweiterungen einen echten Mehrwert. Sie erlauben es, Reviews zu strukturieren, zielführend durchzuführen und zu dokumentieren.
Auch Retrospektiven lassen sich digital unterstützen. Das gezeigte Add-On hilft dem Team bei Reflexion und Dokumentation und bildet so die Basis für die stetige Verbesserung.
Im nächsten Artikel unserer DevOps Blogartikel-Serie zeigen wir, wie Projekte mit mehreren Entwicklungsteams gemeinsam an einem Produkt erfolgreich zusammenarbeiten können.
