Was ist das wichtigste Event in Scrum?
Product Owner antworten hierauf meistens: „Sprint Planning“. Scrum Master fast immer: „Sprint Retrospektive“.
Warum antwortet fast niemand: „Sprint Review“?
Vielleicht, weil Sprint Reviews schwierig sind und sich deshalb viele Anti-Pattern etabliert haben. Beginnen wir gleich mit einem:
Anti-Pattern 1: Das Sprint Review wird abgesagt.
Im Jahr 2019 war ich Teil eines Scrum Teams. Der Sprint lief gut. Zwei Tage vor Sprint-Ende hatten wir alle Arbeiten erledigt, die für die Erreichung des Sprintziels nötig waren. Unser Team war bereits in Feierlaune. Nur das finale Deployment stand noch an.
Der Deployment-Prozess lief an, aber im letzten Moment brach er ab. Auch mehrmalige Versuche konnten das Problem nicht beheben. Was nun?
Wenn wir das Problem nicht beheben, was sollten wir morgen im Sprint Review sagen? „Eigentlich sind wir fertig, aber es funktioniert nichts.“ Werden unsere Kunden daraufhin das Vertrauen in unsere Zusammenarbeit verlieren und womöglich das Budget einfrieren? Wie würde unser Team einen solchen Rückschlag verkraften? Diese Gedanken gingen mir durch den Kopf.
Am nächsten Tag bewahrheitete sich meine Vorahnung und das Problem bestand immer noch. Es wäre leicht gewesen, das Sprint Review abzusagen. Aber unser Team nahm all seinen Mut zusammen und berichtete dem Kunden im Sprint Review, was vorgefallen war. Zu meinem Erstaunen machte sich unser Mut bezahlt, meine Befürchtungen traten nicht ein.
Was mich zurück zur Frage bringt: Warum nennt fast niemand das Sprint Review als das wichtigste Event in Scrum? Ich glaube, viele schrecken noch vor Sprint Reviews zurück. Sprint Reviews sind doppelt schwer. Es braucht die nötige Weitsicht, die für ein gelungenes Sprint Planning nötig ist. Und es braucht Mut und Offenheit, die auch in der Retrospektive über Erfolg und Misserfolg entscheiden.
Mein Tipp, um diesem Anti-Pattern zu begegnen: Sei mutig.
Anti-Pattern 2: Jeder Eintrag des Sprint-Backlogs wird vorgeführt.
Dieses Anti-Pattern sehe ich mit Abstand am häufigsten.
Hier zwei Beispiele, wie es aussehen kann:
- Die Entwickler stellen den Stakeholdern jeden Task des Sprint-Backlogs vor.
- Das Scrum Team stellt auch Einträge des Sprint-Backlogs vor, die noch nicht fertig sind.
Hier zwei Tipps, um dieses Anti-Pattern zu durchbrechen:
Tipp 1: Konzentriert euch auf eure Kunden.
Es geht nicht darum, zu zeigen, wie beschäftigt das Scrum Team in diesem Sprint war. Stattdessen soll verstanden werden, wie die Arbeit in diesem Sprint dazu beiträgt, die Schmerzen zu lindern oder die Bedürfnisse oder Anfragen der Nutzer und Kunden zu erfüllen. Deshalb beschränkt euch maximal auf eine Handvoll Einträge. Wählt dabei diejenigen aus, die Wert für Kunden und Nutzer versprechen. Aus meiner jahrelangen Erfahrung sind das die Punkte, für die sich Stakeholder aus Kundensupport, Vertrieb, Marketing und Geschäftsführung interessieren.
Tipp 2: Sprecht nur über die Einträge, die auch die „Definition of Done“ erfüllen.
Der Scrum Guide ist hier unmissverständlich:
„Wenn ein Product-Backlog-Eintrag nicht der Definition of Done entspricht, kann er weder released noch beim Sprint Review präsentiert werden.“
Das ist auch gut so. Über unfertige Arbeit zu sprechen, kann bei Stakeholdern schnell zu einer falschen Illusion führen. Außenstehende können häufig nicht einschätzen, wie viel Arbeit tatsächlich noch nötig ist. Das neue Feature ist zwar bereits auf dem Rechner eines Entwicklers zu benutzen, aber bis es tatsächlich an den Kunden geliefert werden kann, dauert es noch eine unbestimmte Zeit.
Ich habe noch einen weiteren Tipp für dich. Da dieser so häufig missachtet wird, habe ich ihn direkt als weiteres Anti-Pattern formuliert:
Anti-Pattern 3: Es werden keine Ziele besprochen.
Steht die Erreichung der Ziele im Sprint Review im Mittelpunkt, kuriert dies meistens Anti-Pattern 2.
Das Sprint-Ziel dient Scrum Teams zum einen dazu, aus einer Gruppe von Entwicklern ein wirkliches Team zu formen. Zum anderen liefert es diesem Team ein klares Bild von einer wünschenswerten Zukunft.
Sprint-Ziele helfen Scrum Teams zu beschreiben, was nach diesem Sprint für die Nutzer des Produkts möglich sein soll.
Ich nutze hierfür die Formulierung:
„Am Ende dieses Sprints wollen wir unseren Stakeholdern berichten, dass es unseren Nutzern nun möglich ist, folgende Sache zu tun.“
Mein Tipp gegen dieses Anti-Pattern ist jetzt wenig überraschend:
Hilf deinem Team, ein Sprint-Ziel für jeden Sprint zu formulieren. Nutze meine Formulierung und hilf deinem Team, die Platzhalter „Stakeholder“, „Nutzer“ und „Sache“ mit Leben zu füllen.
Wenn dein Team ein Sprint-Ziel hat, dann beginnt jedes Sprint Review mit der Erklärung dieses Ziels. Es wird berichtet, welche Einträge des Product-Backlogs das Team umgesetzt hat. Diese Einträge haben geholfen, das Ziel zu erreichen.
Ein motivierendes Ziel hilft dir, ein langweiliges in ein spannendes Meeting zu verwandeln. Denn ein Sprint-Ziel hilft, den Sprint in eine Geschichte zu verpacken und diese im Sprint Review zu erzählen.
Anti-Pattern 4: Die Teilnehmer sind passiv.
Im Sprint Review geht es um Feedback.
Wenn das Ergebnis der Arbeit nicht bekannt ist – was in der Entwicklung von Produkten nie der Fall ist –, hilft nur Feedback. Scrum Teams können so entscheiden, ob sie sich auf dem richtigen Weg zum Ergebnis befinden oder nicht. Wenn es den Anschein macht, dass die Anwesenden im Sprint Review eher schlafen, dann ist dies ein unübersehbares Zeichen, dass das Team kein Feedback erhält.
Hier zwei Tipps, wie du dieses Anti-Pattern beheben kannst:
Tipp 1: Verkürze das Sprint Review.
Im Scrum Guide steht, dass das Sprint Review bis zu 4 Stunden dauern darf. Es steht nicht dort, dass es nicht nach 30 Minuten vorbei sein kann. Denke daran: Je kürzer ein Meeting, desto einfacher ist es, aktiv zu sein und sich zu beteiligen. Lass dich dabei von der Frage leiten: Wenn wir nur eine Sache im Sprint Review besprechen könnten, welche sollte es sein?
Tipp 2: Reduziere die Redezeit des Teams und erhöhe die Redezeit der Stakeholder.
Das geht sehr einfach. Stelle mehr Fragen und lasse Raum für Antworten.
Die Fragen könnten lauten:
- Wenn ihr diese Funktion seht, welche Fragen stellen sich euch?
- In welchen Situationen seht ihr euch diese Funktion verwenden?
- Welche Aspekte der Funktion sind euch sofort klar und welche sind noch unklar?
- Wie intuitiv findet ihr die Bedienung dieser Funktion? Gibt es etwas, das euch verwirrt?
- Welche Verbesserungen oder zusätzlichen Features würdet ihr euch für diese Funktion wünschen?
- Könnt ihr euch weitere Situationen vorstellen, in denen diese Funktion nützlich sein könnte?
Den Raum für Diskussion schaffst du, indem du sie direkt in die Agenda aufnimmst. Etwa nach dem Punkt „Vorstellung des Ergebnisses des Sprints“ kommt der Punkt „Diskussion der Ergebnisse“ und erst dann „Ausblick auf die nächsten Sprints“.
Zum Abschluss noch ein Anti-Pattern, das häufig im Verborgenen bleibt:
Anti-Pattern 5: Das Sprint Review steht in Konkurrenz zu anderen Meetings.
Was meine ich damit? Eigentlich sind die Scrum Events so gestaltet, dass sie jegliche andere Meetings überflüssig machen.
Im Falle des Daily Scrums nennt dies der Scrum Guide auch explizit:
„Daily Scrums verbessern die Kommunikation, identifizieren Hindernisse, fördern die schnelle Entscheidungsfindung und eliminieren konsequent die Notwendigkeit für andere Meetings.“
Gleiches gilt für das Sprint Review. Wenn Stakeholder also nicht zum Sprint Review erscheinen, dann solltest du dem auf den Grund gehen. Möglicherweise gibt es andere Meetings im Unternehmen, die in Konkurrenz zum Sprint Review stehen.
Hier einige Beispiele:
- Produktstrategie-Meeting
- Projekt-Status-Meeting
- Treffen des Lenkungsausschusses
- Marketing- und Vertriebsstrategie-Meetings
- Kundenpräsentationen
- Budget-Review-Meetings
- Meetings zur Besprechung der Roadmap und Strategie
Gibt es solche Meetings in deinem Unternehmen, dann lautet mein Tipp:
Besuche sie und versuche, den Zweck des Meetings zu verstehen. Überschneidet sich das Ziel des Meetings mit dem Sprint Review deines Teams? Dann suche nach Möglichkeiten, diese Meetings zu verbinden.
Vielleicht heißt dann das Sprint Review nicht mehr Sprint Review. Aber ist das nicht ein zu verschmerzender Preis, wenn jetzt mehr Stakeholder anwesend sind und dein Team Feedback zu seiner Arbeit bekommt?