Agile Sprint-Reviews

Drei Schritte zur Verbesserung der Sprint-Reviews in deinem agilen Team

Dan Radigan Dan Radigan

Sprint-Reviews sind nicht das Gleiche wie Retrospektiven. Bei einem Sprint-Review geht es darum, die harte Arbeit des gesamten Teams darzustellen: von Designern, Entwicklern und dem Product Owner. Bei Atlassian sind die Sprint-Reviews eine eher ungezwungene Angelegenheit. Die Teammitglieder versammeln sich um einen Tisch, um informelle Demonstrationen zu teilen und die Aufgaben zu beschreiben, die sie in dieser Iteration erledigt haben. Alle haben die Gelegenheit, Fragen zu stellen, neue Features auszuprobieren und Feedback zu geben. Erfolge zu teilen ist ein wichtiger Bestandteil in einem agilen Team.

Let’s first review why the team’s definition of ‘done’ is so important to this agile ceremony.

Schritt 1: die Definition erledigter Arbeit

Für routinierte Jira-Benutzer gibt es nichts zufriedenstellenderes als eine Aufgabe von der Phase "Code-Review" zu "Erledigt" zu verschieben. Der Soundeffekt der agilen Karte steht für fertiggestellte Aufgaben, die wir als Team in Angriff genommen hatten. Fix und fertig!

Aktualisieren einer agilen Karte in Jira

Das Übertreten der Ziellinie und die Fertigstellung von Aufgaben erfordert eine gute Planung, eine klare Definition von "Erledigt" und eine konzentrierte Bearbeitung. Der Großteil hiervon geschieht während der Sprintplanung, aber für einen erfolgreichen Sprint-Review und Sprint muss das Team noch ein wenig mehr tun, als nur planen. Es muss sich ganz klar einig sein, wie die Arbeit abzuliefern ist und wann diese wirklich fertig ist.

Eine Teamkultur für effektive Ergebnisse

Effiziente Teams wenden klare Prozesse auf jedes einzelne Aufgabenelement an und verfügen über eine genau definierte Entwicklungskultur. Bewerte deinen Prozess anhand der folgenden Fragen und überprüfe, ob er für dein Team optimal funktioniert:

  • Wurden die Storys vom Product Owner, Designer und dem Entwicklungsteam vor der Implementierung eindeutig abgesteckt?
  • Verstehen und befolgen alle die entwicklerischen Werte und die Kultur des Teams?

  • Sind klare Definitionen und Anforderungen rund um Code-Review, automatisiertes Testen und Continuous Integration vorhanden, die eine nachhaltige, agile Entwicklung fördern?

  • Kommen nach Abschluss einer Story noch viele Bugs zum Vorschein? Mit anderen Worten: Bedeutet "erledigt" wirklich "erledigt"?

Die Teamkultur rund um Qualität und erfolgreiches Abschließen der Arbeit sollte jeder User Story, jedem Entwicklungselement und Bug vorangestellt werden. Diese Kultur spiegelt wider, wie das Team an Software herangeht und sie ausliefert.

Die Definition von "erledigt" für jedes Aufgabenelement

Eine klare Definition, wann ein Aufgabenelement erledigt ist, hilft dem Team dabei, sich auf das Endziel jedes Aufgabenelements zu konzentrieren. Wenn der Product Owner dem Backlog des Teams Aufgaben hinzufügt, ist die Definition der Abnahmekriterien ein wichtiger Teil dieses Prozesses. Wann ist eine User Story abgeschlossen? Bei Atlassian verfolgt das Jira-Team die Abnahmekriterien und Testhinweise in Jira direkt mit dem Rest der User Story. Auf diese Weise hat das gesamte Team einen klaren Überblick über den erfolgreichen Abschluss der einzelnen Issues. Was sind Abnahmekriterien und Testhinweise?

  • Abnahmekriterien: Metriken, anhand denen der Product Owner überprüft, ob die Story zufriedenstellend implementiert wurde
  • Testhinweise: kurze gezielte Anweisungen vom Qualitätsunterstützungsteam, die dem Entwickler helfen, besseren Feature-Code und bessere automatisierte Tests zu schreiben.

Wenn die Issues während der Implementierung gut definiert sind, ermöglicht dies allen Beteiligten eine erfolgreiche Arbeit. In Jira ist es ganz einfach, Inline-Felder hinzuzufügen. Als Administrator musst du nur auf die "Admin"-Schaltfläche im Issue klicken.

Schritt 2: Feiern von Teamerfolgen

Einer unserer zentralen Werte bei Atlassian ist das "Spiel im Team". Sprint-Reviews sind ein guter Zeitpunkt, um das Team und die Leistungen der einzelnen Teammitglieder während einer Iteration zu feiern. Normalerweise halten wir sie Freitagnachmittags ab, wenn alle sich schon langsam auf das Wochenende einstellen. Sprint-Reviews sind nicht das Gleiche wie Retrospektiven, halte den Sprint-Review also nach einer Iteration, aber vor deiner Retrospektive ab. Externe Teilnehmer sind immer willkommen, aber üblicherweise sind Product Owner, das gesamte Entwicklerteam und der Scrum Master anwesend. Wir empfehlen als Best Practice eine halbe bis ganze Stunde für jede Iteration im Meeting anzusetzen.

Wir mögen Sprint-Reviews, weil sie dafür sorgen, dass die Stimmung im Team nicht abfällt und der Zusammenhalt gestärkt wird. Die Teamentwicklung ist der zentrale Aspekt von Sprint-Reviews. Im Review stehen sich keine Gegner gegenüber, es ist keine Prüfung – es ist eine gemeinschaftliche Veranstaltung des Teams, in der die Mitglieder ihre Arbeit vorstellen, Fragen stellen und Feedback erhalten.

Wenn der Sprint-Review im Team nicht als positive Aktivität wahrgenommen wird, kann dies ein Hinweis auf folgende Probleme sein.

  • Das Team halst sich zu viel Arbeit auf und kann diese während einer Iteration nicht fertigstellen.
  • Das Team hat mit bestehenden technischen Schulden zu kämpfen.

  • Bei der Entwicklung der Features wird nicht auf Nachhaltigkeit geachtet, um nicht neue Bugs in die Codebasis einzuschleusen.

  • Die Entwicklungsverfahren des Teams könnten noch besser abgestimmt sein.

  • Der Product Owner ändert während einer Iteration die Prioritäten und das Entwicklerteam wird durch Scope Creep an die Wand gedrängt.

Anmerkung: Jedes Team durchlebt gelegentlich eine schwierige Iteration. Nimm dir in der Retrospektive die Zeit zu verstehen, warum eine Iteration sich geändert hat, und erstelle einen Plan, um die Probleme im nächsten Sprint in Angriff zu nehmen.

Schritt 3: Überschreiten geografischer Grenzen

Unternehmen mit verteilten Teams stehen vor speziellen Herausforderungen rund um die Skalierung agiler Rituale über mehrere Standorte hinweg. Sprint-Reviews sind hier keine Ausnahme. Das Jira-Team ist über den gesamten Erdball verteilt: Sydney, Danzig, Saigon und San Francisco. Die Sprint-Reviews sind trotz unserer Internationalität ein wichtiger Teil unserer Teamkultur. Die Teammitglieder erstellen informelle Videos und teilen sie auf einer Confluence-Seite, damit das gesamte Team sie ansehen kann.

Diese informellen Videos halten alle im Team trotz der Zeitunterschiede zum Entwicklungsfortschritt auf dem Laufenden. Eine Feature-Demo direkt vom Entwickler zu sehen, stärkt das Team in doppelter Hinsicht:

  • Produktverständnis: Das gesamte Team erhält Informationen zu Zweck, Grundgedanke und Implementierung des Features. Alle Teammitglieder erweitern ihre Kenntnisse zum Produkt.

  • Teamentwicklung: Die Videos schaffen persönlichere Beziehungen im Team. Jedes Teammitglied sieht, wer hinter den einzelnen Aspekten des Produkts steht. Die Verbindungen, die durch diese Vorgehensweise geschaffen werden, lassen uns trotz der räumlichen Trennung zu einer engeren, geschlosseneren Gruppe zusammenwachsen.

Zum Schluss noch ein letzter Ratschlag

Teams, für die Sprint-Reviews neu sind, neigen dazu, Sprint-Review und Retrospektive miteinander verschwimmen zu lassen. Ein Sprint-Review ist ein von der Sprint-Retrospektive unabhängiges Ritual. Nehmt euch die Zeit, die Früchte deiner Arbeit zu genießen. Feiert eure Leistungen ausgiebig. Effektive Sprint-Reviews fördern die Stimmung und Motivation im Team. Diese Würdigung unserer Leistungen ist für uns im Jira-Team so wichtig, dass wir aus genau diesem Grund "Los, lasst uns feiern!" in unsere erklärte Vision mit aufgenommen haben.

Up Next
Standups