Agiles Projektmanagement mit Scrum und Userstories

Thomas SchisslerTSchissler@artiso.com

http://www.artiso.com/problog

Vorstellung• Thomas Schissler

– Coach und Consultant artiso AG– Schwerpunkte sind

• Team Foundation Server• Entwicklungsprozesse• Software-Architektur und Software Design

– Professional Scrum Developer Trainer– Leiter der .net Developergroup Ulm

(http://www.dotnet-ulm.de) – EMEA-Lead Visual Studio ALM User Group

(http://www.vsalmug.com) – Blog : http://www.artiso.com/problog– Kontakt: Tschissler@artiso.com

Was ist SCRUM

• SCRUM ist ein Framework für agile Prozesse• Basiert auf Empirischem Projektmanagement• SCRUM ist nicht trivial, auch wenn es auf den ersten

Blick so erscheint

Agile Anforderungen

Agile Anforderungen

• ... sind lösungsfrei definiert• ... sind als Einzelartefakte abgebildet• ... sind aus Kundensicht formuliert• ... beschreiben einen Kundennutzen• ... enthalten Akzeptanz-Kriterien• ... beschreiben kurz und knapp die Anforderung• ... bieten Raum um Notizen abzulegen• ... „reifen“

Agile Anforderungen als User Story

8 SP

Demo User Stories mit Karteikarten User Stories im TFS

Agiles Anforderungsmanagement

Demo Hierarchien im TFS

Priorisierung

Sortierung

Sortierung

• Priorisierung muss eindeutig sein (Reihenfolge)• Die Sortierung wird durch verschiedene Faktoren

beeinflusst– Wert einer Funktion– Risiko der Funktion (Risiken früh ausschließen)– Kosten der Funktion (auf Basis der Schätzung)– Neues Wissen

• Die Sortierung ist alleinig die Aufgabe des PO

Sortierung

• Sortierung in der Hierarchie eignet sich nicht um eine Implementierungsreihenfolge festzulegen

• Zusätzliche Sicht auf ein flaches Backlog notwendig• Zwei Sortierkriterien

Demo Sortierung in der Hierarchie Sortierung im flachen Backlog

Agile Planung

„Ein Plan hält nur, bis zur ersten Feinberührung“ Feldmarschall Helmuth Graf von Moltke

Agiles Schätzen

• Eine Schätzung basiert immer auf einer Annahme• Eine Schätzung gibt die aktuelle Sicht wieder und

kann sich jederzeit ändern• Statt einer möglichst genauen Schätzung zu Beginn

werden Änderungen kontinuierlich abgebildet und Auswirkungen transparent gemacht

Schätzaufwand

0

50

100

Aufwand

Gen

auigkeit

Schätzung in Komplexität

• Schätzung in einer abstrakten Einheit (Story Points, T-Shirt Sizes, Gummibärchen)

• Schätzung der relativen Komplexität• Stellt sich heraus, dass zu optimistisch oder zu

pessimistisch geschätzt wurde, muss die Schätzung nicht angepasst werden, die Relation bleibt erhalten

• Es wird die Velocity gemessen und daraus können Prognosen erstellt werden

Planning Poker ®

• Es gibt Karten mit der Wertigkeit 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞, ?

• Jeder Teilnehmer erhält einen Kartensatz• Vom PO wird jeweils eine User Story vorgestellt• Jeder Teilnehmer schätzt die relative Komplexität und legt die

Karte verdeckt vor sich• Alle Karten werden gleichzeitig aufgedeckt• Teilnehmer mit der höchsten und niedrigsten Schätzung

begründen und die Schätzung wird wiederholt

Demo Planning Poker für Slides Download

Schätzung in Hierarchien

• Kommulierung in der Hierarchie ist eher unpraktisch• Beim Breakdown Verteilung auf Sub-Elemente• Zusätzlich auf übergeordneten Elementen durch Sub-

Elemente nicht beschriebene Funktionen schätzen• Beim Anlegen neuer Sub-Elemente Schätzungen

dafür vom übergeordneten Element abziehen• Auf Komplexitätsskala runden• Dadurch müssen diese Elemente auch Teil des

Backlogs sein und bearbeitet werden (Done)

Demo Breakdown der Slides Download Story Schätzung der Sub-Stories

Sprint Planung

Sprint Planning II

• Das Team entwickelt eine gemeinsame Realisierungsvision

• Aus der Realisierungsvision leiten sich Tasks ab• Aus den Akzeptanz-Kriterien leiten sich Akzeptanz-

Tests ab• Zu den Tasks und Tests werden Stunden geschätzt

Task Breakdown

Task 1.1User Story 1

User Story 2

Task 1.2

Task 1.4Task 1.3

Task 1.5

Test 1.1

Test 1.3Test 1.2

Test 1.4

Task 2.1 Task 2.2

Task 2.4Task 2.3

Task 2.5

Test 2.1

Test 2.3Test 2.2

Test 2.4

Aktiv Abgeschlossen

Sprint Burndown Chart

Sprint Durchführung

Kein Best-Guess

Product OwnerEntwickler

Team

Welche Änderungen ergeben sich aus

der Antwort?

Detailierung der

Anforderung

Wie soll das implementiert

werden?

Release-Planung

Release Vision

• Gibt übergeordnete Ziele für das Release vor• Hilft strategische Ziele im Blick zu behalten• Regelmäßiger Review

– Sind wir noch auf dem richtigen Weg?– Hat sich unsere Release-Vision geändert?

Agile Release-Planung

• Erstellung eines initialen Product Backlogs mit groben PBIs

• Schätzung der PBIs• Ermittlung der Velocity (aus der Historie oder

schätzen)• Hochrechnung wie lange die Umsetzung der PBIs

dauern wird• Pflege des Backlogs und Aktualisierung der Velocity

verändern die Releaseplanung

Releaseplan

Häufige Fragen

• Wie dokumentiere ich Abhängigkeiten zwischen Anforderungen?

• Wie schätze ich aufeinander aufbauende Funktionen• Wie gehe ich mit Festpreis-Projekten um?

„Ein Plan ist nichts, Planung ist alles“

Dwight D. Eisenhower