Autor: Stefan Ruchti

Definition des Backlog Refinements Backlog Refinement, auch bekannt als Backlog Estimation oder Backlog Grooming, bezeichnet den fortlaufenden Prozess der Pflege und Aktualisierung des Product Backlogs. In diesem Prozess arbeiten der Product Owner und das Entwicklungsteam zusammen, um das Backlog aktuell zu halten. Typische Aktivitäten im Rahmen des Backlog Refinements umfassen: Ziele des Backlog Refinements Das Hauptziel des Backlog Refinements besteht darin, die höher priorisierten Elemente im Backlog so vorzubereiten, dass sie optimal für das Sprint Planning genutzt werden können. Dies trägt zur Verkürzung von Planungsmeetings bei, während es gleichzeitig aktuelle Informationen berücksichtigt. Der Scrum Guide weist dem Product Owner die Verantwortung für das Product Backlog und damit auch für dessen Refinement zu, auch wenn diese Aufgaben delegiert werden können oder Entwickler aktiv an der Verfeinerung beteiligt sind. Backlog Refinement im Scrum Guide Obwohl das Backlog Refinement im Scrum Guide nicht als offizielles Event wie das Daily Scrum oder das Sprint Planning aufgeführt ist, wird empfohlen, es regelmäßig durchzuführen. Der Scrum Guide von 2017 beschreibt es als fortlaufenden Prozess, bei dem der Product Owner und das Entwicklungsteam zusammenarbeiten, um Details, Schätzungen und die Reihenfolge der Backlog-Einträge zu aktualisieren. Der Scrum Guide 2020 erwähnt das Refinement nur kurz und verzichtet auf detaillierte Beschreibungen oder Empfehlungen bezüglich des maximalen Aufwands. Dennoch bleiben die wesentlichen Aspekte des Backlog Refinements in der Praxis unverändert: Best Practices für das Backlog Refinement Es gibt eine Reihe bewährter Methoden, um das Backlog Refinement effizient zu gestalten. Obwohl der Scrum Guide die Verantwortung dem Product Owner zuschreibt, ist es ratsam, auch den Scrum Master in den Prozess einzubeziehen. Der Scrum Master kann eingreifen, wenn Diskussionen länger als geplant dauern, indem er Zeitlimits für User Story-Diskussionen setzt. Der INVEST-Ansatz von William Wake bietet eine gute Grundlage für die Definition hochwertiger User Stories, während der DEEP-Ansatz von Roman Pichler für die Pflege der Backlog Items nützlich ist. User Story Maps können helfen, den Überblick zu behalten und die Stories für das Team sichtbar zu machen, was die Diskussion von Akzeptanzkriterien erleichtert. Gemeinsame Schätzungen der Stories, zum Beispiel mit Story Points, fördern ein besseres Verständnis und können Diskrepanzen aufzeigen, die durch unterschiedliche Realisierungsansätze entstehen. Timeboxes sind ein gängiges Mittel, um klare zeitliche Grenzen für Aktivitäten zu setzen, wobei die Qualität und Relevanz der Backlog Items im Vordergrund stehen sollten. Vorteile des Backlog Refinements Das Backlog Refinement bietet zahlreiche Vorteile: Tipps für effizientes Backlog Refinement Unternehmen stehen vor der Herausforderung, Backlog Refinements effizient zu planen und durchzuführen. Hier einige Tipps:

Inkrement – Die schrittweise Erweiterung des Lieferumfangs Der Begriff „Inkrement“ leitet sich vom Lateinischen ab und bedeutet auf Deutsch „vergrößern“ oder „Zuwachs“. In der inkrementellen Softwareentwicklung bedeutet dies, dass das gesamte System geplant wird, jedoch in einzelnen Teilen umgesetzt wird. Mit jedem Inkrement wachsen der Umfang und/oder die Funktionalitäten des Systems. Dieses Konzept findet Anwendung in verschiedenen Vorgehensmodellen, Methoden und Frameworks wie Scrum, Extreme Programming, Scaled Agile Framework (SAFe), Large-Scale Scrum (LeSS), Feature-Driven Development (FDD) und dem V-Modell XT. Das Inkrement in Scrum In der agilen Entwicklung von Software, Produkten oder Dienstleistungen, wie zum Beispiel in Scrum, stellt das Inkrement das erwartete, potenziell lieferfähige Ergebnis eines Sprints dar. Der Scrum Guide beschreibt es als „ein konkretes Etappenziel auf dem Weg zum Produktziel, wobei jedes Inkrement zu den vorherigen beiträgt und gründlich überprüft wird, um sicherzustellen, dass alle zusammenwirken. Um tatsächlichen Wert zu liefern, muss es nutzbar sein“. Der Umfang des potenziell lieferfähigen Ergebnisses wird durch das Sprint Backlog festgelegt, auf das sich die Entwickler während des Sprint Plannings verpflichten. Bevor das Ergebnis freigegeben wird, muss die Definition of Done überprüft werden. Potenziell lieferfähig bedeutet, dass die Software – wie definiert – funktioniert und an Kunden oder Anwender ausgeliefert werden könnte. In der Praxis wird jedoch nicht jedes Sprint-Ergebnis sofort ausgeliefert; meist werden die Ergebnisse mehrerer Sprints gebündelt als Release zur Verfügung gestellt und durch Marketing und Vertrieb vermarktet. Das Inkrement in Large-Scale Scrum (LeSS) Large-Scale Scrum (LeSS) ist ein Framework zur Skalierung von Scrum auf mehrere Teams, die an einem gemeinsamen Produkt arbeiten. Innerhalb von LeSS wird das „Inkrement“ ähnlich wie im traditionellen Scrum definiert, jedoch mit zusätzlichen Aspekten, die für die Skalierung relevant sind. Da mehrere Teams an einem Produkt arbeiten, trägt jedes Team zur Erstellung eines gemeinsamen Inkrements bei, was die Zusammenarbeit und die gemeinsame Verantwortung fördert. Die Notwendigkeit eines integrierten Inkrements am Ende jedes Sprints unterstreicht die Wichtigkeit der kontinuierlichen Integration und Zusammenarbeit zwischen den Teams. Dadurch wird sichergestellt, dass die Arbeit aller Teams kompatibel und funktionsfähig ist. Ein potenziell auslieferbares Inkrement ermöglicht es dem Produktmanagement und den Stakeholdern, den Fortschritt regelmäßig zu überprüfen und fundierte Entscheidungen basierend auf den tatsächlichen Ergebnissen zu treffen. Die inkrementelle Systementwicklung im V-Modell XT Das V-Modell XT, als deutscher Standard für die Planung und Durchführung von Systementwicklungsprojekten, das in Unternehmen, Behörden und im militärischen Bereich genutzt wird, definiert eine inkrementelle Systementwicklung. Diese berücksichtigt sowohl Neuentwicklungen als auch die Weiterentwicklung und Migration von Altsystemen. Sie kann angewendet werden, wenn die Anforderungen an das zu entwickelnde oder weiterzuentwickelnde System als relativ stabil gelten und die technologischen Risiken gering sind. Auch der Einsatz von Fertigprodukten ist möglich. Die inkrementelle Featureentwicklung bei FDD In Feature-Driven Development (FDD) wird die Entwicklung in kleinere, iterative Schritte unterteilt, die sich auf die Implementierung von Features konzentrieren. Diese Features sind eigenständige, funktionsfähige Teile des Systems, die schrittweise entwickelt werden. Jedes Feature kann als ein Inkrement betrachtet werden, das während eines Entwicklungszyklus hinzugefügt oder verbessert wird. FDD legt Wert auf die kontinuierliche Lieferung von funktionsfähiger Software, wobei die fertigen Features die Inkremente darstellen, die den Wert für den Kunden steigern.

Defintion Sprint Backlog Während eines jeden Sprints soll ein funktionsfähiges und potenziell auslieferbares Zwischenprodukt, bekannt als Inkrement, entwickelt werden. Im Sprint Planning Meeting wird entschieden, welche Items aus dem Product Backlog oder dem Release Backlog (abhängig vom Vorgehen innerhalb einer Organisation) in das Sprint Backlog aufgenommen werden, um im kommenden Sprint umgesetzt zu werden. Das Team wählt die Items oder User Stories mit den höchsten Prioritäten aus und schätzt, welche und wie viele davon im nächsten Zeitraum realisiert werden können. Diese ausgewählten Items werden dann ins Sprint Backlog aufgenommen. Danach werden die User Stories in Aufgaben unterteilt, die innerhalb eines Tages abgeschlossen werden können. Das Entwicklungsteam entscheidet eigenständig, wer welche Aufgaben übernimmt. Um den Entwicklungsfortschritt nachvollziehen zu können, ist es wichtig, die Aufgaben und die User Stories mit Statusangaben zu versehen. Sobald alle Aufgaben zur Umsetzung einer User Story abgeschlossen sind und die Definition of Done erfüllt ist, gilt die User Story als umgesetzt. Für die Visualisierung eignet sich der Einsatz von Taskboards.

Definition Product Backlog: Das Product Backlog ist die primäre Sammlung von Aufgaben, funktionalen Anforderungen und Features, die bearbeitet werden müssen. In einigen Organisationen wird es auch als Domain Backlog bezeichnet, insbesondere wenn sie in verschiedenen Bereichen tätig sind und es sinnvoll ist, die Elemente pro Domäne zu organisieren. Vier wesentliche Merkmale zeichnen ein Product Backlog aus: Die Priorisierung der Backlog-Items spielt eine entscheidende Rolle, da nicht alle Anforderungen gleich wichtig sind, denselben Kundennutzen bieten oder denselben Aufwand erfordern. In Scrum übernimmt der Product Owner, idealerweise in enger Zusammenarbeit mit den Entwicklern, die Priorisierung. Während Stakeholder oft den Geschäftswert im Blick haben, konzentriert sich das Team auf den Entwicklungsaufwand und die technisch sinnvolle Reihenfolge der Umsetzung. Für die Aufwandsschätzung sind relative Werte mit Fibonacci-Zahlen nützlich, da sie Aufwände sowohl im kleinen als auch im großen Umfang gut abbilden können. Es ist wichtig, die Priorisierung regelmäßig zu aktualisieren, da neue Anforderungen oder die Verfeinerung bestehender Items ständig neue Erkenntnisse liefern. Das Product Backlog ist daher dynamisch und unterscheidet sich erheblich von traditionellen Lasten- oder Pflichtenheften. Release Backlog: In agilen Projekten und Produktentwicklungen werden Releases und Iterationen genutzt. Da Iterationen in Scrum normalerweise zwischen einer Woche und einem Monat dauern, werden sie Sprints genannt und haben stets dieselbe Dauer innerhalb eines Projekts. Eine bestimmte Anzahl von Sprints bildet ein Release. Jeder Organisation obliegt es, die genaue Dauer und Anzahl zu definieren. Zum Beispiel könnte nach fünf Sprints das erste Release erfolgen, gefolgt von einem weiteren Release nach fünf weiteren Sprints. Bei mehreren Teams und parallelen Sprints sollten die Intervalle synchronisiert werden. Anforderungen werden basierend auf ihrer Priorität den jeweiligen Releases zugeordnet. Der Product Owner legt Prioritätsgrenzen fest, um die Anforderungen auf verschiedene Releases zu verteilen. Sprint Backlog: Im Sprint wird ein funktionierendes, potenziell auslieferbares Zwischenprodukt, ein sogenanntes Increment, entwickelt. Beim Sprint Planning Meeting entscheiden das Team, welche Items aus dem Product oder Release Backlog in das Sprint Backlog aufgenommen werden sollen. Das Team wählt die am höchsten priorisierten Items aus und schätzt, welche innerhalb des nächsten Intervalls realisierbar sind. Diese Items werden im Sprint Backlog festgehalten und in kleinere Aufgaben unterteilt, die innerhalb eines Tages erledigt werden können. Zur Überwachung des Fortschritts ist es wichtig, den Aufgaben und User Storys Zustände zuzuordnen. Sobald alle Aufgaben für eine User Story abgeschlossen sind und die Definition of Done erfüllt ist, gilt diese als realisiert. Taskboards sind nützlich für die Visualisierung dieses Prozesses. Priorisierung von Backlog Items: Die Priorisierung von Backlog-Items ist entscheidend für den Erfolg der Software- und Produktentwicklung, da sie sicherstellt, dass die wichtigsten und relevantesten Anforderungen umgesetzt werden. Es gibt verschiedene Methoden zur Priorisierung, die sich auch kombinieren lassen: Weitere Methoden sind beispielsweise Rocks, Pebbles & Sand, Walking Skeleton oder Theme Scoring. Jede Organisation sollte die für sie passende Methode wählen. Tipps für die Arbeit mit Backlogs: Backlogs sind dynamisch und erfordern regelmäßige Pflege, bekannt als Refinement oder Grooming, um Transparenz und Flexibilität zu gewährleisten. Die 5S Technik (Sort, Set in Order, Shine, Standardize, Sustain) kann helfen, Backlogs effektiv zu organisieren und zu pflegen. User Story Mappings sind eine nützliche Ergänzung bei der Arbeit mit Backlogs. Es ist wichtig, den Umfang des Backlogs im Blick zu behalten und gegebenenfalls überflüssige Items zu entfernen. Bei der Priorisierung sollten absolute Werte pro Item definiert werden, um Dopplungen zu vermeiden. Laut Scrum Guide ist der Product Owner für die Sortierung der Product Backlog Items zuständig, kann diese Aufgabe jedoch auch delegieren, sofern er die Verantwortung behält. Die Sortierung im Team fördert die Transparenz und das Verständnis der Beteiligten.

Scrum Master – Verantwortlicher für die Implementierung von Scrum Der Scrum Master trägt die Verantwortung für die Implementierung von Scrum, wie es im Scrum Guide beschrieben ist. Als Teil des Scrum-Teams fungiert er als Facilitator und übernimmt Rollen wie Moderator, Vermittler, Prozessbegleiter, Unterstützer und Coach. Einfach ausgedrückt unterstützt er die Entwickler und den Product Owner – die beiden anderen Rollen im Scrum-Framework – dabei, ihre Ziele gemeinsam zu erreichen, indem er die Zusammenarbeit erleichtert. Zusätzlich wirkt er auch innerhalb der Organisation. Die Aufgaben des Scrum Masters (oft als SM abgekürzt) sind anspruchsvoll: Er schafft eine vertrauensvolle, offene Arbeitsatmosphäre und fördert die Kommunikation und Interaktion im Team. Seine Haltung basiert auf den Prinzipien des agilen Manifests, und er lebt die Werte des Frameworks vor. Er ist ein genauer Beobachter, der unproduktives Verhalten anspricht und angemessenes Feedback gibt. Aufgaben des Scrum Masters: Entgegen dem verbreiteten Missverständnis, dass der Scrum Master lediglich Meetings moderiert, betont der Scrum Guide 2020 seine Verantwortung gegenüber dem Product Owner, den Entwicklern und der Organisation. Mit einer positiven Einstellung übernimmt er folgende Aufgaben: Missverständnisse über die Rolle des Scrum Masters: Es gibt immer wieder Diskussionen über die Rolle des SM, besonders wichtig für Organisationen, die mit agilen Methoden beginnen oder ihre Teamdynamik entwickeln. Der Scrum Master ist ein Facilitator und Servant Leader. Als Facilitator arbeitet er im System an der Systemoptimierung und schützt das Team vor äußeren Einflüssen. Als Servant Leader unterstützt er die Beteiligten situativ und bietet Hilfe zur Selbsthilfe, ohne Abhängigkeiten zu schaffen. Diese Aufgaben erfüllt er entschlossen und mutig, was ihn auf eine Art „heldenhaft“ macht.

Product Owner Definition Scrum definiert drei Accountabilitys bzw. Verantwortlichkeiten: Der Product Owner – ins Deutsche übersetzt: der Produkteigentümer – ist für die Wertsteigerung des Produkts im Entwicklungsprozess zuständig und verantwortet das Product Backlog und Product Goal. In der Praxis ist er häufig derjenige, der die fachliche Sicht vertritt und als Ansprechpartner für die Developer agiert. Er formuliert u.a. Anforderungen an die gewünschte Lösung und beurteilt Entwicklungsfortschritte anhand von Funktionalität, Usability und Qualität. Definition des Product Owners Scrum definiert drei zentrale Rollen: den Scrum Master, die Entwickler und den Product Owner. Der Product Owner, auf Deutsch als Produkteigentümer bekannt, ist für die Wertsteigerung des Produkts während des Entwicklungsprozesses verantwortlich und verwaltet das Product Backlog sowie das Produktziel. In der Praxis übernimmt er häufig die fachliche Perspektive und fungiert als Hauptansprechpartner für die Entwickler. Er formuliert Anforderungen an die Lösung und bewertet den Entwicklungsfortschritt basierend auf Funktionalität, Benutzerfreundlichkeit und Qualität. Aufgaben des Product Owners Laut dem aktuellen Scrum Guide 2020 hat der Product Owner, oft als PO abgekürzt, folgende Aufgaben: Der Scrum Guide ergänzt, dass der PO diese Aufgaben delegieren darf, aber dennoch die Verantwortung trägt. Er ist dafür zuständig, den Wert des Produkts durch die Arbeit des Scrum Teams zu maximieren und die Interessen der Stakeholder zu vertreten. Änderungen am Product Backlog erfolgen nur auf seine Überzeugung hin. Der PO klärt den Umfang eines Sprints und kann ihn bei neuen Erkenntnissen neu verhandeln. Er hat die Autorität, einen Sprint abzubrechen. Zudem sorgt er dafür, dass die Teilnehmer des Sprint Plannings vorbereitet sind, und schlägt vor, wie das Produkt im aktuellen Sprint an Wert gewinnen könnte. Falls er am Daily Scrum teilnimmt, agiert er als Teil der Entwickler. Bei Bedarf unterstützt er die Entwickler beim Backlog Refinement. Der Product Owner ist immer eine Einzelperson und kein Komitee. Für den Erfolg des Product Owners ist es wichtig, dass die gesamte Organisation seine Entscheidungen respektiert, die durch die Inhalte und Reihenfolge des Product Backlogs sowie die Inkremente am Ende der Sprints sichtbar sind. Zusätzliche Aufgaben in der Praxis Neben den Aufgaben aus dem Scrum Guide übernimmt der Product Owner in der Praxis häufig weitere Tätigkeiten, wie: Oftmals ist der Product Owner auch der fachliche Ansprechpartner für den Scrum Master und die Entwickler und sollte für Fragen regelmäßig und kurzfristig zur Verfügung stehen. In der Praxis gibt es Diskussionen darüber, ob der PO die Gesamtverantwortung für das Produkt trägt, einschließlich Marketing, Verkauf, Entwicklung, Betrieb und Support. Es ist wichtig, den spezifischen Kontext der Organisation zu berücksichtigen und ein gemeinsames Verständnis für Rollen und Verantwortlichkeiten zu entwickeln. Was ist ein Product Owner nicht? Ein Product Owner ist nicht: Der Scrum Master sollte bei Bedarf eingreifen und auf die Einhaltung der Scrum-Verantwortlichkeiten achten. Eine Doppelfunktion als Scrum Master oder Entwickler sollte vermieden werden, um Konflikte zu verhindern. Es wird oft fälschlicherweise angenommen, dass der PO für die Formulierung von User Stories verantwortlich ist. Dies hängt jedoch vom Kontext ab, und die Hauptsache ist, dass sich Nutzer und Entwickler verstehen. Der PO sollte hierzu seinen Beitrag leisten, wie es die Umstände erfordern. Product Owner Zertifizierung Es gibt zwei anerkannte Zertifikate für Product Owner: Der Unterschied liegt in der Zertifizierung: Für das CSPO-Zertifikat ist eine Schulung mit anschließendem Test erforderlich, während das PSPO-Zertifikat nur einen Test erfordert. Nach dem CSPO oder PSPO gibt es weitere Zertifizierungsstufen, wie den Advanced Certified Scrum Product Owner (A-CSPO) und den Professional Scrum Product Owner II + III. Alle Zertifikate der Scrum Alliance müssen alle zwei Jahre erneuert werden, während Scrum.org keine solche Forderung stellt. Die Aufgaben des Product Owners Nach dem aktuellen Scrum Guide 2020 hat der Product Owner – oftmals auch einfach als PO abgekürzt – folgende vier Aufgaben: Ergänzend führt der Scrum Guide aus, dass der PO Damit der Product Owner erfolgreich arbeiten kann, muss – laut Scrum Guide – die gesamte Organisation seine Entscheidungen respektieren, die durch die Inhalte und Reihenfolge der Product Backlog Items, sowie die Inkremente am Ende der Sprints einsehbar sind. Weitere Tätigkeiten in der Praxis Neben den Aufgaben aus dem Scrum Guide gibt es in der Praxis Tätigkeiten, die häufig in das Betätigungsfeld des Product Owners fallen, wie bspw. Darüber hinaus ist es oftmals fachlicher Ansprechpartner des Scrum Masters und der Entwickler und sollte regelmäßig und idealerweise auch kurzfristig für Fragen zur Verfügung stehen. Immer wieder gibt es in der Praxis Diskussionen darüber, ob der PO die Gesamtverantwortung für das Produkt trägt und für den Erfolg des Produkts und in letzter Konsequenz auch für Marketing, Verkauf, Entwicklung, Betrieb und Support verantwortlich ist. Es empfiehlt sich, den konkreten Kontext einer Organisation zu beachten und ein gemeinsames Verständnis zu den Verantwortlichkeiten, Aufgaben und Rollen zu finden, zumal es in vielen Organisationen bereits ein Erfolg wäre, wenn Vertreter der genannten Bereiche an dem Sprint Review teilnehmen. Was ist ein Product Owner NICHT? Es ist wichtig zu verstehen, was ein Product Owner NICHT ist: Er kann, muss aber kein Manager in der Linienorganisation sein; wichtig ist die Fähigkeit die Stakeholder fachlich kompetent zu vertreten. Grundsätzlich sollte der Scrum Master bei Bedarf eingreifen und auf die Einhaltung der im Scrum Guide definierten Verantwortlichkeiten achten. Um mögliche Konflikte zu vermeiden, sollte es keine Doppelfunktion als Scrum Master oder Entwickler geben. Immer wieder wird behauptet, dass der PO als Vertreter der Nutzer für die Formulierung von User Storys verantwortlich ist. Dies ist nicht der Fall. Abgesehen davon, dass es kontextabhängig ist, welche Elemente im Product Backlog verwaltet werden, ist es letztendlich sekundär, wer diese formuliert. Die Verantwortung über das Product Backlog und das Product Goal obliegt dem Product Owner, aber wichtig ist vor allen, dass sich Nutzer und Entwickler verstehen. Dazu muss er seinen Beitrag leisten. Wie er dies tut, hängt von der Situation ab. Und wie gut er es tut, lässt sich im Zuge von Retrospektiven thematisieren. Product Owner Zertifizierung Es gibt zwei anerkannte Product Owner Zertifikate: Genau wie bei der Unterscheidung zwischen dem Certified Scrum Master (CSM) und dem Professional Scrum Master (PSM) findet sich der wesentliche Unterschied zwischen dem CSPO und dem PSPO in der Art der Zertifizierung. Zur Erlangung des CSPO-Zertifikat…

Scrum Retrospektive Definition Eine Retrospektive ist ein Rückblick. Als Begriff in der Kunst beschreibt er die Auseinandersetzung mit Werken eines Künstlers und/oder einer Epoche. In Scrum ist eine Retrospektive ein regelmäßiges Event, zu dem sich das Scrum Team trifft, um die jüngere Vergangenheit – also den zurückliegenden Sprint – zu beleuchten und dadurch die zukünftige Zusammenarbeit im Team zu verbessern. Es ist ein Meeting, bei dem reflektiert werden. Der Austausch miteinander bietet dabei Chancen sowohl für das Team als Ganzes als auch für jeden einzelnen Teilnehmer. Phasen einer Retrospektive Eine Retrospektive – gerne  auch in Kurzform Retro genannt – läuft in der Regeln in fünf Phasen ab: Beim Ankommen geht es darum, für die Teilnehmer eine angenehme und passende Atmosphäre für den Austausch untereinander zu schaffen, bei dem auch kritische Aspekte der Zusammenarbeit thematisiert werden können. Wichtig ist dabei die Annahme, dass jeder im Sprint involvierte Mitarbeiter die bestmögliche Arbeit geleistet hat, die er leisten konnte. Gemeinsam wird zudem das Ziel der Retrospektive vereinbart und der Scrum Master beschreibt kurz die Methode, die er für den Austausch nutzen möchte. Beim Sammeln von Informationen – bspw. anhand von definierten Fragen – geht es darum, die Dinge zu benennen, die im zurückliegenden Sprint gut oder weniger gut waren. Bei der Entwicklung von Erkenntnissen sollen Einsichten gewonnen werden. Einsichten über Gründe und Probleme, Einsichten über Positives und Möglichkeiten. Es geht darum, nicht nur Maßnahmen für Symptome zu identifizieren, sondern tatsächliche Ursachen zu erkennen, um dafür Maßnahmen festzulegen. Sind Probleme und Chancen identifiziert, werden gemeinsam Maßnahmen – konkrete und sinnvolle Schritte – für den nächsten Sprint vereinbart. Zum Abschluss der Retro lassen die Teilnehmer den Austausch untereinander Revue passieren: Was lief gut, was könnte beim nächsten Mal besser laufen? Der Moderator nutzt das Feedback für die Vorbereitung der nächsten und beendet die aktuelle Retrospektive. Ziele der Retrospektive Die Sprint Retrospektive – so der offizielle Name aus dem Scrum Guide – verfolgt verschiedene Ziele: Die Verbesserung der Zusammenarbeit im Team und somit um die Verbesserung von Abläufen und Inhalten steht im Mittelpunkt des Austausches. Es geht auch um das Zusammenspiel zwischen einzelnen Entwicklern, um das Wirken des Scrum Masters und die Kommunikation mit dem Product Owner. Damit ist die Retrospektive wichtiger Teil eines kontinuierlichen Verbesserungsprozesses (KVP). Darüber hinaus sind auch die Festlegung von Maßnahmen, von Dos und Don’ts, basierend auf  den gemeinsam gewonnen Erkenntnissen, sowie die Überprüfung der vereinbarten Maßnahmen der vergangenen Retrospektive wichtige Ziele. Und zu guter Letzt versucht die Retro auch Raum und Gelegenheit für offenes Feedback im Team zu schaffen, was idealerweise zur Vermeidung von Frust und der Beseitigung von Missverständnissen beiträgt.  Arten einer Scrum Retrospektive Es gibt viele verschiedene Arten von Retros: Es gibt noch viele weitere Methoden und Möglichkeiten, um die Eindrücke und Meinungen der Teammitglieder in Erfahrung zu bringen. Es obliegt dem Scrum Master, hier einerseits neue Methoden einzubringen, andererseits an bewährten Techniken festzuhalten. Eine Retrospektive darf trotz aller Ernsthaftigkeit auch Spaß machen. Tipps für Retrospektiven Es gibt eine Reihe von Tipps zur Durchführung von Retros: Und last but not least: Freuen Sie sich auf den Austausch, denn er legt die Basis für eine verbesserte Zusammenarbeit. Feedback ist ein Geschenk. Es ist eine Möglichkeit, sich gegenseitig zu unterstützen, Probleme anzusprechen und zu lösen. Es ist die Basis für eine kontinuierliche Verbesserung.

Definition des Sprint Reviews Das Sprint Review ist ein Treffen am Ende eines Sprints, bei dem die erreichte Arbeit im Hinblick auf das Sprint-Ziel bewertet wird. Laut Scrum Guide dient das Sprint Review dazu, das Ergebnis des Sprints zu überprüfen und zukünftige Anpassungen zu planen. Das Scrum-Team präsentiert seine Arbeitsergebnisse wichtigen Stakeholdern und diskutiert den Fortschritt in Richtung des Produktziels. Während des Reviews bewerten das Scrum-Team und die Stakeholder, was im Sprint erreicht wurde und welche Änderungen in der Umgebung eingetreten sind. Auf Basis dieser Informationen wird gemeinsam entschieden, welche nächsten Schritte unternommen werden sollten. Das Hauptaugenmerk liegt darauf, das Sprint-Ziel zu erreichen, welches im Sprint Planning festgelegt wurde. Nur die Items, die gemäß der Definition of Done abgeschlossen wurden, werden im Review präsentiert. Teilnehmer des Sprint Reviews Am Sprint Review nehmen das gesamte Scrum-Team – bestehend aus Entwicklern, Scrum Master und Product Owner – sowie idealerweise auch Stakeholder wie Anwender, Manager und Vertreter aus Marketing, Vertrieb oder IT teil. Es ist natürlich nicht möglich, alle Stakeholder einzubeziehen; Wettbewerber sind zwar von den Ergebnissen betroffen, tragen aber nicht zur Verbesserung des Produkts bei. Im Vordergrund steht der Austausch zwischen den Entwicklern und dem Product Owner als Stellvertreter der Stakeholder. Falls der Product Owner nicht alle fachlichen Aspekte abdecken kann, sollte der Auftraggeber oder ein entsprechender Stellvertreter teilnehmen. Andernfalls wird die Abnahme bestimmter User Storys verschoben. Bei komplexen Storys sollte der Auftraggeber schon vor dem Review einbezogen werden, um umfangreiche und möglicherweise scheiternde Abnahmen zu vermeiden. Das Sprint Review als Scrum-Event Scrum definiert verschiedene Events, darunter das Sprint Planning, der Sprint, das Daily Scrum, die Retrospektive und das Sprint Review. Das Backlog Refinement wird kontinuierlich durchgeführt, ist jedoch kein offizielles Scrum-Event. Diese Vielzahl an Events unterstreicht die Bedeutung der Kommunikation im agilen Kontext. Jedes Event hat seine eigenen Ziele. Das Sprint Review dient dazu, Feedback von den Stakeholdern zu erhalten, welches in die weitere Entwicklung einfließt. Ablauf des Sprint Reviews Nach einer kurzen Begrüßung durch den Product Owner und der Vorstellung der Teilnehmer, falls nötig, werden die Regeln erläutert. Eine „goldene Regel“ wie in der Sprint Retrospektive kann hilfreich sein. Bevor das Team die umgesetzten User Storys präsentiert, stellt der Product Owner eine Liste bereit, die zeigt, welche Items abgeschlossen sind und präsentiert werden. Diese Liste sollte im Vorfeld zwischen Product Owner und Entwicklern abgestimmt werden, da sie die Reihenfolge der Präsentation bestimmt. In einigen Organisationen wird diese Liste bereits mit der Einladung zum Review verschickt, um Stakeholdern die Teilnahmeentscheidung zu erleichtern. Das Herzstück des Sprint Reviews ist die Präsentation der neuen Funktionalitäten, idealerweise durch die Entwickler selbst. Feedback wird eingeholt und User Storys werden abgenommen oder eben nicht. Vor der Diskussion über kommende Backlog Items kann der Scrum Master die größten Herausforderungen des Sprints ansprechen. Abschluss des Reviews bildet ein Dank an die Entwickler und die Bestimmung des nächsten Sprint Review Termins.