Agile Sprint-Reviews

Drei Schritte zur Optimierung von Sprint-Reviews in deinem Agile-Team

Dan Radigan Dan Radigan
Themen durchsuchen

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 Produktinhaber. 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 für den Zusammenhalt in Agile-Teams sehr wichtig.

Erst einmal sollten wir klären, warum die teameigene Definition von "Erledigt" für diese Agile-Zeremonie so eine große Rolle spielt.

Schritt 1: die Definition erledigter Arbeit

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

Aktualisieren einer agilen Karte in Jira

Das Erreichen der Ziellinie und das Fertigstellen einer Aufgabe erfordern eine gute Planung, eine klare Definition von "Erledigt" und eine konzentrierte Bearbeitung. Der Großteil hiervon geschieht während der Sprint-Planung, aber für einen erfolgreichen Sprint-Review und Sprint muss das Team noch ein wenig mehr tun als nur zu planen. Es muss sich ganz klar einig sein, wie die Arbeit abzuliefern ist und wann sie wirklich erledigt 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 Produktinhaber, Designer und Entwicklerteam 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-Reviews, automatisierte Tests 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 jedem 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 Produktinhaber 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 Vorgänge. Was sind Abnahmekriterien und Testhinweise?

  • Abnahmekriterien: Metriken, anhand denen der Produktinhaber ü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 Vorgänge 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 Vorgang klicken.

Schritt 2: Feiern von Teamerfolgen

Einer unserer zentralen Werte bei Atlassian lautet "Teamgeist ist Trumpf". 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 der Produktinhaber, das gesamte Entwicklerteam und der Scrum Master anwesend. Wir empfehlen als Best Practice, eine halbe bis ganze Stunde pro 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 Produktinhaber ä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 von Agile-Ritualen ü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. 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 zu vermischen. Ein Sprint-Review ist ein von der Sprint-Retrospektive unabhängiges Ritual. Nehmt euch die Zeit, die Früchte eurer 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.

Weiter geht's
Standups