TL;DR

Scrum erfordert, dass das Event am Ende jeder Iteration abgehalten wird, sogar zu Beginn eines Projekts. Auch wenn Sie erwägen könnten, es zu verkürzen oder den Fokus leicht auf den Prozess statt auf die Ergebnisse zu verlagern, sollte die Veranstaltung dennoch stattfinden.

Ereignisse bauen Kadenz auf

Formal ist das Sprint Review ein Pflichtereignis in Scrum. Während es sicherlich vernünftig ist, sich kurz zu halten, wenn Sie wenig zu demonstrieren haben, ist es wichtig, frühzeitig den Ton für eine zuverlässige Kadenz anzugeben. Diese Kadenz erzeugt:

1. Vorhersagbarkeit. Stakeholder können sich darauf verlassen, dass bei jeder Iteration ein Inspektionspunkt zur Verfügung steht.
2. Transparenz. Stakeholder können sich darauf verlassen, dass sie an jedem Inspektionspunkt einen klaren Einblick in das Projekt haben, nicht nur, wenn es gute Nachrichten zu teilen gibt.

Auch wenn Sie also nichts für Ihre Bemühungen vorzuweisen haben (und das haben Sie, also lesen Sie weiter), lohnt es sich, die Veranstaltung abzuhalten.

Mehrwert

Auch wenn Sie nichts zu demonstrieren haben, ist ein kurzes Sprint Review nützlich, um die Zusammenarbeit mit den Beteiligten einzuladen. Der Scrum Guide bietet einige klare Beispiele dafür, was ein Sprint Review neben der Demonstration der Ergebnisse enthalten sollte:

• Der Product Owner bespricht das Product Backlog in seiner jetzigen Form. Er oder sie prognostiziert voraussichtliche Ziel- und Liefertermine basierend auf dem bisherigen Fortschritt (falls erforderlich);
• Die gesamte Gruppe arbeitet daran, was als nächstes zu tun ist, sodass das Sprint Review wertvollen Input für die nachfolgende Sprint-Planung liefert;
• Überprüfung, wie sich der Markt oder die potenzielle Verwendung des Produkts geändert haben könnte, was als nächstes am wertvollsten ist; und,
• Überprüfung des Zeitplans, des Budgets, der potenziellen Fähigkeiten und des Marktes für die nächsten erwarteten Versionen von Funktionen oder Fähigkeiten des Produkts.

Neben der Etablierung einer Kadenz und der Schaffung eines Gefühls des Vertrauens bei den Stakeholdern durch Vorhersehbarkeit und Transparenz lädt das Sprint Review also zu einer strukturierten Zusammenarbeit mit dem Scrum-Team ein!

Dinge, die Sie demonstrieren können

Zugegeben, Sie können ein Produktinkrement möglicherweise nicht vorführen. Aber wenn Sie darüber nachdenken, können Sie den Wert des Projekts immer noch demonstrieren, insbesondere wenn Sie eine Test-First-Agilitäts-Denkweise angenommen haben!

Demonstrierbar ist beispielsweise die Einrichtung einer Entwicklerumgebung oder eines Continuous-Integration-Servers. Verwenden Ihre Entwickler eine IDE? Schnappen Sie sich einen Projektor und demonstrieren Sie die Intellisense-Funktionen (oder was auch immer), die dem Projekt vermutlich durch die Effizienz der Entwickler einen Mehrwert verleihen werden. Halten Sie es kurz, aber erklären Sie, warum es wichtig ist!

Haben Sie Continuous Integration zum Laufen gebracht? Ich wette, die Teammitglieder, die es gemacht haben, haben es irgendwie getestet. Auch wenn sie noch keine Produktinkremente durchpumpen, müssen sie etwas getan haben , um sicherzustellen, dass es wie erwartet funktioniert. Machen Sie daraus eine visuelle Demo und erklären Sie, wie diese teamorientierte Funktion dazu beitragen wird, das Produkt zu liefern, das den Stakeholdern letztendlich am Herzen liegt.

Bekenntnisse aus der realen Welt

Ich gebe zu, von Zeit zu Zeit ein Sprint Review abgesagt zu haben, insbesondere zu Beginn oder am Ende eines Projekts. Ich habe dies jedoch immer als einen Mangel an Vorstellungskraft oder als Ergebnis eines übermäßig spezifikationsorientierten (und nicht testorientierten) Ansatzes für das Projekt und seine Produktentwicklungsmethodik angesehen.

Wenn Sie wirklich nichts demonstrieren können und nichts haben, an dem die Beteiligten möglicherweise zusammenarbeiten möchten, dann möchten Sie sicherlich nicht die Zeit aller verschwenden. Unter solchen Umständen kann es sinnvoll sein, das Sprint Review nur auf das Scrum-Team (einschließlich des Product Owners) zu beschränken. Stellen Sie nur sicher, dass Sie angemessene Erwartungen darüber haben, wann Sprint Reviews ernsthaft beginnen werden, und stellen Sie sicher, dass Sie dem Product Owner und den Stakeholdern mitteilen, welchen Wert Ihr Sprint geliefert hat.

Am Anfang eines Projekts, selbst wenn ich kein formelles Sprint Review abgehalten habe, habe ich normalerweise immer noch eine informelle Veranstaltung abgehalten, um den Umfang, die Methodik oder den Ansatz des Projekts zu besprechen. Das kommt in der Regel gut an.

Zum Ende hin gibt es produkttechnisch meist mehr zu zeigen. Manchmal interessieren sich die Beteiligten jedoch weniger für die kleinen, inkrementellen Änderungen in dieser Phase des Projekts. In diesen Fällen habe ich das formelle Sprint Review manchmal durch kürzere Stakeholder-Meetings ersetzt. Dort sprechen wir oft über Zeitpläne, Versandtermine oder Projektabschlussthemen.

Ich behaupte nicht, dass es eine bewährte Methode ist, und behaupte sicherlich nicht, dass es Scrum ist. Es ist jedoch sicherlich eine Option, wenn eine strikte Einhaltung des Frameworks nicht erwünscht ist oder wenn die Unreife des Prozesses oder die Apathie der Stakeholder das Starten (oder Beibehalten) der Kadenz unpraktisch machen.

Meine praktische Erfahrung ist, dass es unter bestimmten Umständen von Vorteil sein kann, das Ereignis zu verkürzen oder den Fokus leicht auf den Prozess zu verlagern. Die Veranstaltung komplett zu überspringen, war für mich jedoch fast immer ein Projektgeruch. Ich empfehle es nicht, aber Ihre Laufleistung kann variieren.

Ja! Meine Empfehlung wäre eigentlich, ein wirklich kleines Ziel zu haben, das leicht zu sehen ist, aber nicht viel Arbeit (oder vielleicht Wert) hinzufügt. Es ist mehr ein Gesprächsstoff als alles andere. Diese erste Überprüfung ist eine großartige Zeit, um die Voraussetzungen für das Projekt zu schaffen und die Leute vorzustellen. Sie müssen die Zeitbox nicht füllen, aber es ist eine großartige Möglichkeit, die Dinge ohne Stress mit dem richtigen Fuß zu beginnen.

architektonische User Stories ohne geschäftlichen Wert

Ich ermutige die Teams, eine sehr einfache erste User Story im „Hallo Welt“-Stil zu erstellen, die einen begrenzten, aber ungleich Null-Geschäftswert bietet. Führen Sie dann alle technischen Setup-Aufgaben unter dieser User Story durch.

Der Vorteil dieses Ansatzes besteht darin, dass er das Team dazu bringt, sich immer auf die Bereitstellung des Geschäftswerts zu konzentrieren, und deutlich macht, dass technische Aufgaben nur Mittel zum Zweck sind.

Als Beispiel hat ein Business Intelligence-Team, mit dem ich zusammengearbeitet habe, eine erste Geschichte erstellt:

Als Marketing Manager möchte ich das Datum des Registrierungsberichts sehen, damit ich weiß, wann er erstellt wurde

Dann erledigte das Team alle Einrichtungsaufgaben und erstellte einen sehr einfachen Online-Bericht, der das aktuelle Datum und sonst nichts enthielt. Diese erste Geschichte dauerte wegen der ganzen Einrichtungsarbeit, die sie beinhaltete, einen ganzen zweiwöchigen Sprint.