Zu Hanser-Fachbuch.de
Warenkorb
Ralf Wirdemann
Scrum mit User Stories
Inhalt
6
Vorwort zur 3. Auflage
16
1 Einführung
18
1.1 Warum dieses Buch?
19
1.2 Struktur und Aufbau
20
1.3 Dankeschön
22
1.4 Feedback
23
2 Beispiel: Scrumcoaches.com
24
2.1 Das Projekt
25
2.2 Der Entwicklungsprozess
26
2.3 Die Beteiligten
26
2.4 Die Anforderungen
27
2.5 Priorisieren und Schätzen des Product Backlog
28
2.5.1 Priorisieren
29
2.5.2 Schätzen
30
2.6 Sprint-Planung
31
2.6.1 Sprint-Ziel
31
2.6.2 Entwicklungsgeschwindigkeit
32
2.6.3 Analyse der User Stories
32
2.6.4 Design der User Stories
32
2.7 Sprint-Durchführung
34
2.8 Messen des Sprint-Fortschritts
36
2.9 Am Ende des Sprint
37
2.9.1 Sprint-Review
37
2.9.2 Sprint-Retrospektive
37
2.10 Die Arbeit geht weiter
39
2.11 Zusammenfassung
40
2.12 Wie geht es weiter?
40
3 Die Grundlagen von Scrum
42
3.1 Was ist Scrum?
42
3.2 Scrum, ein Framework?
44
3.3 Überblick
45
3.3.1 Scrum-Team
45
3.3.2 Vision und Product Backlog
45
3.3.3 Sprint Planning Meeting
46
3.3.4 Sprints
47
3.3.5 Daily Scrums
47
3.3.6 Sprint-Review
48
3.3.7 Sprint-Retrospektive
48
3.4 Prinzipien
48
3.4.1 Transparenz
48
3.4.2 Beobachten und Anpassen
49
3.4.3 Timeboxing
50
3.4.4 Dinge abschließen
50
3.4.5 Maximierung von Geschäftswert
51
3.4.6 Teams scheitern nicht
52
3.4.7 Ergebnisorientierung
52
3.5 Die Rollen
53
3.5.1 Das Team
54
3.5.2 Der ScrumMaster
55
3.5.2.1 Dienstleistender Anführer und Problembeseitiger
55
3.5.2.2 Scrum implementieren
56
3.5.2.3 Entscheider
56
3.5.2.4 Müssen ScrumMaster programmieren können?
57
3.5.2.5 Product Owner-Coaching
57
3.5.2.6 Belastbare Persönlichkeit
57
3.5.2.7 Scrum in der Organisation verbreiten
58
3.5.3 Der Product Owner
58
3.5.3.1 Den Kunden repräsentieren
59
3.5.3.2 User Stories und Product Backlog
59
3.5.3.3 Mit dem Team durch den Sprint
60
3.5.3.4 Bestimmen, wann was fertig ist
60
3.5.4 Nebenrolle Kunde
60
3.6 Die ideale Arbeitsumgebung
62
3.7 Empirisches Management
63
3.8 Zusammenfassung
65
3.9 Wie geht es weiter?
65
4 User Stories
66
4.1 Was sind User Stories?
67
4.1.1 Story-Karte
68
4.1.2 Konversation
69
4.1.3 Akzeptanzkriterien
69
4.2 Warum User Stories?
70
4.3 User Stories schreiben
71
4.3.1 Die Sprache des Kunden
72
4.3.2 Benutzerrollen
72
4.3.3 User-Story-Muster
74
4.3.4 Epics
74
4.3.5 Themen
76
4.3.6 Wie viel Detail?
77
4.3.7 Keine Technik
78
4.3.8 Keine Benutzeroberfläche
78
4.4 Eigenschaften guter User Stories
78
4.4.1 Independent – Unabhängige User Stories
78
4.4.2 Negotiable – Verhandelbare User Stories
79
4.4.3 Valuable – Wertvolle User Stories
79
4.4.4 Estimatable – Schätzbare User Stories
80
4.4.5 Small – Kleine User Stories
80
4.4.6 Testable – Testbare User Stories
81
4.5 Zusammenfassung
82
4.6 Wie geht es weiter?
82
5 Agiles Schätzen
84
5.1 Was ist agiles Schätzen?
85
5.1.1 Relative Größe statt Dauer
85
5.1.2 Schätzen in Story Points
86
5.1.3 Wo bleibt die Dauer?
87
5.1.4 Argumentationshilfe für Story Points
87
5.2 Schätzen von User Stories
88
5.2.1 Größenordnungen und Punktesequenzen
89
5.2.2 Planungspoker
91
5.2.2.1 Schätzen im Team
93
5.2.2.2 Referenz-Story und Triangularisierung
93
5.2.2.3 Planungspoker funktioniert
95
5.2.3 Wann schätzen?
95
5.3 Zusammenfassung
96
5.4 Wie geht es weiter?
96
6 Agiles Planen
98
6.1 Was macht Planung agil?
98
6.2 Velocity
100
6.2.1 Tatsächliche Velocity
100
6.2.2 Angenommene Velocity
101
6.2.2.1 Angenommene Velocity = Tatsächliche Velocity
102
6.2.2.2 Mittlere Velocity
103
6.2.3 Velocity-basierte Planung
104
6.2.4 Nachhaltige Velocity
105
6.3 Agile Planung funktioniert
107
6.3.1 Velocity korrigiert Schätzfehler
107
6.3.2 Neubewertung von User Stories
108
6.3.3 Urlaub, Krankheit und ähnliche Ereignisse
109
6.3.4 Der Plan entsteht
109
6.4 Zusammenfassung
110
6.5 Wie geht es weiter?
110
7 User Stories fürs Product Backlog
112
7.1 Das Product Backlog
112
7.2 Das Product Backlog füllen
115
7.2.1 Anforderungsworkshops
116
7.2.2 Interviews, Markt-Feedback und Abstimmungsrunden
117
7.2.3 Überarbeitung und Pflege des Product Backlog
118
7.3 User Stories priorisieren
119
7.3.1 Finanzieller Wert
119
7.3.2 Kosten
120
7.3.3 Kundenzufriedenheit nach Kano
121
7.3.4 Risiko
122
7.3.5 Abhängigkeiten
123
7.3.6 Priorisierende Faktoren abwägen
123
7.3.7 MuSCoW-Priorisierung
124
7.4 User Stories schneiden
125
7.4.1 Vertikales Schneiden
126
7.4.2 Schneiden nach Daten
127
7.4.3 Schneiden nach Aufwand
128
7.4.4 Schneiden nach Forschungsanteilen
128
7.4.5 Schneiden nach Qualität
129
7.4.6 Schneiden nach Benutzerrolle
130
7.4.7 Schneiden nach Akzeptanzkriterien
130
7.4.8 Schneiden nach technischer Voraussetzung
131
7.5 Andere Anforderungen
132
7.5.1 Anforderungen umformulieren
132
7.5.2 Constraints
133
7.5.3 Fehler
134
7.5.4 Technisches Backlog
134
7.6 Zusammenfassung
135
7.7 Wie geht es weiter?
136
8 User Story Mapping
138
8.1 User Story Maps
139
8.2 Eine Story Map erstellen
140
8.2.1 Schritt 1: User Tasks ermitteln
141
8.2.2 Schritt 2: Gruppen bilden – User Activities
142
8.2.3 Schritt 3: Ordnung schaffen
143
8.2.4 Schritt 4: User Tasks durchlaufen = Geschichten erzählen
143
8.2.5 Schritt 5: User Stories schreiben
144
8.3 Warum Story Mapping?
145
8.3.1 Basis für gute Product Backlogs
145
8.3.2 Kleinstmögliche Releases
146
8.3.3 Motivation und Einsicht für alle Stakeholder
146
8.3.4 Lückenlosigkeit
146
8.3.5 Softwarearchitektur
147
8.3.6 Multi-Team-Setups
147
8.4 Von der Story Map zum Product Backlog
147
8.4.1 User Stories schreiben
150
8.4.2 Die Story Map ersetzt das Product Backlog
150
8.5 Zusammenfassung
150
8.6 Wie geht es weiter?
151
9 Sprint-Planung
152
9.1 Überblick und Ablauf
152
9.2 Beteiligte
153
9.3 Ergebnisse
153
9.4 Vorbereitung
156
9.4.1 Sprint Velocity
156
9.4.1.1 Anpassen der Velocity
156
9.4.1.2 Bugfixing, Refactoring und andere Aufgaben
157
9.4.2 Story-Auswahl
158
9.4.3 Sprint-Länge
159
9.5 Sprint Planning 1
160
9.5.1 Ablauf
160
9.5.2 Sprint-Ziel – Warum führen wir den Sprint durch?
161
9.5.3 Vorstellung, Analyse und Commitment
161
9.5.4 Fehler und andere technische Aufgaben
163
9.6 Sprint Planning 2
164
9.6.1 Ablauf
165
9.6.2 Story-Design
166
9.6.3 Tasks schneiden
167
9.6.3.1 Taskgröße
168
9.6.3.2 Schneidetechniken
168
9.6.3.3 Ungeplante Tasks
169
9.6.4 Tasks schätzen?
169
9.6.4.1 Taskschätzungen sind sinnvoll
170
9.6.4.2 Taskschätzungen sind unsinnig
170
9.6.4.3 Keine Empfehlung
171
9.6.5 Das Sprint Backlog
172
9.6.6 Fehler und andere technischen Aufgaben verteilen
173
9.6.7 Was tun, wenn es länger wird?
173
9.7 Abschluss
174
9.8 Zusammenfassung
175
9.9 Wie geht es weiter?
175
10 Sprint-Durchführung
176
10.1 Die eigentliche Arbeit beginnt
176
10.2 Wer macht was?
178
10.2.1 Das Team
178
10.2.2 Der Product Owner
179
10.2.3 Der ScrumMaster
179
10.3 Story für Story Richtung Sprint-Ziel
180
10.3.1 Wie viele User Stories zurzeit?
181
10.3.2 Arbeit an einer User Story
181
10.3.3 Definition of Done
181
10.3.4 Abnahme fertiger User Stories
182
10.3.4.1 Entwicklertest
182
10.3.4.2 Akzeptanztest
183
10.3.4.3 QA-Abnahme
183
10.3.4.4 Frühestmögliche Fehlerbehebung
184
10.4 Daily Scrum
184
10.4.1 Aktualisierung des Taskboard
185
10.4.2 Ein guter Zeitpunkt
186
10.4.3 Ein guter Ort
187
10.4.4 Wer ist noch dabei?
187
10.4.5 Was macht der ScrumMaster?
188
10.5 Unterbrechungen
189
10.6 Messen und Anpassen
190
10.6.1 Bug- und technische Burndown-Charts
191
10.6.2 Was tun, wenn es eng wird?
192
10.7 Reguläres Sprint-Ende
193
10.8 Sprint-Review
194
10.8.1 Vorbereitung
194
10.8.2 Ort, Zeitpunkt und Teilnehmer
194
10.8.3 Ziel
195
10.8.4 Ablauf
195
10.9 Das Team organisiert sich
196
10.9.1 Verantwortung übernehmen
196
10.9.2 Das Team machen lassen und aus Fehlern lernen
197
10.9.3 Den Product Owner einbeziehen
197
10.9.4 Software-Pull-Systeme
198
10.9.5 Das Team bei der Arbeit mit Tasks coachen
199
10.9.6 Einzelgespräche
199
10.10 Sprint Best Practices
200
10.10.1 Source Code Management und Story-Branches
200
10.10.2 Kontinuierliches Integrieren
201
10.10.3 Automatisierung
201
10.10.4 Verständlicher Quellcode
202
10.10.5 Elektronische Sprint Backlogs und Burndown-Charts
202
10.11 Zusammenfassung
203
10.12 Wie geht es weiter?
203
11 User Stories Akzeptanztesten
204
11.1 Was ist Akzeptanztesten?
204
11.1.1 Akzeptanzkriterien
205
11.1.1.1 Akzeptanzkriterien sind Erwartungen
205
11.1.1.2 Akzeptanzkriterien sind Geschäftsregeln
206
11.1.2 Akzeptanztests
206
11.1.3 Akzeptanztesten
207
11.2 Akzeptanzkriterien schreiben
208
11.2.1 Vom Akzeptanzkriterium zum Akzeptanztest
208
11.2.2 Merkmale guter Akzeptanzkriterien
209
11.2.3 Akzeptanzkriterien auch für Epics?
211
11.3 Beispiel: Suche nach Coaches
211
11.4 Kleine Bausteine: Auf dem Weg zur DSL
212
11.5 Akzeptanztesten während des Sprint
213
11.6 Die hohe Schule: Akzeptanztest-getriebene Entwicklung
215
11.6.1 ATDD-Beispiel: Suche nach Coaches
216
11.6.2 Product Owner love writing Tests?
218
11.6.2.1 Alternative JCriteria
218
11.7 Lohnt sich das Ganze?
219
11.8 Zusammenfassung
219
11.9 Wie geht es weiter?
220
12 Sprint-Retrospektive
222
12.1 Nach dem Sprint ist vor dem Sprint
223
12.2 Ablauf von Retrospektiven
223
12.3 Retrospektiven vorbereiten
225
12.4 Retrospektiven leiten
225
12.5 Agenda und Check-in
226
12.6 Phase 1: Daten sammeln
227
12.6.1 Erstellung einer Timeline
228
12.6.2 Erweiterung der Timeline um Energiepunkte
229
12.7 Phase 2: Einsichten generieren
230
12.7.1 Positiv- / Delta-Liste
230
12.7.2 Warum-Fragen
231
12.8 Phase 3: Entscheiden, was zu tun ist
231
12.9 Phase 4: Ziele formulieren und Aktionen planen
232
12.10 Abschluss
233
12.11 Themenorientierte Retrospektiven
234
12.12 Zusammenfassung
235
12.13 Wie geht es weiter?
236
13 Agile Releaseplanung
238
13.1 Releaseplanung
238
13.1.1 Themen-Releases
238
13.1.2 Datum-Releases
239
13.1.3 Releaseplanungs-Workshop
240
13.1.4 Was macht die Planung agil?
240
13.2 Planungs-Velocity
241
13.2.1 Durchführung von Test-Sprints
241
13.2.2 Historische Daten
242
13.2.3 Das Team bestimmen lassen
242
13.2.4 Auswahl eines Verfahrens
242
13.3 Der Releaseplan
243
13.4 Sichere Planung
244
13.4.1 Sichere Velocity
244
13.4.2 Sicherheit durch weniger wichtige User Stories
245
13.5 Monitoring und Aktualisierung
246
13.6 Zusammenfassung
247
13.7 Wie geht es weiter?
247
14 Verticals – SCRUM@OTTO
248
14.1 Warum ich über diese Geschichte schreibe
248
14.2 Die Vorgeschichte
250
14.3 Das Lhotse-Projekt – Zahlen, Daten, Fakten
251
14.4 Das Team – Menschen im Mittelpunkt
252
14.5 Triaden – die Führung eines Teams
254
14.6 Die Triade – Rollenbeschreibungen
254
14.6.1 Der Projektmanager – Project-Lead
255
14.6.2 Der Produktmanager – Business-Designer
256
14.6.3 Der Team-Architekt – Technical-Designer
256
14.7 Die TD-Runde
258
14.8 Die Otto-Architektur in Vertikalen
259
14.8.1 Warum die klassische IT versagt
259
14.8.2 Warum vertikale Schnitte helfen
262
14.8.3 Was eine Vertikale ist
263
14.8.4 Wie vertikale Schnitte gefunden werden können
265
14.9 Makro- und Mikroarchitektur
267
14.9.1 Makroarchitektur
268
14.9.2 Mikroarchitektur
268
14.10 Werte und Leitplanken statt Richtlinien und Governance
269
14.11 Das klassische Management in der agiler werdenden Organisation
269
14.12 Scrum@Otto – 100 Sprints später
271
14.13 Fazit
273
Glossar
274
Literatur
282
Stichwortverzeichnis
282
© 2009-2024 ciando GmbH