Kapitel 03
Die Events und Artefakte
Allgemeines
- Zu den Events gehören Sprint, Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospektive
- Die Artefakte stellen transparent jene Informationen zur Verfügung, die Voraussetzung für eine gemeinsame Inspektion und Adaption sind.
- Für jedes Artefakt ist ein Commitment festgelegt, damit der Fortschritt gemessen werden kann
- Das Product Backlog wird am Produktziel gemessen, das Sprint Backlog am Sprinziel und das Increment an der Definition of Done
Product Backlog
Das Product Backlog ist die laufend aktualisierte, priorisierte Liste der Anforderungen für die Umsetzung des Produkts und das zentrale gemeinsame Artefakt von Product Owner, Auftraggeber und Entwicklern.
Ziele
Ein einziges, zentrales Planungs- und Abwicklungsartefakt für alle Stakeholder und alle Änderungen am Produkt zu führen. Entwickelt sich laufend mit dem Produkt weiter.
Abbildung der gemeinsamen Vorstellungen, wie das Produkt gestaltet und welche Funktionen es erfüllen soll.
Transparente Fortschrittskontrolle.
Aufbau
Enthält alle Features, Funktionalitäten, Verbesserungen und Fehlerbehebungen, die die Änderungen des Produkts in zukünftigen Releases beschreiben.
Die Einträge im Product Backlog sind eindeutig priorisiert.
Hoch priorisierte Backlog Items sind konkreter und detaillierter beschrieben als niedrig priorisierte Einträge.
Die Backlog Items, die im nächsten Sprint umgesetzt werden sollen, sind
ausreichend klar beschrieben und
klein genug, dass sie in einem Sprint fertiggestellt werden können. Das ist die Voraussetzung für eine präzise Schätzung im Refinement
Backlog Items
In Scrum werden Product Backlogs meistens mit User Stories (US) geführt, weil US beschreiben, Wer Welche Funktionalität benötigt und vor allem Warum und was am besten die inkrementelle Lieferung von Business Value unterstützt.
Damit eine User Story in einem Sprint umgesetzt werden kann, werden Funktionalitäten so aufgeteilt (Story Splitting), dass sie die INVEST Kriterien erfüllen.
Die Entwickler unterstützen den Product Owner im Rahmen des Refinements bei der Aufteilung.
Typische Aufteilungskriterien sind Workflowschritte, Geschäftsregeln, Sonderfälle, Schnittstellen, Daten etc.
Management
Der Product Owner:
ist alleine verantwortlich für das Backlog Management.
stimmt den Funktionsumfang und die Prioritäten mit dem Auftraggeber ab und holt das Feedback der Entwickler ein.
ist verantwortlich für den Inhalt und den Rang der Product Backlog Items.
präzisiert die Anforderungen und geht gegebenenfalls Kompromisse ein, um den Aufwand innerhalb der Rahmenbedingungen zu halten.
kommuniziert in jedem Sprint den Fortschritt an alle Stakeholder.
Die Entwickler:
überlegen sich im Rahmen des Refinements Vorschläge zur Umsetzung der beschriebenen Anforderungen.
sind alleine verantwortlich für die Schätzung.
Tipps
Was macht eine gute User Story aus?
ein guter Titel mit hohem Wiedererkennungswert und klarer Abgrenzung von anderen User Stories
präzise, einheitliche Terminologie und kurze aber aussagekräftige, direkte und benutzerzentrierte Beschreibung
einheitlich strukturierte Beschreibung, die bestmöglich auf die Domäne eingeht
end-to-end Umsetzbarkeit, damit alle Stakeholder das Ergebnis der Umsetzung nachvollziehen können
Gut durchdachtes Story Splitting trägt zu einer besseren Früherkennung von Problemfeldern bei. Mögliche Überlegungen, die dabei angestellt werden können sind z.B. riskante Anforderungen zuerst zu klären oder den Hauptanwendungsfall, der die meisten Benutzer/Daten betrifft, zuerst umzusetzen.
Eine Visualisierung der Features und Aufgaben hilft dem Team den Überblick zu bewahren.
Wichtige Begriffe
Sprint Backlog:
Das Sprint Backlog umfasst die Liste jener Backlog Items, zu deren Implementierung sich die Entwickler im aktuellen Sprint verpflichtet haben, sowie den Arbeitsplan und das Sprintziel.
Das Sprint Backlog bildet die gesamte von den Entwicklern identifizierte Arbeit ab, um das vereinbarte Produkt-Inkrement zu liefern.
Das Sprint Backlog enthält auch die Prozessverbesserungen, die in der letzten Retrospektive vereinbart wurden.
Das Sprint Backlog ist so aufgebaut, dass das Scrum-Team während des Sprints im Daily Scrum den Fortschritt erkennen kann.
INVEST Kriterien:
Eine gute User Story erfüllt die INVEST KriterienIndependent – kann unabhängig von anderen US umgesetzt werden
Negotiable – Priorität und Details können von den Entwicklern beeinflusst werden
Valuable – der Business Value ist bekannt und alle verstehen ihn
Estimable – ausreichend klar für die Entwickler für die Schätzung
Small – kann innerhalb eines Sprints umgesetzt werden
- Testable – Ohne Testnachweis kann eine US nicht abgeschlossen werden
Product Backlog Refinement
Das Refinement ist der laufende Vorgang, in dem der Product Owner gemeinsam mit den Entwicklern die Inhalte der nächsten Sprints vorbereitet. Das Refinement ist kein Scrum Event.
Management
Klarheit für die nächsten Backlog Items schaffen (1-2 Sprints)
Ausblick auf die weitere mittelfristige Entwicklung geben (3-4 Sprints)
Gemeinsames Verständnis der nächsten umzusetzenden Funktionalitäten herstellen
Grundlage für fokussiertes Arbeiten während der kommenden Sprints schaffen
Vorbereitung
Dauer: nach Bedarf
das Refinement nimmt ca. 10% der Kapazität der Entwickler in Anspruch. Am Anfang eines Projekts oft mehr, am Ende weniger.
Der Product Owner verfeinert das Product Backlog, indem er
die Probleme beschreibt, die gelöst werden sollen und welchen Wert die Lösung des Problems bringt.
die Prioritäten mit dem Auftraggeber bespricht und Features in Backlog Items zerlegt, die in einem Sprint umgesetzt werden können.
Die Entwickler
erarbeiten Optionen für die Lösung der Probleme, die der Product Owner beschrieben hat.
analysieren komplexe oder vage Anforderungen aus dem letzten Refinement und setzen vereinbarte Spikes für Backlog Items um, bei denen technische Fragen offen sind.
Facilitation
Der Product Owner
das Refinement nimmt ca. 10% der Kapazität der Entwickler in Anspruch. Am Anfang eines Projekts oft mehr, am Ende weniger.
gibt einen Überblick über die Backlog Items, die im Refinement verfeinert werden sollen.
präsentiert die Problemstellungen des Auftraggebers inklusive bereits beantworteter Fragen aus dem letzten Refinement.
Die Entwickler
diskutieren mögliche technische Lösungen, Risiken und Annahmen.
schätzen die Backlog Items hinsichtlich Komplexität ein (in Storypoints).
Der Scrum Master
unterstützt das Team im Arbeitsprozess, z.b. Agenda, Zeitmanagement, Schätzung, Visualisierung etc.
Ergebnis
Das Product Backlog ist aktualisiert und die Priorisierung angepasst.
Backlog Items für den nächsten Sprint sind umsetzungsbereit.
Annahmen und Entscheidungen sind dokumentiert.
Offene Fragen werden zur weiteren Klärung mitgenommen.
Tipps
Betrachtet werden die nächsten 1-3 Sprints. Nicht mehr, da sich die Anforderungen noch ändern können, und nicht weniger, damit sich eventuelle offene Fragen rechtzeitig klären lassen.
In die konkrete Priorisierung sollten die Fragen oder Risiken, die die Entwickler artikulieren, einbezogen werden.
Die konkrete Aufteilung der Backlog Items erfolgt am besten gemeinsam im Scrum-Team, auf Basis eines vorbereiteten Vorschlags des Product Owners.
Gute Abgrenzung der Stories stellt sicher, dass der Fokus des Teams optimal ist und es gemeinsame Erwartungen an den Sprint Review gibt.
Die Anmerkungen und Konkretisierungen sollten direkt im Refinement in die gemeinsame Überarbeitung der Backlog Items einfließen. Dies erhöht die Transparenz und reduziert die Nachfragen während der weiteren Umsetzung.
Wichtige Begriffe
Spike: Ein Spike ist ein Backlog Item, der aufgrund der unzureichenden Information meist als Timebox angesetzt wird. Er dient der Analyse von Anforderungen, die noch zu vage für eine Schätzung sind. Der Spike ist die Grundlage weiterer Analysen im Refinement.
PoC (Proof of Concept): Ein PoC kann eingesetzt werden, um Risiken richtig einzuschätzen oder eine technische Lösung zu evaluieren. Der PoC wird wie ein normales Backlog Item funktional abgegrenzt.
DoR: In der Praxis wird die Definition of Ready oft als Hilfsmittel eingesetzt, um die Vereinbarung zwischen Team und Product Owner zu dokumentieren, welche Kriterien ein Backlog Item erfüllen muss, damit es in das Sprint Backlog aufgenommen und in weiterer Folge umgesetzt werden kann. Besonders in stark reglementierten Umfeldern, kann das bei der Zusammenarbeit helfen. Die DoR sollte jedoch nicht vorgeschoben werden um inhaltliche Diskussionen zu vermeiden.
Sprint Planning
Der Product Owner und die Entwickler entscheiden gemeinsam, welche Funktionalitäten im folgenden Sprint umgesetzt werden und vereinbaren das Sprintziel.
Ziel
Ziel und Scope für den Sprint vereinbaren.
Erwartungen an die Präsentation des Sprintergebnisses im Review klären.
Aufgaben planen.
Vorbereitung
Dauer: Timebox
1 bis maximal 8 Stunden, je nach Sprintdauer
Der Scrum Master organisiert das Meeting und
sorgt dafür, dass die Arbeitsmittel vorhanden sind (Taskboard, Post-Its…).
visualisiert die Kapazität für die Entwicklung.
macht die bisherige Leistung transparent (v.a. Velocity).
Der Product Owner
bereitet ein priorisiertes Product Backlog vor.
kontrolliert, ob die Backlog Items umsetzungsbereit sind.
Facilitation
Der Product Owner macht einen Vorschlag wie der kommende Sprint zur Erreichung des Produktziels beitragen soll.
Die Entwickler und der Product Owner entscheiden gemeinsam, welche Backlog Items konkret in das Sprint Backlog aufgenommen werden.
Die Entwickler entscheiden, wie die geplanten Backlog Items umgesetzt werden sollen. Dabei orientieren sie sich an der DoD.
Das Sprint Planning endet, wenn die Kapazität für den kommenden Sprint erschöpft ist.
Backlog Items mit relevanten Unklarheiten können weder geschätzt noch geplant werden und müssen daher im Rahmen des Refinements für einen der nächsten Sprints spezifiziert werden.
Der Scrum Master
unterstützt den Prozess als Moderator und stellt sicher, dass alle Teammitglieder sich zum Sprintziel bekennen.
moderiert und sorgt für die Einhaltung der Time Box.
Ergebnis
Das Sprint Backlog ist festgelegt und priorisiert, und das Scrum-Team verpflichtet sich zur Lieferung am Ende des Sprints (Forecast / Prognose).
Das Sprintziel ist vereinbart und wird gut sichtbar im Team-Raum oder Workspace dokumentiert.
Die Erwartungen an das Ergebnis, das beim Review präsentiert werden wird, sind allen Teilnehmenden klar.
Tipps
Gute Vorbereitung unterstützt die Erreichung des Sprintziels. Das Refinement spielt dabei eine zentrale Rolle.
Fix eingeplante Terminserien unterstützen den Flow des Teams.
Erfahrungsgemäß sind bei einem Team mit 3-4 Entwicklern für das Sprint Planning für einen 2 Wochen Sprint etwa 1-3 Stunden einzuplanen. Die Dauer der Timebox ändert sich oft mit der Dauer der Zusammenarbeit.
Bei „ungewöhnlichen“ Backlog Items, oder Anwendungen ohne Benutzeroberfläche ist es sinnvoll, bereits im Sprint Planning zu vereinbaren, wie das Ergebnis im Review für alle sichtbar gemacht wird.
Die Prognosen der Entwickler werden besser, wenn sie ihre Kapazität und die durchschnittliche Velocity aus der Vergangenheit kennen und die DoD bewußt in ihre Planung mit einbeziehen.
Die Items im Sprint Backlog werden von den Entwicklern gemeinsam übernommen – nicht von einzelnen Teammitgliedern.
Die meisten Teams planen die Umsetzung im Sprint anhand von Tasks:
Tasks sollten sich an einem Tag vollständig umsetzen lassen.
als Unterstützung werden die Tasks häufig so angelegt, dass sie die Erfüllung der DoD sicherstellen.
Wichtige Begriffe
Sprintziel: Das Sprintziel beschreibt welchen Beitrag der Sprint zur Erreichung des Produktziels leisten wird. „Alle User Stories abschließen“ ist KEIN geeignetes Sprintziel. Das Sprintziel kann benutzerorientiert sein (z.B. Erste Version des Shops für Trial-Kunden) oder sich aus der Retrospektive ergeben (z.B. das Qualitätsziel “alle automatisierten Tests sollen wieder grün sein”). Das Sprintziel hilft den Entwicklern an einem Strang zu ziehen und während des Sprints Entscheidungen zu treffen, die die Erreichung der vereinbarten Ziele unterstützen.
DoD: In der Definition of Done legt das Scrum-Team gemeinsam fest, welche Kriterien erfüllt sein müssen, damit ein Backlog Item als „done“ bezeichnet werden kann. Die DoD ist Grundlage für die Einschätzung, wie viele Backlog Items die Entwickler in ein Sprint Backlog aufnehmen und in einem Sprint umsetzen kann. Die Anpassung der DoD im Zeitverlauf ist ein Element von „Inspect and Adapt“.
Velocity: die Velocity gibt die Leistungsfähigkeit des Teams an. Sie wird nach jedem Sprint festgestellt, und der Durchschnitt für die Prognose zukünftiger Sprints verwendet.
Daily Scrum
Das DSM (Daily Scrum Meeting) unterstützt das Selbstmanagement und die Synchronisation der Entwickler während des Sprints. Es ist eine tägliche Timebox von 15 Minuten.
Ziel
Synchronisation der Entwickler.
Planung für die nächsten 24h.
Hindernisse für die Erreichung des Sprintziels identifizieren.
Erreichung des Sprintziels verfolgen.
Vorbereitung
Dauer: Timebox
maximal 15 Minuten an jedem Tag des Sprints zur selben Zeit am selben Ort.
Jedes Teammitglied reflektiert seinen Beitrag zur Erreichung des Sprintziels und überlegt sich einen durchführbaren Plan für den kommenden Arbeitstag.
Der Scrum Master
bietet den Rahmen: Terminserie, Raum, großer Bildschirm oder Whiteboard für Taskboard.
hat einen Überblick über das Taskboard und kann mögliche Fehlentwicklungen hinterfragen.
Facilitation
Das DSM gehört den Entwicklern
jedes Teammitglied beteiligt sich durch aktives Zuhören und transparente Offenlegung des Status der selbst übernommenen Tasks.
Der Scrum Master
unterstützt am Anfang, bis das Scrum-Team Timebox selbständig einhalten und die Transparenz der Zielerreichung sicherstellen kann.
hinterfragt, wenn das Taskboard Fehlentwicklungen anzeigt.
stellt sicher, dass eventuell Anwesende, die nicht zum Scrum-Team gehören, das Meeting nicht stören.
Ergebnis
-
Das Team geht mit einem angepassten Plan zur bestmöglichen Verfolgung des Sprintziels in die nächsten 24 Stunden.
Tipps
Der Ablauf des DSM kann unterschiedlich sein und wird von den Entwicklern festgelegt. So kann z.B. nach Personen oder nach Backlog Items in der Reihenfolge der Priorisierung vorgegangen werden.
Die Vereinbarung von Fragen hilft vielen Teams bei der strukturierten Abwicklung des DSM. Beispiele: “Was werde ich heute zum Sprintziel beitragen?” oder „Wem habe ich gestern geholfen das Sprintziel zu erreichen?“
Am Anfang gibt es oft viele offene Fragen und die Timebox kann nicht immer eingehalten werden. Es empfiehlt sich, das DSM konsequent in der Timebox zu halten und alle offenen Fragen direkt im Anschluss, aber formal voneinander getrennt zu diskutieren.
Wenn der Product Owner teilnimmt – das Einverständnis der Entwickler vorausgesetzt – und ebenfalls über seine Fortschritte berichtet, trägt dies zur Transparenz und zum besseren Verständnis der Ziele im Team bei.
Während des Sprints akzeptieren die Entwickler keine Änderungen des Scope, die die Erreichung des Sprintziels gefährden und keine Abstriche bei der DoD, also keine Einschränkungen der vereinbarten Qualität.
Anforderungen können während des Sprints weiter detailliert und vereinbart, auch geändert werden, solange die Umsetzung nicht abgeschlossen, und die Erreichung des Sprintziels nicht gefährdet ist.
Wichtige Begriffe
Taskboard: Die meisten Scrum-Teams visualisieren die Arbeit, die sie sich für den Sprint vorgenommen haben auf einem Taskboard. Die Gestaltung des Boards ist in jedem Team anders. Das Taskboard ist die Grundlage für Entscheidungen, die beim DSM getroffen werden, um die Zielerreichung zu gewährleisten.
Mögliche Fehlentwicklungen, die am Taskboard erkennbar sein können:
zu viele Tasks in Bearbeitung (mangelnder Fokus).
niedrig priorisierte Backlog Items werden zuerst umgesetzt (Nichtbeachtung der Priorisierung).
es gibt Teammitglieder, die keine oder zu viele Tasks in Bearbeitung haben.
Tasks werden mehrere Tage nicht als Done markiert (Task zu groß, unerwartete Probleme …).
Sprint Review
Im Sprint Review präsentiert das Scrum-Team die Funktionalität, die im Sprint umgesetzt wurde.
Ziel
Gemeinsames Bild der Zielerreichung und des erzielten Fortschritts schaffen.
Die entwickelten Funktionalitäten abschließen um den Fokus auf die nächsten Backlog Items richten zu können.
Feedback für spätere Weiterentwicklung einholen.
Vorbereitung
Dauer: Timebox
je nach Teamgröße und Sprintlänge bis maximal 4 Stunden.
Der Product Owner
lädt die Stakeholder ein.
Die Entwickler
bereiten den Review vor – d.h. funktionierende Infrastruktur, Testdaten vorhanden wenn nötig etc.
Facilitation
Der Product Owner
sorgt dafür, dass das Sprintziel und das Sprint Backlog für alle zugänglich sind.
gibt einen Überblick über die kommenden Backlog Items.
entscheidet, ob die Funktionalität die Akzeptanzkriterien erfüllt.
Die Entwickler
präsentieren alle Backlog Items aus dem Sprint Backlog, die Done (gemäß DoD) sind.
beantworten Fragen und erklären, welche Probleme aufgetaucht sind und wie sie gelöst wurden.
Die Teilnehmenden
erarbeiten gemeinsam Änderungen und Erweiterungen der Funktionalität, die den Wert der Anwendung optimieren.
Der Scrum Master
unterstützt den Prozess (Teilnehmer verstehen den Zweck, Einhaltung der Time Box).
Ergebnis
Erledigte Backlog Items sind abgenommen und geschlossen.
Das Product Backlog ist aufgrund des Feedbacks von Product Owner bzw. Stakeholdern ergänzt und aktualisiert.
Wenn sich das Feedback auf neue Ideen oder Erweiterungen bezieht, werden neue Backlog Items im Product Backlog angelegt.
Backlog Items, die dokumentierte Akzeptanzkriterien oder die DoD noch nicht erfüllen, werden ebenfalls neu priorisiert und entsprechend eingeordnet.
Tipps
Die Begriffe „Review“ und „Demo“ werden in der Praxis synonym verwendet. Review beschreibt jedoch treffender, dass es um das Einholen von Feedback geht und nicht nur ums Herzeigen der Ergebnisse.
Bei 3-4 Entwicklern im Team dauert der Review bei einem zweiwöchigen Sprint erfahrungsgemäß 0,5 bis 1,5 Stunden. Die Länge hängt auch davon ab, ob und wie intensiv sich die Stakeholder daran beteiligen.
Der Review kann für eine breite Zielgruppe geöffnet werden, z.B. alle anderen Scrum-Teams, die am selben Produkt arbeiten.
Der Review ist KEIN Statusreport – die Stakeholder sollen das entwickelte Inkrement „erleben“.
Es sollen nur Funktionalitäten präsentiert werden, die Done (gemäß DoD) sind!
Die Stakeholder die neue Funktionalität ausprobieren zu lassen, anstatt sie zu präsentieren, bringt differenzierteres Feedback.
Die Stakeholder Items auswählen lassen, anhand derer veranschaulicht wird, wie die DoD erfüllt ist, erhöht das Verständnis und baut Vertrauen auf.
Wenn keine Stakeholder zum Review kommen, agiert der Product Owner als deren Proxy.
Sprint Retrospective
Die Sprint Retrospektive steht unter dem Motto „Inspect and Adapt“. Sie ist die Basis für die kontinuierliche Beseitigung von Hindernissen und Verbesserung der Zusammenarbeit im Scrum-Team.
Ziel
Erkenntnisse über unterschiedliche Perspektiven der Teammitglieder auf die Zusammenarbeit im vergangenen Sprint bezüglich Tools, Prozesse und Beziehungen gewinnen.
Überprüfen, wo das Scrum-Team steht und Möglichkeiten für die Weiterentwicklung der Effektivität des Teams diskutieren.
Maßnahmen zur Umsetzung der vereinbarten Veränderungen festlegen.
Vorbereitung
Dauer: Timebox
je nach Sprintlänge und Teamgröße 1 bis 3 Stunden.
Der Scrum Master
sorgt für das nötige Arbeitsmaterial (Pinnwände, Post-its, Stifte, etc. für alle Teilnehmer).
bereitet die Methoden für die einzelnen Schritte der Retrospektive vor.
Facilitation
Der Scrum Master
moderiert die Retrospektive und führt das Scrum-Team durch die Diskussion zu einer Vereinbarung.
macht die Umsetzung von vereinbarten Maßnahmen vergangener Retrospektiven transparent.
bringt seine Beobachtungen ein und stellt Themen, die er wahrnimmt zur Diskussion.
Die Teilnehmer
bringen sich aktiv in die Diskussion ein.
argumentieren offen, konstruktiv und lösungsorientiert.
An der Retrospektive nehmen ausschließlich die Mitglieder des Scrum-Teams teil. Dies schließt den Scrum Master ein.
Ergebnis
Vereinbarte Maßnahmen sind für alle Teammitglieder leicht zugänglich dokumentiert.
Der Scrum Master unterstützt das Scrum-Team bei der Umsetzung der Maßnahmen, insbesondere bei Abhängigkeiten von anderen Organisationseinheiten.
Tipps
Für die Retrospektive gilt das Prinzip der Vertraulichkeit: was besprochen wird bleibt im Raum, es sei denn, jemand bekommt den Auftrag ein Thema nach außen zu tragen.
Es empfiehlt sich, die Retrospektive gut vorzubereiten und Methoden so zu wählen, sodass
sich die Zeit für individuelle Reflexion und gemeinsame Diskussion abwechseln.
alle Anwesenden sich gleichberechtigt an der Diskussion beteiligen können.
sowohl zustimmende als auch kritische Meinungen ihren Platz haben.
die Ideen gut visualisiert werden können.
Abwechslung bei der Methodenwahl bringt einen Perspektivwechsel und neue Ideen.
Insbesondere am Anfang sind oft viele Themen zu klären. Es ist besser, Themen in fokussierte Meetings auszulagern, als die Timebox zu überschreiten. Beispiele hierfür sind Architekturentscheidungen, Vorgehen im Testing oder Kommunikation mit dem Product Owner.
In jeder Retrospektive sollten 1-3 konkrete Maßnahmen, die im nächsten Sprint umgesetzt werden können, festgelegt werden.
Die Umsetzung der Maßnahmen soll nach 2-3 Sprints überprüft, und gegebenenfalls Anpassungen vereinbart werden.
Experimente eignen sich hervorragend für die Entwicklung von effektiven Teamprozessen. Einigungen aus der Retrospektive können nach der Prüfung ihrer Wirksamkeit auch wieder verworfen werden.
Wichtige Begriffe
Inspect and Adapt:
Das Grundprinzip agiler Arbeitsweise ist die laufende Analyse der Prozesse und Beziehungen im Projekt und die laufende Umsetzung von Ideen zur Verbesserung.
Es gibt immer Spielraum für Verbesserung, auch bei eingespielten, effizienten Scrum-Teams.
Schritte der Retrospective:
Gesprächsbasis schaffen: Teilnehmer abholen, schauen wo die Leute stehen, wie sie sich gerade fühlen.
Themen sammeln: ein gemeinsames evidenzbasiertes Bild schaffen – Sprint Controlling, Beobachtungen sammeln, unterschiedliche Perspektiven sehen.
Erkenntnisse gewinnen: Warum sind die Sichtweisen so wie sie sind?, Warum wurden die Ereignisse im Sprint erlebt wie sie erlebt wurden bzw. haben sich so ausgewirkt wie sie sich ausgewirkt haben?
Abschluss: kurze Reflexion über den Verlauf und den Wert der Retrospektive, Feedback für den Moderator.