Was zeichnet eine gute Scrum Review aus?

Home » Blog » Scrum » Scrum Review
  • Scrum Review

Was zeichnet eine gute Scrum Review aus?

In vielen Organisationen und Unternehmen besteht die Scrum Review in erster Linie daraus, dass die Entwickler das präsentieren, was sie im letzten Sprint fertig gestellt haben. Diese Demo ist sicherlich ein wichtiges Element einer jeden Scrum Review, aber nicht das einzige. Aber was soll in einer Review sonst noch passieren und was ist das Ziel der ganzen Veranstaltung?

Das oft vergessene Ziel einer Review steht explizit in der Bibel im Scum Guide:

The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities. (Scrum Guide, Seite 13)

Wenn man diese Zeilen liest, scheint das Demo-Element der Scrum Review tatsäch der am wenigsten wichtigste Teil zu sein. Das vorrangige Ergebnis soll es vielmehr sein, das Product Backlog zu überarbeiten. Wir möchten wissen, was die nächsten Schritte sollten.

Wenn Du Dich nun fragst, wie das erreicht werden kann, findest Du auf der gleichen Seite des Scrum Guides eine sehr wertvolle Liste mit wichtigen Elementen für eine gelungene Scrum Review, die ich an dieser Stelle ein wenig kommentieren möchte:

Wichtig für die Review ist laut Scrum Guide, dass die Key Stakeholder anwesend sind bzw. auch eingeladen wurden. Denn die Inhalte der Review sind gerade für diese besonders wichtig. Falls Deine Key Stakeholder abwesend sind, ist das manchmal ein Anzeichen dafür, dass Du die weiter unten folgenden Elemente einer Scrum Review ignoriert hast. Dann sehen Deine Key Stakeholder keinen Vorteil darin, sich die Zeit dafür zu nehmen. In diesem Fall solltest Du die Qualität Deiner Review verbessern. Es kann aber auch sein, dass Du bereits eine sehr gute Scrum Review machst, aber Deine Key Stakeholder trotzdem nicht erscheinen. Hier hilft es nur, Gespräche mit Deinen Key Stakeholdern zu führen und ihnen die Wichtigkeit der Scrum Review zu verdeutlichen.

Der Product Owner spricht in einer guten Scrum Review darüber, was fertig geworden ist und auch darüber, was nicht fertig geworden ist. Am einfachsten ist es, wenn er die User Stories aus dem letzten Sprint Backlog nacheinander kurz bespricht. Ein Impediment Backlog, das visualisiert, welche Hindernisse bestimmte User Stories wie lange aufgehalten haben, kann ebenfalls hilfreich sein.

All das erfordert natürlich eine gute gemeinsame Gesprächskultur, die frei von Schuldzuweisungen ist und auf Kollaboration basiert. Diejenigen Unternehmen, die diese Kultur (noch) nicht haben, werden durch dieses Element dazu gebracht, sie zu entwickeln. Doch nur dann, wenn man auch darüber spricht, was nicht fertig geworden ist, entsteht für alle Transparenz. Es ist nicht hilfreich, Dinge zu verschweigen oder zu beschönigen. Nur so können alle verstehen, was noch verbessert werden muss.

Anschließend berichtet das Entwickler Team darüber, wie der letzte Sprint lief und welche Probleme und Hindernisse dabei aufgetaucht sind. An dieser Stelle ist es übrigens auch hilfreich und möglich, Probleme und Hindernisse anzusprechen, die nicht gelöst werden konnten. Beispielsweise, weil externe Abhängigkeiten bestanden, die nicht aufgelöst werden konnten. Auch das ist ein gutes Mittel, um der Organisation (und anderen Key Stakeholdern) zu vermitteln, welche Dinge zu unternehmen sind, um die Velocity des Scrum Teams weiter zu steigern. Nicht jedes Problem kann ausschließlich durch das Scrum Team selbst gelöst werden: Kooperationen mit externen Partnern werden beispielsweise meist auf einer höheren Ebene entschieden.

Die Scrum Review ist somit auch der Ort, an dem fortlaufend sichtbar gemacht werden kann (und sollte), wie die Key Stakeholder das Team dabei unterstützen können, produktiver zu werden.

Dieser Teil ist das wohl bekannteste Element einer Scrum Review. Die Entwickler demonstrieren fertige Software (oder andere fertige Produkte) und beantworten die Fragen der Key Stakeholder dazu.

Nach der Demo übernimmt der Product Owner wieder die Scrum Review und bespricht mit allen Anwesenden das Product Backlog. Ist das Product Backlog gut gepflegt und sind zumindest die weit oben angesiedelten User Stories mit Story Points versehen, kann er auf Basis der aktuellen Velocity des Scrum Teams Auskunft darüber geben, welche User Stories im nächsten Sprint fertiggestellt werden können. Auch hier ist es Sinn und Zweck für alle Beteiligten Transparenz herzustellen.

Auch wenn der Product Owner der „Herr über das Product Backlog“ ist, dürfen wir nicht vergessen, dass er auch die Pflicht hat, es so zu strukturieren und zu ordnen, dass es den größten möglichen Wert erzeugt. Dazu benötigt er natürlich auch Feedback und Input von seinen Stakeholder. (Natürlich kann dieses Feedback jederzeit erfolgen. Aber die Scrum Review ist nichts desto trotz ein wichtiger „offizieller“ Ort für diesen Input.)

Gerade wenn in einer Review heiß darüber diskutiert wird, was als nächstes zu tun sei, ist das ein gutes Zeichen dafür, dass innerhalb des Unternehmens keine gemeinsame Vorstellung über die Ziele herrscht, die man mit dem Produkt erreichen will oder keine gemeinsame Produktvision existiert. Durch eine gemeinsame Review werden diese Diskrepanzen öffentlich sichtbar für alle. Und liefern den vielleicht notwendigen Impuls, genau daran zu arbeiten.

An dieser Stelle übernehmen die Key Stakeholder die Scrum Review einen wichtigen Part. Insbesondere Kunden und Mitarbeiter aus dem Marketing oder Vertrieb können dem Product Owner wertvolle Informationen darüber geben, in welcher Marktsituation sich das Produktes aktuell befindet und mit welchen Herausforderungen sie derzeit zu kämpfen haben. Nicht alle Anforderungen wird der Product Owner erfüllen können. Doch nur das gemeinsame Teilen dieser Informationen bietet die Möglichkeit, zumindest das Wertvollste als erstes zu tun.

Arbeitet das Unternehmen mit Releases und veröffentlich nicht nach jedem Sprint ein Update, können die Anwesenden nun darüber sprechen, welche Features in den nächsten Releases enthalten sein sollten. Erfahrungsgemäß nimmt die Genauigkeit in komplexen Umgebungen ab, je weiter man in die Zukunft blickt. Um nicht komplett „ins Blaue hinein“ zu diskutieren, kann die sogenannte Velocity Range dem Product Owner helfen, ein wenig mehr Klarheit für alle zu schaffen. Denn so kann er den Key Stakeholdern leichter kommunizieren, dass das eine oder andere Feature eventuell ein „Wackelkandidat“ (a.k.a. Might-Have-Feature) für den nächsten Release sein wird.

Das war’s von meiner Seite. Ich hoffe, meine kurzen Erläuterungen und Kommentare zum Scrum Guide helfen Dir und Deinem Team noch bessere Scrum Reviews abzuhalten. Über Feedback, Meinungen und Kommentare freue mich mich natürlich auch.

Mehr Infos

Scrum & Agiles Projektmanagement

Du möchtest Scrum in Deinem Unternehmen oder Deiner Abteilung einführen, weißt aber nicht wie Du vorgehen sollst? Ich berate Dich gerne!

Mehr Infos
Von |2018-12-10T17:26:20+00:0010. Dezember 2018|Kategorien: Scrum|Schlagworte: |0 Kommentare

Über den Autoren:

Ich glaube an eine Arbeitswelt, in der Menschen darauf brennen, am Montag endlich wieder zur Arbeit gehen zu dürfen. Deshalb helfe ich Menschen, Unternehmen und Organisationen, Arbeitsumgebungen so zu gestalten, dass sich Motivation und Engagement entfalten können.

Hinterlasse einen Kommentar

Newsletter

Diese Website benutzt Cookies und anderes Teufelswerk. Näheres dazu findest Du auf unserer Datenschutz-Seite. Verwalte hier Deine Einstellungen Einverstanden

Angebote von Drittanbietern

Hier kannst Du auswählen, welche Angebote von Drittanbietern Du während Deines Besuches auf dieser Webseite erlauben möchtest und welche nicht.