Iterations-Review

Ziel

Das Iterations-Review ist die Sitzung, in der ein Team ein fertiggestelltes Inkrement der Lösung mit Stakeholdern vorführt und prüft, um Rückmeldungen zu erhalten; diesen Zweck setzt ihm die Agile Extension zum BABOK Guide. Das Team, das die Arbeit geleistet hat, führt die Sitzung. Sie kehrt am Ende jeder Iteration wieder; sie versammelt das ganze Team und jene Stakeholder, die der Product Owner oder der Kundenvertreter für das jeweilige Inkrement einlädt.

Das Ergebnis der Sitzung sind verwertbare Rückmeldungen. Der Product Owner oder der Kundenvertreter fasst sie zusammen und entscheidet, was ins Backlog aufgenommen wird. Die Agile Extension nennt den Grund für diesen Takt: Rückmeldungen früh und häufig einzuholen erhöht die Chance, dass eine Lösung den Bedarf deckt, wenn sie den Kunden ausgeliefert wird. Die Sitzung nützt mehr, wenn sie die geleistete Arbeit an die Vision und die Ziele der Organisation und der Initiative zurückbindet.

Die Agile Extension verortet die Technik am Horizont Delivery, wo sie den regelmässigen Kontakt zu den Stakeholdern zu den Stärken zählt. Tabelle 7.0.1 führt sie unter den Kommunikationstechniken, die mit Stakeholdern ausserhalb des Teams arbeiten. Die Retrospektive, in derselben Familie geführt, steht dort auf der Seite der internen Teams.

Die Abgrenzung zu Reviews von Arbeitsergebnissen

Das BABOK behandelt Reviews als die Bewertung des Inhalts eines Arbeitsergebnisses durch andere Personen als dessen Autor: ein Dokument, eine Spezifikation oder ein Modell, auf dem Papier geprüft. Die Agile Extension stützt sich auf dieses Kapitel und weicht im Gegenstand davon ab: Das Iterations-Review betrifft eine lauffähige Lösung, die in der Sitzung bedient wird. Ein Reviewer sucht die Abweichung zwischen einer geschriebenen Anforderung und ihrer Absicht; ein Stakeholder vor dem Inkrement entdeckt, was die geschriebene Anforderung nicht gesagt hat.

Die Abgrenzung zur Retrospektive

Die Retrospektive prüft unter den Teammitgliedern allein, wie das Team gearbeitet hat. Das Iterations-Review zeigt vor dem Team und vor externen Stakeholdern, was das Team gebaut hat. Beide Sitzungen schliessen dieselbe Iteration ab und folgen oft am selben Tag aufeinander; sie zu verwechseln heisst, ein internes Thema vor Kunden zu behandeln oder die Rückmeldungen der Kunden ohne Empfänger zu lassen.

Einsatz

Wann einsetzen

• Iterationsende mit fertiggestellter Arbeit: das Inkrement zeigen und das weitere Backlog mit denen klären, die es nutzen werden.
• Stakeholder ausserhalb des Teams: Kunden, Nutzer und Sponsoren reagieren auf ein Produkt, das sie selbst bedienen.
• Zweifel an der Deckung des Bedarfs: das laufende Inkrement zeigt die Abweichungen, die ein Dokument durchgehen lässt.
• Horizont Delivery über mehrere Monate: der Takt hält das Engagement der Stakeholder aufrecht.
• Team ohne direkten Kontakt zu seinen Nutzern: die Sitzung stellt ein Gespräch wieder her.

Wann nicht einsetzen

• Die Arbeitsweise des Teams steht zur Prüfung an: die Retrospektive abhalten.
• Ein Dokument oder eine Spezifikation ist zu bewerten: es läuft noch nichts, also ein Review des Arbeitsergebnisses durchführen.

Beschreibung

Drei Abschnitte

Das Team führt das fertiggestellte Inkrement im Betrieb vor. Die Anwesenden stellen ihre Fragen und besprechen, was sich in ihrem Umfeld geändert hat. Der Product Owner nimmt diese Rückmeldungen auf und passt das Backlog für die nächste Iteration an.

Der erste Abschnitt entscheidet über den Wert der beiden anderen. Die Agile Extension beschränkt die Vorführung auf fertiggestellte Arbeit: Vor einem halb integrierten Inkrement betreffen die Rückmeldungen eine Lösung, die nicht existiert. Der Scrum Guide macht daraus eine Regel: Ein Backlog-Item, das die Definition of Done nicht erfüllt, also die Qualitätskriterien, die ein Inkrement für den Status fertig erfüllen muss, darf im Sprint Review nicht gezeigt werden und geht zurück ins Backlog.

Die Elemente

Die Agile Extension beschreibt die Technik über zwei Elemente, die gelieferte Lösung und die Stakeholder, letztere aufgeteilt auf drei Rollen.

Das Sprint Review in Scrum

Der Scrum Guide gibt dem Sprint Review einen Zweck: das Ergebnis des Sprints zu prüfen und die folgenden Anpassungen zu bestimmen. Das Scrum Team stellt den wichtigsten Stakeholdern seine Arbeit vor und bespricht mit ihnen den Fortschritt zum Product Goal, dem Produktziel, dem die aufeinanderfolgenden Sprints das Team näherbringen. Die Anwesenden prüfen, was im Sprint erreicht wurde und was sich in ihrem Umfeld geändert hat, und entscheiden danach gemeinsam über das weitere Vorgehen. Das Product Backlog kann angepasst werden, um neue Gelegenheiten zu nutzen.

Der Guide bezeichnet das Ereignis als Arbeitssitzung und verlangt vom Team, es nicht auf eine Präsentation zu verkürzen. Er stellt es an vorletzter Stelle im Sprint, direkt vor die Retrospektive. Seine Dauer ist bei einem einmonatigen Sprint auf vier Stunden begrenzt; bei einem kürzeren Sprint ist die Sitzung in der Regel kürzer. Das Sprint Review ist keine Voraussetzung für die Produktivsetzung: Ein Inkrement kann den Stakeholdern schon vor dem Ende des Sprints ausgeliefert werden.

Was ein Iterations-Review scheitern lässt

Die Vorführung Aufgabe für Aufgabe

Das Team geht jedes fertiggestellte Item in der Reihenfolge des Backlogs durch und erklärt, was es getan hat. Stefan Wolpers führt dieses Muster unter den häufigen Mängeln, unter dem Namen "Sprint Accounting": Die Sitzung legt Rechenschaft über die geleistete Arbeit ab, statt zu zeigen, was die Lösung nun ermöglicht. Die Rückmeldungen betreffen dann Details einzelner Bildschirmmasken. Nach einigen Iterationen kommen die Stakeholder nicht mehr und das Team schliesst daraus, dass sie das Interesse am Produkt verloren haben. Dagegen hilft, einen vollständigen Ablauf zu zeigen, vom Bedarf einer Person bis zu dem Ergebnis, das sie erhält.

Das Review als Freigabeinstanz

Die Sitzung wird zu der Instanz, in der ein Stakeholder die Produktivsetzung genehmigt oder ablehnt. Die Traktanden verschieben sich zur Unterschrift. Das Team zeigt, was durchgeht, und schweigt über das, was noch wackelt; die Rückmeldungen verschwinden. Der Scrum Guide ist eindeutig: Das Sprint Review genehmigt keine Produktivsetzung. Einen Freigabeentscheid gibt es in den meisten Organisationen; er gehört zur Produkt-Governance und fällt ausserhalb dieser Sitzung.

Zu breit gestreute Rückmeldungen

Die Agile Extension nennt die erste Grenze: Wenn das Review ein breites Spektrum von Stakeholdern versammelt, werden die Rückmeldungen zu vielfältig, als dass das Team sie auswerten und danach handeln könnte. Zwanzig Personen bringen zwanzig Meinungen hervor, von denen keine entscheidet. Die wichtigsten Stakeholder sind jene, die sagen können, ob das Inkrement den Bedarf deckt: Eine Frage an drei Personen, die das Produkt nutzen werden, ist mehr wert als eine Runde mit zwanzig.

Rang wiegt schwerer als Nutzung

Die Agile Extension nennt die zweite Grenze: In einer Organisation, in der die Hierarchie zählt, wiegt die Rückmeldung eines hochgestellten Stakeholders schwerer als die der anderen, ohne Rücksicht auf dessen Umgang mit dem Produkt oder dessen Verständnis der Ziele. Eine Bemerkung des Direktors wird innerhalb einer Stunde zu einem Backlog-Item, jene einer Mitarbeiterin, die dreissig Dossiers pro Tag bearbeitet, bleibt eine Notiz. Die Moderation antwortet darauf, indem sie jede Rückmeldung ihrem Urheber und dessen Nutzung des Produkts zuordnet.

KI-Überlegungen

Ein Sprachmodell bereitet die Sitzung aus den fertiggestellten Items der Iteration vor: Es schlägt einen Ablauf für die Vorführung vor, der den Weg einer Nutzerin durch die Lösung nachzeichnet, ordnet jedes Item dem Ziel zu, dem es dient, und formuliert die Fragen an jede anwesende Gruppe. Nach der Sitzung transkribiert es die Diskussion und ordnet jede Rückmeldung dem betroffenen Backlog-Item zu.

Die Vorführung betrifft das reale Inkrement: Ein generiertes Mockup zeigt eine Lösung, die nicht existiert. Widersprüchliche Rückmeldungen abzuwägen heisst zu entscheiden, was das Team mit der Zeit der nächsten Iteration tut; der Entscheid liegt beim Product Owner, den die Agile Extension für diese Zusammenfassung benennt. Eine automatische Zusammenfassung glättet den einzelnen Einwand, oft jenen der Person, die das Produkt täglich nutzen wird.

Die Sitzung versammelt Personen ausserhalb der Organisation, Kunden eingeschlossen. Eine Aufzeichnung, ein Transkript oder Notizen mit Namen, die an einen externen Dienst gehen, sind eine Bearbeitung von Personendaten im Sinne des revidierten Datenschutzgesetzes (revDSG): Der vorgesehene Zweck wird vor der Sitzung angekündigt und bleibt auf das Angekündigte beschränkt.

Beispiele

Ein Team einer Kantonalbank liefert den Online-Hypothekenrechner in Sprints von zwei Wochen. Das Review des Sprints 12 versammelt das Team, die Product Ownerin, zwei Kundenberater aus den Filialen, die Compliance-Spezialistin für das Kreditgeschäft und drei Kunden, die im Vormonat eine Berechnung angefragt hatten. Das Team zeigt auf der Demonstrationsumgebung einen vollständigen Ablauf: Ein Haushalt gibt ein Einkommen von CHF 168'000 und ein Objekt zu CHF 900'000 ein, erhält die verlangten CHF 180'000 an Eigenmitteln und eine theoretische Belastung von CHF 53'000 pro Jahr beim kalkulatorischen Zinssatz von 5%, also 31,5% des Einkommens und damit unter der Grenze von einem Drittel. Das Ergebnis erreicht ihn danach per E-Mail. Die drei Kunden übernehmen der Reihe nach und geben ihre eigene Situation ein; erst beim Bedienen des Rechners stolpern zwei von ihnen über den angezeigten Zinssatz, was eine allein vom Team geführte Vorführung nicht zutage gefördert hätte.

Die nützlichste Zeile der Tabelle ist die letzte: Ein geliefertes Item, das keine Reaktion auslöst, weist auf eine Funktion hin, die niemand verlangt hat; diese Frage öffnet die Product Ownerin ausserhalb der Sitzung wieder. Die drei anderen Zeilen sind während der Sitzung ins Backlog eingegangen, vor den Augen ihrer Urheber; jene, die noch zu klären ist, geht durch das Backlog Refinement, bevor sie in eine Iteration aufgenommen wird. Ein Entscheid über die Produktivsetzung ist nicht gefallen: Der Rechner geht in Betrieb, sobald der überarbeitete rechtliche Hinweis freigegeben ist.

Visualisierungen

Die wichtigste Visualisierung eines Iterations-Reviews ist das Inkrement selbst, im Betrieb gezeigt auf einer Umgebung, auf der die Anwesenden es bedienen können. Ein Screenshot oder eine Präsentationsunterlage bringt nicht dieselben Rückmeldungen.

Das Ergebnis der Sitzung passt in eine Tabelle mit drei Spalten: was gezeigt wurde, die erhaltene Rückmeldung mit ihrem Urheber, der Entscheid fürs Backlog. Von Review zu Review geführt, bringt dieses Register jene Rückmeldung zum Vorschein, die ein zweites Mal kommt, ohne bearbeitet worden zu sein, ebenso die gelieferten Items, von denen niemand spricht.

Aufwand

Werkzeuge

Die Demonstrationsumgebung trägt die Sitzung. Eine Integrations- oder Vorproduktionsumgebung, die mit dem Inkrement der Iteration aufgefrischt und mit plausiblen Daten bestückt ist, erlaubt es, das Produkt im Betrieb zu zeigen. Leere oder unsinnige Testdaten verschieben die Diskussion auf den Datenbestand. Eine Umgebung, die mit einer Kopie der Produktion gefüllt ist, legt Personendaten gegenüber Externen offen und verlangt eine vorgängige Anonymisierung.

Die Werkzeuge für das Backlog-Management (Jira, Azure DevOps, GitLab und ihre Entsprechungen) nehmen die Rückmeldungen während der Sitzung auf. Ein Item, das vor dem versammelten Raum angelegt wird, mit dem Urheber der Rückmeldung in seiner Beschreibung, erspart die Rekonstruktion aus dem Gedächtnis am nächsten Tag und zeigt den Stakeholdern, dass ihre Bemerkung aufgenommen wurde.

Die Videokonferenz mit Bildschirmfreigabe (Teams, Zoom, Webex und ihre Entsprechungen) ermöglicht die Sitzung auf Distanz; die Agile Extension zieht das Gespräch vor Ort vor. Auf Distanz geht das Bedienen durch die Stakeholder verloren: Einem Kunden auf der Demonstrationsumgebung die Steuerung zu übergeben oder ihm vor der Sitzung den Zugang zu schicken stellt diesen Kontakt wieder her.

Quellen

• IIBA, Agile Extension to the BABOK Guide, §7.15 Reviews: der Zweck der Technik, die Vorführung einer lauffähigen Lösung, die Führung durch das Team, das die Arbeit geleistet hat, die Beschränkung auf fertiggestellte Arbeit, die Rückbindung an die Vision und die Ziele, die Zusammenfassung der Rückmeldungen durch den Product Owner, die Elemente sowie die dort genannten Stärken und Grenzen, darunter das regelmässige Engagement der Stakeholder am Horizont Delivery, die zu breit gestreuten Rückmeldungen und das Gewicht des hierarchischen Rangs.
• IIBA, Agile Extension to the BABOK Guide, §7.0, Tabelle 7.0.1 Selecting the Right Technique: das Review, eingeordnet unter den Kommunikationstechniken, die mit Stakeholdern ausserhalb des Teams arbeiten.
• Ken Schwaber und Jeff Sutherland, The Scrum Guide (November 2020), Abschnitte "Sprint Review" und "Increment": der Zweck des Ereignisses, die Vorstellung vor den wichtigsten Stakeholdern, die Besprechung des Fortschritts zum Product Goal und dessen, was sich im Umfeld geändert hat, die mögliche Anpassung des Product Backlogs, die Arbeitssitzung, die nicht auf eine Präsentation verkürzt wird, die Stellung als vorletztes Ereignis des Sprints und die Obergrenze von vier Stunden bei einem einmonatigen Sprint; sodann, für das Inkrement, der Ausschluss jeder Rolle als Freigabeinstanz und die Regel, die das Zeigen eines Items verbietet, das die Definition of Done nicht erfüllt.
• Stefan Wolpers, 15 Sprint Review Anti-Patterns, Scrum.org, 2019: ein Katalog aus der Praxis, nicht normativ; das Durchgehen jedes fertiggestellten Items, das er "Sprint Accounting" nennt, und das zur Freigabeinstanz umgebaute Review.