Visions Workshop Grooming (Estimation Meeting) Sprint Planning 1 Sprint Planning 2 Daily Scrum Scrum of Scrums Review Retrospektive

(1)

Überblick

● Visions Workshop

● Grooming (Estimation Meeting)

● Sprint Planning 1

● Sprint Planning 2

● Daily Scrum

● Scrum of Scrums

● Review

● Retrospektive

WPF - IN, WI, TI, IAM

(2)

Anforderungen

"Unter einer Anforderung oder einem

Requirement versteht man einen Aspekt, den die zu erstellende Software erfüllen soll.

Unter der Summe aller Anforderungen verstehen wir alle die Aspekte des

Einsatzkontextes, die vom zukünftigen System abgedeckt werden sollen."

(3)

Anforderungen

● Problem: Detaillierungsgrad

● wenige Dokumente - schnelle Software

● wenig im Voraus

● kleine Anforderungen

● überschaubare Iterationen

● so aufnehmen, dass Umfang geschätzt werden kann

● Lernprozess

(4)

MVP - Minimum Viable Product

● minimal überlebensfähiges Produkt

● Klarheit über Marktchancen

● nötigste Kernfunktionen

● Feedback von (möglichen) Kunden einholen

● Early adopters (frühestmögliche Bereitstellung eines Produkts an User)

● Testen einer Marktlücke mit möglichst wenig

Entwicklungsaufwand

(5)

MVP - Minimum Viable Product

(6)

● “The Minimal Viable Product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

● “The Minimum Marketable Feature is the smallest unit of functionality with intrinsic market value.”

○ Eine Funktionalität oder ein Feature, das dem Enduser einen echten Nutzen bringt

● “The Minimum Marketable Release” ist das erste Release der MMFs

MMP - Minimum Marketable Feature/Product

(7)

MMP - Minimum Marketable Product

(8)

Anforderungen in Scrum

● Pragmatischer Weg: kommender Sprint

● Klarheit zwischen Entwickler und Kunde

● "User-Stories" zur Beschreibung der Anforderungen

● Story als "Versprechen"

● Story als Kommunikationsmittel

● so genau, dass man schätzen kann

● Karteikarten

● Stories aus Nutzersicht beschreiben, nicht

technisch

(9)

User Stories

● beschreiben das gewünschte Verhalten eines Software-Systems

● basieren auf einer Konversation zwischen den Anspruchsgruppen (Kunde, Fach, IT)

● beschreiben das WAS und nicht das WIE

● sind aus der Perspektive des Benutzers geschrieben (natürlichen Sprache)

● generieren Business Value

● fokussieren auf kleine, verdaubare Häppchen

● formulieren das Bedürfnis mit wenigen Worten (Story Card)

● dienen als Kommunikationsmittel zwischen

● den Stakeholdern (Anforderer, Kunde, Nutzer, Interessent…)

● und den Umsetzern (Entwickler, Designer, Tester, …)

● minimieren das Risiko, dass Anforderungen

○ falsch verstanden

○ falsch geschätzt

○ falsch umgesetzt werden

(10)

Story Card Als XY ...

... möchte ich folgendes Feature ...

... damit ...

(11)

Story Card

(12)

Story Card

Abnahmekriterien:

Rahmenbedingungen:

Lieferantenbeziehung:

Story Points:

Wichtigkeit:

(13)

Story Card - Advanced

● Ist die Story schätzbar?

● Zerlegen von großen in kleinere Stories

● Vertikal schneiden

● Fachlich trennen

○ Fachliche Entität

○ Rolle

○ Kontext

○ Ergebnis

○ Details

○ Aufgabe

(14)

(15)

Story Card - Advanced

● Straßenmetapher

● Größe von Pareto

(16)

User Story Kriterien nach dem INVEST Prinzip

● Independent (I) (unabhängig)

○ Sie ist nicht von einer anderen User Story abhängig

● Negotiable (N) (verhandelbar)

○ Sie dient als Gesprächsgrundlage und kann gemeinsam weiterentwickelt werden.

● Valuable (V) (nützlich)

○ Sie stellt immer einen Vorteil für den User, Kunden oder Auftraggeber dar

● Estimatable (E) (quantifizierbar)

○ Sie ist schätzbar. Sie hat also soviel konkrete Details, dass ein erfahrenes Team deren Umfang schätzen kann

● Small (S) (klein)

○ Sie hat die richtige Größe

● Testable (T) (prüfbar)

○ Sie kann getestet werden.

(17)

Gute Stories schreiben

● Aus Anwendersicht

● Teamwork ist gefragt

● Kommunikation ist wichtig

● Keep it simple

● Abnahmekriterien (Akzeptanzkr.) sind wichtig

● Mit Papierkarten arbeiten (alternativ: visuelles Taskboard)

● Immer im Blick behalten

(18)

Beispiele schlechte Stories

Als Entwickler möchte ich eine Datenbankschicht, damit ich eine GUI dafür entwickeln kann

➢ Horizontal geschnitten - besser: vertikal

➢ “Entwickler” ist keine “Rolle” die mit dem System interagiert

(19)

Beispiele schlechte Stories

Als User möchte ich eine schöne GUI, damit es mir Spaß macht durch die App zu navigieren.

➢ … ist eher ein Akzeptanzkriterium

➢ … ist eher eine nichtfunktionale Anforderung

(20)

Beispiele schlechte Stories

Als User möchte ich dass die App eine schnelle Performance hat, damit ich nicht genervt bin beim benutzen.

➢ … ist eher ein Akzeptanzkriterium

➢ … ist eher eine nichtfunktionale Anforderung

➢ Besser: Messbare Angaben machen: z.B. “das Suchergebnis soll nach max. 500 Millisekunden angezeigt werde” (in den Akzeptanzkriterien)

(21)

Beispiele schlechte Stories

Als Administrator möchte ich einen

Administrationsbereich, damit ich alle Einstellungen der App anpassen kann.

➢ Eher ein EPIC, da viel zu groß

➢ Besser: Runterbrechen in einzelne Stories

(22)

Beispiele schlechte Stories

Als Kunde möchte ich in meinem Onlineshop suchen können, um mein gewünschtes Produkt zu finden.

Akzeptanzkriterien:

➢ Filter, “Meinten Sie”, Recommendations

➢ Übersteuerbar

➢ Suchranking nach Abverkaufszahlen

➢ Intelligenter Algorithmus

➢ Apache Technik: Lucene Probleme:

➢ Viel zu groß (Skateboard, Fahrrad, Auto …)

➢ Keine Technik vorgeben!

(23)

Beispiele “bessere” Stories

Als Käufer in einem Online Shop möchte ich vor der bindenden Bestellung eine Übersicht über meine Bestellung bekommen, um Fehler bei der

Bestellung auszuschließen.

Akzeptanzkriterien:

➢ Liste an Produkten mit Preis

➢ Wenn es mehr als 10 sind: Paginator

(24)

Beispiele “bessere” Stories

Als Angestellter beim Maschinenverleih möchte ich alle Rüttelplatten auflisten können, um diese

meinen Kunden anzubieten.

Akzeptanzkriterien:

➢ Die Liste zeigt alle noch nicht verliehenen Rüttelplatten an

➢ Die Liste ist nach Verleihpreis sortiert

➢ Wenn keine Rüttelplatten mehr vorhanden sind, erscheint ein Hinweistext

(25)

(26)

Hamburger Methode - Identifiziere Tasks

(27)

Identifiziere Optionen pro Layer (in Subteams)

(28)

Trimme den Hamburger

(29)

Nimm den ersten Biss

(30)

Priorisierungsmöglichkeiten MuSCoW

Die MuSCoW-Methode ist eine Technik zur Priorisierung, um Backlog Item grob in vier Kategorien einzuordnen:

● Must have

○ unbedingt erforderlich

● Should have

○ sollte umgesetzt werden, wenn alle MUST-Anforderungen trotzdem erfüllt werden können

● Could have

○ kann umgesetzt werden, wenn die Erfüllung von höherwertigen Anforderungen nicht beeinträchtigt wird

● Won’t have

○ wird diesmal nicht umgesetzt, aber für die Zukunft vorgemerkt

*Quelle: https://de.wikipedia.org/wiki/MoSCoW-Priorisierung

(31)

Priorisierungsmöglichkeiten by Value

● Business Value

○ Wie viel "bringt" die Umsetzung der Story dem Unternehmen

● User Benefit

○ Wie viel "bringt" die Umsetzung der Story unseren Kunden bzw. dem Nutzer des Features

● Strategic Value

○ Was bringt dieses Feature dem Unternehmen für IT-strategische Vorteile (Kostenersparnis, Höhere Variabilität, Cloudfähigkeit, etc.)

● Fun Factor

○ Wie viel Spaß macht es dem Team die Story umzusetzen.

● ROI

○ Gibt es Kennzahlen die gesteigert werden können (z.B. Umsatz oder Gewinn)

(32)

Product Backlog - DEEP

● Detailliert (passend)

○ User Stories im Product Backlog, die in Kürze angegangen werden, müssen hinreichend genau verstanden sein, damit sie im kommenden Sprint fertiggestellt werden können. Stories, die nicht so bald entwickelt werden, sollten nicht bis ins letzte Detail ausformuliert sein.

● Estimated (geschätzt)

○ Das Product Backlog ist mehr als eine Liste aller zu erledigenden Stories. Es ist auch ein

nützliches Planungswerkzeug. Da Artikel, die weiter unten hängen, noch nicht so gut verstanden sind, werden die damit verbundenen Schätzungen weniger genau sein als die Schätzungen, der höher prioren Stories.

● Emergent (unerwartet neu auftretend)

○ Ein Product Backlog ist nicht statisch. Es wird sich im Laufe der Zeit ändern. Im Laufe des Projekts werden User Stories im Product Backlog hinzugefügt, entfernt oder neu priorisiert.

● Priorisiert

○ Das Product Backlog sollte mit den wertvollsten Stories oben und mit dem am wenigsten

wertvollen unten sortiert werden. Indem das Team immer an der Priorität arbeitet, kann es den Wert des zu entwickelnden Produkts oder Systems maximieren.

(33)

(34)

Wer schreibt User Stories?

● Jeder kann User Stories schreiben. Es liegt in der Verantwortung des Product Owners sicherzustellen, dass ein Product Backlog mit User Stories vorhanden ist. Dies bedeutet jedoch nicht, dass der Product Owner derjenige ist, der sie schreibt – teilweise wird er es aber tun bzw. dabei unterstützen.

● Im Verlauf eines guten agilen Projekts kann jedes Teammitglied User Story schreiben.

● Neben dem Product Owner kann der Scrum Master beim Schreiben oder Formulieren von Stories helfen.

● Fakt: Die Diskussionen über eine User Story sind meist wichtiger als der Inhalt der Story

● Zitat: „Eine User Story ist ein Angebot zum Gespräch“

(35)

Wann werden User Stories geschrieben?

● User Stories werden während des gesamten Lebenszyklus eines Produkts geschrieben. Normalerweise findet zu Beginn eines Projekts ein

Story-Workshop statt, in welchem jedes Teammitglied das Ziel verfolgt, gemeinsam den Produkt-Backlog zu erstellen

● User Stories sollten nur eine bestimmten Umfang haben. (Passt die Story in einen Sprint). Falls die Stories zu groß sind, werden diese häufig auch als Epic bezeichnet. Epen werden später in kleinere Stories zerlegt.

● Darüber hinaus können jederzeit und von jedem neue Stories geschrieben und mit Rücksprache mit dem Produkt Owner dem Produkt-Backlog

hinzugefügt werden.

(36)

Wann ist eine Story “fertig”?

● Definition of Ready

○ Wie detailliert muss eine Story ausgefüllt sein, damit mit dieser begonnen werden kann?

● Definition of Done

○ Wann ist meine Story „fertig“?

● Akzeptanzkriterien

○ Was muss erfüllt sein,

○ damit eine Story „fertig“ ist

(37)

Zusammenfassung - User Story CCC

(38)

Grooming / Backlog Refinement / Estimation

(39)

Definition Of Ready

Wann ist eine Story "Ready to estimate"?

(40)

Definition Of Ready

Wann ist eine Story "Ready to estimate"?

● Ist dem Team alles klar?

● Abnahmekriterien

● Lieferantenbeziehung

● Tests

(41)

Wie schätzen wir Aufwände

● Wetter von gestern

● Fachliche Nachfragen ermöglichen

● Entwicklerteams schätzen

● Abstrakte Schätzmaße

● Demokratisches Schätzen

(42)

Estimation Meeting/Refinement - Agenda

● Planning Poker

● Diskussionen sind wichtig

● Fibonacci Reihe als Wertebereich

● Nivillierung (Referenz)

● Definition Of Ready

● Referenzstory

● Niedrigste und höchste Schätzung diskutieren

(43)

Estimation Meeting/Refinement - Zahlen

(44)

Estimation Meeting - Details

● Zunächst erhält jedes Teammitglied einen Stapel mit Schätz-Karten (Alternativ:

Scrum App -> Suche im Market unter: "Scrum").

● Der PO stellt eine zu schätzende Story vor. Das Team klärt etwaige Unklarheiten mit dem PO.

● Dann bespricht das Team die wesentlichen zur Umsetzung des Eintrags notwendigen Schritte.

● Jedes Teammitglied wählt eine Karte aus und legt sie verdeckt vor sich auf den Tisch.

● Zeitgleich drehen alle Teammitglieder ihre Karten um.

● Liegt kein Konsens vor, so erklären die beiden Teammitglieder, deren

Schätzwerte am weitesten auseinander liegen, warum sie den jeweiligen Wert gewählt haben. Dann erfolgt eine neue Schätzrunde.

● Der ScM moderiert und stellt sicher, dass die Besprechung pünktlich endet (Timebox).

● Das Meeting endet, wenn alle Einträge abgeschätzt, oder die Zeit abgelaufen ist.

● Anhand der geschätzten Komplexitäten können dann Dauer und Kosten errechnet werden.

(45)

Schnelles Schätzen - Alternative

● "Magical Estimation"

● geeignet für sehr grobe Schätzungen

● alle Stories werden ausgedruckt an Teammitglieder verteilt

● jeder hängt seine Stories an die Wand

● links die einfachsten, rechts die komplexesten

● danach werfen alle nochmal einen Blick darauf

● evtl. Nachbesserungen

● Einigung, wo man die Fibonacci Zahlen positioniert

● Wichtig: solche Schätzungen müssen als "magic"

markiert werden

(46)

Team Velocity

● Anfangs sagen die Story Points noch nicht viel aus

● Nach den ersten Sprints bekommt das Team ein Gefühl, wie viele Story Points pro Sprint geschafft werden können - ab da: Planung möglich! ^Story ^Points

A 5

B 8

C 3

D 13

E 8

F 5

G 3

H 20

I 3

J 8

K 8

L 5

M 13

(47)

Sprint Planning 1 + 2

(48)

Sprint Planning 1 Im Sprint Planning 1 erstellt das Team ein Sprint Backlog welches festlegt, welche Stories innerhalb des Sprints umgesetzt werden können.

Zentrale Frage

"Was machen wir?"

(49)

Ablauf

● Der Scrum-Master macht die Eckdaten des Sprints sichtbar

● Product Owner stellt Sprint-Ziel und die Vorauswahl der umzusetzenden Anforderungen vor

● Team legt fest, welche und wie viele der vom Product Owner vorbereiteten Stories innerhalb des Sprints

umgesetzt werden können

● Scrum Master moderiert und achtet auf die Einhaltung der Regeln (vor allem Wahrung des Pull-Prinzips, d.h.: Das

Team nimmt sich die Aufgaben, NICHT: Der Product Owner weist die Aufgaben zu)

● Team verpflichtet sich, die ausgwählten Stories komplett umzusetzen

(50)

Sprint Planning 2

Im Sprint Planning 1 bricht das Team die

einzelnen Stories in Tasks herunter und plant die Abarbeitungsreihenfolge.

Zentrale Frage

"Wie machen wir es?"

(51)

WPF - IN7, WI7, TI7, IAM7 WS 2011/12

Sprint Planning 2

● Entwicklungsteam weiß bereits, was es zu erledigen hat

● technische Umsetzung klären (ohne jedoch mit der eigentlichen Umsetzung zu beginnen).

● Dieses Meeting organisiert das

Entwicklungsteam eigenverantwortlich

● Ergebnis dieses Meetings: Aufgaben oder

„Tasks“, (dauer pro Task: max 1 Tag)

(52)

Sprint Planning 2

● Taskcards zusammen mit User Stories an Pinnwand (Taskboard)

● Pro Teammitglied ein "Bereich, in welchen er seine Tasks hängen kann

● Übersichtlich anordnen, damit erkennbar welche Aufgaben zu bearbeiten / in

Bearbeitung sind, und welche bereits bearbeitet wurden

● Anzahl Tasks auf "Burndown Chart" markieren

(53)

Task Board

(54)

Burndown Chart

(55)

WPF - IN7, WI7, TI7, IAM7 WS 2011/12

Daily Scrum und Scrum of Scrums

(56)

Pigs and Chickens

Beteiligte heißen Personen Pigs (Schweine) Außenstehende heißen Chickens (Hühner).

A chicken and a pig were brainstorming...

● Chicken: Let's start a restaurant!

● Pig: What would we call it?

● Chicken: Ham 'n' Eggs!

● Pig: No thanks. I'd be committed, but you'd only be

involved!

(57)

WPF - IN7, WI7, TI7, IAM7 WS 2011/12

Pigs and Chickens

Leute, die tatkräftig mitarbeiten und auch ein echtes Risiko auf sich nehmen.

Sie sind "committed".

In Scrum nennen man solche Leute daher

"Pigs".

Personen, die zwar gern mitreden, kritisieren und schlußendlich am Erfolg partizipieren

wollen, ansonsten aber eher unbeteiligt sind

Sie wollen gern "involved" sein. In Scrum

nennt man sie daher "Chickens".

(58)

Pigs

● Direkt am Projekt beteiligte Personen, die auch eine Last bzw. ein Risiko im Projekt tragen

● Arbeiten in durch die Scrum-Regeln definierter Weise zusammen

● Treffen sich regelmäßig zu kurzen, effizienten Meetings

● Halten ihre jeweiligen Scrum-Artefakte auf dem neuesten Stand, damit alle - auch die Chickens - sich selbständig über den

Fortschritt informieren können

(59)

WPF - IN7, WI7, TI7, IAM7 WS 2011/12

Chicken

● Am Projekt interessierte, jedoch nicht direkt an der Umsetzung und am Projektrisiko beteiligte Personen

● Geben vor, wissen zu müssen, was passiert, weil es angeblich ihre Arbeit in irgendeiner Weise

berührt/beeinflußt

● Overhead in Meetings und im gesamten Prozeß

● Bekommen in Scrum einmal pro Sprint Gelegenheit, sich zu informieren und Feedback zu geben

● Werden ansonsten gleich zu Beginn aus dem Prozeß eliminiert

● dürfen bestenfalls in Meetings zuhören

(60)

Daily Scrum

● ist ein Abstimmungsmeeting für die Teammitglieder.

● findet jeden Tag zur gleichen Zeit und am gleichen Ort statt.

● Die Dauer des Meetings ist auf 15 Minuten beschränkt.

● Dabei beantwortet jedes Teammitglieder die folgenden 3 Fragen:

1. Was habe ich seit dem letzten Daily Scrum erreicht?

2. Was hat mich daran behindert?

3. Was werde ich bis zum nächsten DailyScrum erreichen?

(61)

WPF - IN7, WI7, TI7, IAM7 WS 2011/12

Daily Scrum - Benefits

● verbessert die Kommunikation,

● macht andere Meetings überflüssig,

● identifiziert und beseitigt Hindernisse für die Entwicklung

● betont und fördert die schnelle Entscheidungsfindung

● verbessert den Kenntnisstand über das Projekt für alle

● Der ScrumMaster sorgt dafür, dass das Team dieses Meeting durchführt

● Das Team ist für die Durchführung des Daily Scrums

verantwortlich

(62)

Daily Scrum - übliche Fehler

● Der ScrumMaster bringt dem Team bei, wie es das

Daily Scrum kurz hält, indem er die Regeln durchsetzt und dafür sorgt, dass sich die Teilnehmer kurz fassen.

● Der ScrumMaster setzt auch die Regel durch, dass

„Hühner" während des Daily Scrums nicht sprechen oder sich auf andere Weise in das Daily Scrum

einmischen.

(63)

WPF - IN7, WI7, TI7, IAM7 WS 2011/12

Daily Scrum - Do's and Don'ts

● kein Reportmeeting

● nicht für jeden gedacht, sondern nur für die Mitarbeiter, die aus den Product Backlog-Einträgen ein Produkt-Inkrement erstellen (das Team).

● ist eine Inspektion des Fortschritts in Richtung auf dieses Sprintziel (die drei Fragen).

● Folgemeetings werden häufig eingeplant, um Anpassungen an der aufkommenden Arbeit im Sprint vorzunehmen.

● Die Zielsetzung ist es, die Wahrscheinlichkeit zu erhöhen, dass das Team sein Ziel erreicht.

● Schlüsselmeeting zur Inspektion und Adaption in Scrum.

(64)

Scrum of Scrums

● Bei großen Projekten arbeiten deutlich mehr als sieben Personen zusammen

● → mehrere Teams werden gebildet, die sich in der Folge untereinander mit möglichs wenig Overhead koordinieren und abgleichen müssen

● Jedes Team → eigenständig mit jeweils eigenem Sprint Backlog, eigenen Daily Scrums usw.

● Jedes Team: ein Mitglied in den Scrum of Scrums

● Ablauf nach Muster des Daily Scrum

● Teambotschafter berichten aus ihrem Teilprojekt

● Sie nehmen Informationen mit zurück in ihre jeweiligen Teams

(65)

WPF - IN7, WI7, TI7, IAM7 WS 2011/12

Review

(66)

Review

(67)

WPF - IN7, WI7, TI7, IAM7 WS 2011/12

Review

● Findet als Sprintabschluss statt

● ein auf vier Stunden beschränktes Meeting für einmonatige Sprints

● für kürzere Sprints: nicht mehr als 5% der gesamten Sprintzeit

● Scrum Team und Stakeholder arbeiten zusammen an der Betrachtung der Arbeitsergebnisse

● Auf dieser Basis erarbeiten sie die nächsten möglichen Schritte

● Rein informelles Meeting

● Vorführung der Funktionalität ist dazu gedacht, die Zusammenarbeit für die weitere Planung zu fördern.

(68)

Ablauf

● Der Product Owner identifiziert, was fertig gestellt wurde und was nicht.

● Das Team diskutiert, was während des Sprints

funktioniert hat, wobei es Probleme gegeben hat UND wie diese Probleme gelöst worden sind.

● Das Team demonstriert die geleistete Arbeit und beantwortet Fragen dazu.

● Der Product Owner diskutiert den aktuellen Stand des Product Backlogs.

● Alle Teilnehmer erarbeiten was ihr Eindruck über das gerade gesehene in Bezug auf die weitere Planung bedeutet.

(69)

WPF - IN7, WI7, TI7, IAM7 WS 2011/12

Retrospektive

(70)

Retrospektive

(71)

WPF - IN7, WI7, TI7, IAM7 WS 2011/12

Retrospektive

● Zeitpunkt: nach Review und vor Planning

● Entwicklungsprozess nach Scrum-Vorgaben inspizieren

● Ziel: kommenden Sprint effektiver und angenehmer gestalten

● Sinn: Wie ist der letzte Sprint gelaufen im Bezug auf:

○ Menschen

○ Beziehungen

○ Prozess

○ Werkzeuge

● wesentlichen Punkte identifizieren und priorisieren, die gut funktioniert haben

(72)

Retrospektive

● Punkte identifizieren, die noch besser gelaufen wären, wenn sie anders angegangen worden wären

● Themen:

○ Teamzusammensetzung

○ Meeting-Arrangements

○ Werkzeuge

○ die Definition von „fertig"

○ Kommunikationsmethoden

○ Prozesse, um aus dem Product Backlog etwas

„fertiges" herzustellen

● Scrum Team identifiziert umsetzbare Verbesserungsmaßnahmen

(73)

WPF - IN7, WI7, TI7, IAM7 WS 2011/12

Retrospektive

Viele Techniken für Retrospektiven

Retrospektiven werden meist in den folgenden 5 Schritten durchgeführt:

1. Intro

2. Daten sammeln

3. Einsichten gewinnen: Warum sind die Dinge wie sie sind?

4. Maßnahmen beschließen

5. Abschluss

(74)

Retrospektive - einfache Techniken

● Mad, Glad, Sad

● Wandernder Stift

● Fist of Five (Happiness Histogram)

● Offene Diskussion

● Brainstorming

● Energy Seismograph (Gefühlswelle)

...

(75)

WPF - IN7, WI7, TI7, IAM7 WS 2011/12

Spiderchart

(76)

Sailboat

(77)

WPF - IN7, WI7, TI7, IAM7 WS 2011/12

Glückskekse

Eine gute Retro sollte folgenden Dinge beinhalten:

• Fragen, welche die Teilnehmer zum Nachdenken anregen

• Was zu Essen

Neuer Grundsatz „Inspect, Eat and Adapt“. Der Ablauf ist der Folgende:

1. Jeder Teilnehmer bekommt einen Glückskeks.

2. Nacheinander öffnen die Teilnehmer ihren Glückskeks und beantworten die gestellte Frage. Man kann dem Team auch fünf Minuten geben, um ihre Gedanken aufzuschreiben.

3. Der ScrumMaster moderiert das Ganze, hakt nach und fragt auch andere Teammitglieder nach ihrer Meinung.

(78)

Hot Air Balloon

(79)

WPF - IN7, WI7, TI7, IAM7 WS 2011/12

Glows, Grows, Knows, and Throws

(80)

(81)

WPF - IN7, WI7, TI7, IAM7 WS 2011/12

Checkliste für eine erfolgreiche Retrospektive

● Gibt es einen Moderator und ist jedem klar, wer das ist?

● Bereitet der Moderator die Retrospektive vor?

● Hält sich der Moderator aus der inhaltlichen Diskussion heraus?

● Setzt der Moderator Hilfsmittel wie Moderationswände und -karten angemessen ein?

● Variiert der Moderator die konkrete Durchführungsform der Retrospektive?

● Wird die Timebox für die Retrospektive eingehalten?

● Findet die Retrospektive in einer angstfreien, energiegeladenen Atmosphäre statt?

● Partizipieren alle Teilnehmer aktiv an der Retrospektive?

● Werden die Ursachen für Probleme analysiert?

● Generiert die Retrospektive konkrete, umsetzbare Maßnahmen (SMART)?

● Werden die beschlossenen Maßnahmen schnell umgesetzt?