79
Scrum

Scrum - hs-augsburg.degori/AgileSWE/Script-Scrum-02.pdf · Scrum- Rollen Product Owner ist verantwortlich für den Erfolg der gesamten Entwicklungsvorhaben eines Produktes oder einer

Embed Size (px)

Citation preview

Scrum

WPF - IN, WI, TI, IAM

Überblick

Scrum

Was ist Scrum?● Scrum ist eine agiles Projektmanagement Rahmenwerk

● Scrum ist eine Methode zum Management komplexer Systeme (Inspect & Adapt)

● Scrum ist eine Methode zur Einführung agiler Projektmanagementmethoden in Unternehmen (Enterprise Scrum)

WPF - IN, WI, TI, IAM

Scrum

Was ist Scrum?● Selbst-organisierende Teams

● Produkt schreitet in Serien von monatlichen “Sprints” fort

● Anforderungen sind als Listeneinträge im “Produkt-Backlog” festgehalten

● Keine spezifischen Entwicklungsvorgehen vorgeschrieben

● Benutzt generative Regeln um ein agiles Umfeld für die Auslieferung von Produkten zu schaffen

● Einer der „agilen Prozesse“

WPF - IN, WI, TI, IAM

Scrum

WPF - IN, WI, TI, IAM

Scrum-Rollen

WPF - IN, WI, TI, IAM

Scrum- Rollen

Product Owner

WPF - IN, WI, TI, IAM

Scrum- Rollen

Product Owner

WPF - IN, WI, TI, IAM

Scrum- Rollen

Product Owner● ist verantwortlich für den Erfolg der gesamten

Entwicklungsvorhaben eines Produktes oder einer Produktlinie

● bringt die Produktvision ins Team. ● beschreibt die Anforderungen ● verwaltet und priorisiert das Product Backlog● managed die Stakeholder und arbeitet eng mit dem

Team während der gesamten Projektlaufzeit zusammen.

WPF - IN, WI, TI, IAM

Scrum- Rollen

Product Owner● Definiert Produkt-Features ● Bestimmt Auslieferungsdatum und Inhalt ● Ist verantwortlich für den Gewinn des Projekts

(ROI) ● Priorisiert Features abhängig vom Marktwert ● Passt Features und Prioritäten nach Bedarf für

jede Iteration an ● Akzeptiert oder weist Arbeitsergebnisse zurück● wohnt nach Möglichkeit den Daily Scrums bei, um

sich (passiv) zu informieren

WPF - IN, WI, TI, IAM

Scrum- Rollen

Was der Product Owner NICHT tut● Rolle des Chefs für das Team übernehmen● Dailys moderieren oder ungefragt dort reden● Während des Sprints den Sprint Backlog

beeinflussen (Zusatzanforderungen, Streichung von Aufgaben etc.)

● im Projekt als Team Member (z.B. Entwickler, Software-Architekt) mitarbeiten

● versuchen, gleichzeitig den ScrumMaster zu mimen

● seine Aufgabe nur zu Beginn und am Ende der Sprints wahrnehmen

WPF - IN, WI, TI, IAM

Scrum- Rollen

Scrum-Master

WPF - IN, WI, TI, IAM

Scrum- Rollen

Scrum-Master

WPF - IN, WI, TI, IAM

Scrum- Rollen

Scrum-Master

● Verantwortlich für die Einhaltung von Scrum-Werten und -Techniken

● Entfernt Hindernisse ● Stellt sicher, dass das Team vollständig funktional und

produktiv ist● Unterstützt die enge Zusammenarbeit zwischen allen

Rollen und Funktionen● Schützt das Team vor äußeren Störungen● hilft, Scrum richtig anzuwenden. ● Repräsentiert das Management gegenüber dem Projekt ● unterstützt das Team und stellt die direkte Arbeit

zwischen ProductOwner und Team sicher

WPF - IN, WI, TI, IAM

Scrum- Rollen

Scrum-Master

● beseitigt Impediments und hilft dem Team, seine Produktivität kontinuierlich zu steigern.

● ist der Trainer und Moderator des Teams. Er hat immer einen Trainingsplan für sein Team - das Impediment Backlog.

● hält die "inspect and adapt" Zyklen von Scrum unter Kontrolle.

● beschützt das Team und arbeitet zusammen mit dem Product Owner an der Maximierung der Rendite.

WPF - IN, WI, TI, IAM

Scrum- Rollen

Was der ScrumMaster NICHT tut

● Rolle des Chefs für das Team übernehmen● das Projekt in dem Sinne leiten, dass er anschafft,

wer welche Arbeit auf welche Weise zu erledigen hat

● Doppelfunktion als Team Member oder Product Owner übernehmen (Interessenkonflikte!)

WPF - IN, WI, TI, IAM

Scrum- Rollen

Exkurs: Scrum Master

WPF - IN, WI, TI, IAM

Scrum- Rollen

Exkurs: Scrum Master

WPF - IN, WI, TI, IAM

Scrum- Rollen

Das Team

WPF - IN, WI, TI, IAM

Scrum- Rollen

Das Team

WPF - IN, WI, TI, IAM

Scrum- Rollen

Das Team

● Typischerweise fünf bis zehn Leute● Funktionsübergreifend/interdisziplinär besetzt

○ Architekten, QA, Programmierer, UI-Designer, Tester, etc.

○ besteht aus unterschiedlichen Spezialisten, damit alle notwendigen Kenntnisse zur Realisierung des Produktes vorhanden sind.

● Teams organisieren sich selbst● Mitgliedschaft kann sich nur zwischen Sprints

verändern

WPF - IN, WI, TI, IAM

Scrum- Rollen

Das Team

● muss die Vision und die Sprint Ziele des Product Owners verstehen, um funktionsfähige Produktinkremente zu liefern

● ist bevollmächtigt und autonom● entscheidet selbständig über das Zerlegen von

Requirements in Tasks und deren Verteilung an einzelne Mitglieder

● jedes Team Member kennt das Big Picture des Projekts

● jedes Team Member aktualisiert täglich die Restaufwände seiner Tasks im Sprint Backlog

WPF - IN, WI, TI, IAM

Scrum- Rollen

Was ein Scrum-Team NICHT tut

● Fachkonzepte schreiben - dafür gibt es das Product Backlog des Product Owners

● sich vom Product Owner seine Arbeitsweise vorschreiben lassen

● im Daily Scrum dem ScrumMaster und/oder dem Product Owner berichten - die Team Members berichten einander

● das Sprint Backlog vernachlässigen● ungestörtes Arbeiten während des Sprints

verwechseln mit dem Sitzen im Elfenbeinturm

WPF - IN, WI, TI, IAM

Scrum Meetings

Überblick

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

WPF - IN, WI, TI, IAM

Scrum-AnforderungsmanagementAnforderungen

"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."

WPF - IN, WI, TI, IAM

Scrum-Anforderungsmanagement

Anforderungen

● Problem: Detaillierungsgrad ● wenige Dokumente - schnelle Software● wenig im Voraus● kleine Anforderungen● überschaubare Iterationen● so aufnehmen, dass Umfang geschätzt werden

kann● Lernprozess

WPF - IN, WI, TI, IAM

Scrum-Anforderungsmanagement

MVP - Minimum Viable Product

WPF - IN, WI, TI, IAM

● 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

Scrum-Anforderungsmanagement

MVP - Minimum Viable Product

WPF - IN, WI, TI, IAM

Scrum-Anforderungsmanagement

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

WPF - IN, WI, TI, IAM

Scrum-Anforderungsmanagement

Story Card

Als XY ...

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

... damit ...

WPF - IN, WI, TI, IAM

Scrum-Anforderungsmanagement

Story Card

Abnahmekriterien:

Rahmenbedingungen:

Lieferantenbeziehung:

Story Points:

Wichtigkeit:

WPF - IN, WI, TI, IAM

Scrum - User Stories

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

WPF - IN, WI, TI, IAM

Scrum - User Stories

WPF - IN, WI, TI, IAM

Scrum-AnforderungsmanagementStory Card - Advanced

● Straßenmetapher● Größe von Pareto

WPF - IN, WI, TI, IAM

Scrum - User Stories

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.

WPF - IN, WI, TI, IAM

Scrum - User Stories

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

WPF - IN, WI, TI, IAM

Scrum - User Stories

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

WPF - IN, WI, TI, IAM

Scrum - User Stories

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

WPF - IN, WI, TI, IAM

Scrum - User Stories

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)

WPF - IN, WI, TI, IAM

Scrum - User Stories

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

WPF - IN, WI, TI, IAM

Scrum - User Stories

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!

WPF - IN, WI, TI, IAM

Scrum - User Stories

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:➢ Eher ein EPIC, da viel zu groß➢ Besser: Runterbrechen in einzelne Stories

WPF - IN, WI, TI, IAM

Scrum - User Stories

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

WPF - IN, WI, TI, IAM

Scrum - User Stories

Priorisierungsmöglichkeiten MuSCoWDie 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

WPF - IN, WI, TI, IAM

Scrum - User Stories

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)

WPF - IN, WI, TI, IAM

Scrum-Meetings

Grooming / Backlog Refinement / Estimation

WPF - IN, WI, TI, IAM

Scrum-Schätzen

Definition Of Ready

Wann ist eine Story "Ready to estimate"?

WPF - IN, WI, TI, IAM

Scrum-Schätzen

Definition Of Ready

Wann ist eine Story "Ready to estimate"? ● Ist dem Team alles klar? ● Abnahmekriterien● Lieferantenbeziehung● Tests

WPF - IN, WI, TI, IAM

Scrum-Schätzen

Wie schätzen wir Aufwände

● Wetter von gestern● Fachliche Nachfragen ermöglichen● Entwicklerteams schätzen● Abstrakte Schätzmaße● Demokratisches Schätzen

WPF - IN, WI, TI, IAM

Scrum-Estimation

Estimation Meeting - Agenda

● Planning Poker● Diskussionen sind wichtig● Fibonacci Reihe als Wertebereich● Nivillierung (Referenz) ● Definition Of Ready ● Referenzstory● Niedrigste und höchste Schätzung diskutieren

WPF - IN, WI, TI, IAM

Scrum-Estimation

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.

WPF - IN, WI, TI, IAM

Scrum-Estimation

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

WPF - IN, WI, TI, IAM

Scrum-Meetings

Sprint Planning 1 + 2

WPF - IN, WI, TI, IAM

Scrum-Meetings - Planning

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?"

WPF - IN, WI, TI, IAM

Scrum-Meetings - Planning

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

WPF - IN, WI, TI, IAM

Scrum-Meetings - Planning

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?"

WPF - IN, WI, TI, IAM

WPF - IN7, WI7, TI7, IAM7WS 2011/12

Scrum-Meetings - Planning

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)

WPF - IN7, WI7, TI7, IAM7WS 2011/12

Scrum-Meetings - Planning

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

WPF - IN7, WI7, TI7, IAM7WS 2011/12

Scrum-Meetings

Daily Scrum und Scrum of Scrums

WPF - IN7, WI7, TI7, IAM7WS 2011/12

Scrum-Meetings

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!

WPF - IN7, WI7, TI7, IAM7WS 2011/12

Scrum-Meetings

Pigs and ChickensLeute, 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 sindSie wollen gern "involved" sein. In Scrum nennt man sie daher "Chickens".

WPF - IN7, WI7, TI7, IAM7WS 2011/12

Scrum-Meetings

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

WPF - IN7, WI7, TI7, IAM7WS 2011/12

Scrum-Meetings

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

WPF - IN7, WI7, TI7, IAM7WS 2011/12

Scrum-Meetings

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?

WPF - IN7, WI7, TI7, IAM7WS 2011/12

Scrum-Meetings

Daily Scrum - Benefits

● verbessert die Kommunikation, ● machet 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

WPF - IN7, WI7, TI7, IAM7WS 2011/12

Scrum-Meetings

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.

WPF - IN7, WI7, TI7, IAM7WS 2011/12

Scrum-Meetings

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.

WPF - IN7, WI7, TI7, IAM7WS 2011/12

Scrum-Meetings

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

WPF - IN7, WI7, TI7, IAM7WS 2011/12

Scrum Meetings

Review

WPF - IN7, WI7, TI7, IAM7WS 2011/12

Scrum Meetings

Review

WPF - IN7, WI7, TI7, IAM7WS 2011/12

Scrum Meetings - Review

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.

WPF - IN7, WI7, TI7, IAM7WS 2011/12

Scrum Meetings - Review

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.

WPF - IN7, WI7, TI7, IAM7WS 2011/12

Scrum Meetings

Retrospektive

WPF - IN7, WI7, TI7, IAM7WS 2011/12

Scrum Meetings

Retrospektive

WPF - IN7, WI7, TI7, IAM7WS 2011/12

Scrum Meetings

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

WPF - IN7, WI7, TI7, IAM7WS 2011/12

Scrum Meetings

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

WPF - IN7, WI7, TI7, IAM7WS 2011/12

Scrum Meetings

RetrospektiveViele Techniken für Retrospektiven Retrospektiven werden meist in den folgenden 5 Schritten durchgeführt: 1. Intro2. Daten sammeln 3. Einsichten gewinnen: Warum sind die Dinge wie

sie sind? 4. Maßnahmen beschließen 5. Abschluss

WPF - IN7, WI7, TI7, IAM7WS 2011/12

Scrum Meetings

Retrospektive - weitere Techniken

● Mad, Glad, Sad● Wandernder Stift● Fist of Five (Happiness Histogram)● Offene Diskussion● Brainstorming● Energy Seismograph (Gefühlswelle)● Sailboat● Spiderchart

WPF - IN7, WI7, TI7, IAM7WS 2011/12

Scrum Meetings

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?