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 |