Viele Organisationen verpassen leider die Chance das Beste aus dem Sprint Review zu machen indem sie sich während dieses Scrum Events auf Folgendes konzentrieren:

• Entwickler demonstrieren dem Product Owner die im letzten Sprint geleistete Arbeit und beantworten Fragen zum Inkrement.
• Der Product Owner akzeptiert die „Done“-Elemente und entscheidet, was nicht „Done“ war.
• Das Team feiert die Leistung und geht zum nächsten Meeting über (Sprint Planning).

‍

Während all diese Dinge entweder im Scrum Guide erwähnt sind oder in vielen Organisationen als „gute Praktiken“ angesehen werden, verpassen sie meiner Meinung nach alle die Gelegenheit, das Beste aus diesem Scrum-Event herauszuholen: das Produkt zu inspizieren und anzupassen und darauf zu schauen, was als nächstes getan werden muss, um den Lieferwert zu maximieren.

‍

Hier sind meine Top 4 Vorschläge zum Sprint Review:

1. Echte Kunden und/oder Endnutzer ins Sprint Review einbinden.
2. Product Owner (oder eine unterstützende Person) gibt Einblicke in die Leistung des Produktes, bestehende Zeitpläne, Budgets und Marktchancen.
3. Kunden und/oder Endbenutzer sollten die neuen Produkt-Features, die das Team implementiert hat, so weit wie möglich praktisch erleben.
4. Teilnehmern die Möglichkeit geben, die Erkenntnisse aus dem Sprint Review ins Product Backlog zu übertragen.

Hier etwas mehr zu den einzelnen Punkten:

1. Echte Kunden und/oder Endnutzer ins Sprint Review einbinden

Scrum schlägt vor, Stakeholder in das Sprint Review einzubeziehen, aber oft sehe ich nur Entwickler, die das Produktinkrement dem Product Owner und manchmal Product Ownern anderer Teams präsentieren. Dies ist oft ein Zeichen dafür, dass das Team ein Komponententeam ist, das sich nur auf einige technische Teile eines Systems konzentrieren, die in die Arbeit anderer Teams integriert werden müssen, was automatisch zu einer Wasserfallentwicklung führt. Dies kann nur geändert werden, indem Sie Ihr Organisationsdesign ändern, um Feature Teams zu erstellen, die Ende-zu-Ende-Kundenanforderungen implementieren, wie z.B. in LeSS vorgeschlagen. Aber selbst mit Feature-Teams, erlebe ich in vielen Organisationen, dass Sprint Reviews ohne tatsächliche Kunden oder Endbenutzer durchgeführt werden, weil man oft nicht weiss, wie man die richtigen Personen findet, motiviert und einbezieht. Bei der Entwicklung eines internen Produktes (wie ein CRM-System), sollten die Endnutzer diejenigen sein, die dieses System verwenden. Das bedeutet, dass es nicht schwierig sein sollte, diese zu finden und zu motivieren, an dem Sprint Review teilzunehmen. Bei der Entwicklung eines marktorientierten Produktes, gibt es üblicherweise eine Marketingabteilung (wenn diese Leute nicht in dem Teams integriert sind) sowie eine ausgewählte Gruppe von Erstanwendern, die Ihr Produkt lieben und ausgiebig nutzen. Sollte das nicht der Fall sein, wäre es vielleicht gut darüber nachdenken, ob es sich weiterhin lohnt, in diese Produktentwicklung zu investieren. Es sollte nicht schwer sein, zumindest ein paar verschiedene Personen aus diesen Gruppen in dem Sprint Review zu integrieren.

2. Product Owner gibt Einblicke in die Leistung des Produkts, bestehende Zeitpläne, Budgets und Marktchancen

Das Sprint Review sollte eine Gelegenheit für alle sein, die an der Produktidee, -erstellung, -lieferung und -nutzung beteiligt sind, zu beurteilen, ob das richtige Produkt (mit den richtigen Features) geliefert wurden. Dies ist einer der wichtigsten Teile der empirischen Prozesskontrolle. Es hat keinen Wert, in kurzen Iterationen zu liefern, wenn man nicht gründlich analysiert, ob die richtigen Sachen geliefert werden, und die Richtung andernfalls geändert wird. Um dies richtig einzuschätzen, müssen man sich die tatsächlichen Nutzungsdaten ansehen, z. B. wie viele tatsächlich das Produkt benutzen, wie oft die neuen Funktionen konsumiert werden und vor allem, ob die kürzlich entwickelten Produktfunktionen zu der gewünschten Wirkung geführt haben. Ich persönlich nutze gerne Techniken wie Impact Mapping dafür. Aus diesem Grund ist es eine gute Idee, aufschlussreiche Daten über die Produktnutzung für alle Teilnehmer des Sprint Reviews vorzubereiten. Dies kann vom Product Owner vorbereitet oder an andere Produktmanager delegiert werden, aber natürlich muss der Product Owner den Überblick behalten, um wichtige Produktentscheidungen treffen zu können. Auch wenn es offizielle Veröffentlichungszeitpläne gibt, die kommuniziert wurden, ist das Sprint Review eine Gelegenheit, die Erwartungen mit den Stakeholdern zu managen. Darüber hinaus sollten Sie Feedback zu Budgetzahlen geben, die der Product Owner als derjenige, der für den ROI des Produkts verantwortlich ist, verwalten sollte. Alle anderen wichtigen Einblicke in Bezug auf die Marktveränderung und Möglichkeiten, die für alle an der Produktidee, -kreation, -lieferung und -nutzung Beteiligten wertvoll sind, können im Sprint Review bekannt gegeben werden.

3. Kunden und/oder Endbenutzer sollten die neuen Produkt-Features , die das Team implementiert hat, so weit wie möglich praktisch erleben

Das ist eine andere Sache, womit sich viele Teams schwer tun. Ja, es ist großartig, Ihre Entwickler zu befähigen und zu motivieren, Kunden und Stakeholdern neu implementierte Features zu präsentieren, aber diese Demos haben schwerwiegende Nachteile:

• Die Entwickler zeigen, was sie getestet haben und was funktioniert hat (und nicht das was vielleicht nicht funktioniert).
• Sie erklären normalerweise, wie und warum sie die Funktion auf eine bestimmte Weise verwenden würden.
• Das Feedback beschränkt sich auf einzelne Leute, denen was während der Demo aufgefallen ist, und sich nicht scheuen das zu erwähnen.

Anstatt Entwickler die neu implementierten Funktionen präsentieren zu lassen, schlage ich vor, allen Teilnehmern des Sprint Reviews die Möglichkeit zu geben, die Funktionen so praktisch wie möglich zu erleben. Sie können dies erreichen, indem Sie (1) den Teilnehmern ein Gerät übergeben , (2) den Link zur Software/Anwendung geben oder (3) einige gedruckte/digitale Prototypen auf ein (virtuelles) Whiteboard stellen . Sie können eine kurze Beschreibung hinzufügen, wie Sie auf die Funktionen zugreifen, zu denen Sie Feedback erhalten möchten, sowie alle anderen Fragen, die Ihnen dabei helfen, wertvolles Feedback zu erhalten.

Diese Vorgehensweise hat verschiedene Vorteile:

• Die Entwickler können miterleben, wie die Kunden das Produkt/die Funktionen tatsächlich wahrnehmen und verwenden.
• Die Benutzer werden nicht bei der Verwendung der Funktionen beeinflusst (was die Realität widerspiegelt - den Kunden kriegen die neuen Features auch nicht erklärt).
• Entwickler werden manchmal Zeuge eines Kundenverhaltens, das ganz anders ist als erwartet, was ihnen hilft, in Zukunft bessere Lösungen zu entwickeln.

4. Teilnehmern die Möglichkeit geben, die Erkenntnisse aus dem Sprint Review ins Product Backlogs zu übertragen

Sie möchten den Teilnehmern nicht nur ermöglichen, das Inkrement des Sprints so praktisch wie möglich zu erleben, sondern ihnen auch die Möglichkeit geben, so viel Feedback wie möglich zu geben. Ich mache das, indem ich darauf achte, dass neben dem Gerät oder dem Papierprototypen reichlich Post-its und Stifte herumliegen, oder wenn ich das virtuell mache, lasse ich das/die Team(s) Screenshots der App-Bildschirme erstellen, oder alles, was es zu überprüfen gibt, auf einem virtuellen Whiteboard, wo die Teilnehmer direkt Feedback hinterlassen können. Sie können auch zusätzliche Fragen hinzufügen (z. B. welche Funktionen derzeit fehlen oder ob sie erwarten würden, dass die Funktionalität anders funktioniert), um wertvolles Feedback zu erhalten. Sie werden erstaunt sein, wie viel Feedback Sie bekommen, verglichen mit „nur einer Demo“.

Aber der entscheidende Teil beginnt erst, nachdem Sie alle Rückmeldungen erhalten haben. Denn wie ich bereits erwähnt habe, hat es wenig Wert, eine iterative und inkrementelle Entwicklung durchzuführen, wenn Sie das Backlog nicht ständig anpassen und sicherstellen, dass Sie an den Elementen arbeiten, die auf der Grundlage des neuesten Feedbacks und des aktuellen Verständnisses dem Unternehmen/den Kunden den höchsten Wert liefern. Sie möchten also das gesamte Feedback destillieren und zu einer Entscheidung kommen, welches kritische Feedback Sie haben und sofort (vielleicht bereits im nächsten Sprint) darauf reagieren möchten, welches wichtige Feedback es gibt, das Sie in einem zukünftigen Product Backlog Refinement weiter besprechen möchten und welches Feedback derzeit nicht wichtig ist. Sie können dies tun, indem Sie alle Rückmeldungen zusammenfassen und die Gruppen in verschiedene Kategorien unterteilen.

‍

Mit nur diese 4 Änderungen erhalten Sie ein interaktives Event, bei denen jeder Produktersteller/-entwickler direkt mit Kunden/Benutzern des Produkts interagiert und versteht, wie das aktuelle Produkt seinen Zweck erfüllt und was er als Nächstes implementieren muss, um die Probleme des Kunden zu lösen oder bestimmte Ergebnisse besser zu erzielen.

‍

Um ein Sprint Review zu erleben, bei dem alle oben genannten Vorschläge demonstriert werden, abonieren Sie unseren Lean Sherpas LeSSons Learned Newsletter. Wir ermöglichen unseren Kunden und Auftraggebern, an unseren eigenen Sprint Reviews teilzunehmen und uns in Aktion zu erleben.

‍