Cover | 1 |
Titel | 5 |
Impressum | 6 |
Inhaltsverzeichnis | 7 |
Vorwort von Mike Cohn | 21 |
Vorwort von Ron Jeffries | 23 |
Einleitung | 25 |
Danksagungen | 29 |
Über den Autor | 33 |
Kapitel 1: Einführung | 35 |
1.1 Was ist Scrum? | 35 |
1.2 Die Ursprünge von Scrum | 37 |
1.3 Wieso Scrum? | 38 |
1.4 Ergebnisse bei Genomica | 39 |
1.5 Kann Scrum Ihnen helfen? | 39 |
1.5.1 Die Complex-Domäne | 42 |
1.5.2 Die Complicated-Domäne | 42 |
1.5.3 Die Simple-Domäne | 43 |
1.5.4 Die Chaotic-Domäne | 43 |
1.5.5 Disorder (Nicht-Wissen, Regellosigkeit) | 43 |
1.5.6 Unterbrechungsgesteuerte Arbeit | 44 |
1.6 Abschließende Bemerkungen | 45 |
Teil I: Kernkonzepte | 47 |
Kapitel 2: Das Scrum-Framework | 49 |
2.1 Überblick | 49 |
2.2 Scrum-Rollen | 50 |
2.2.1 Product Owner | 51 |
2.2.2 ScrumMaster | 51 |
2.2.3 Das Entwicklungsteam | 52 |
2.3 Scrum-Aktivitäten und Artefakte | 52 |
2.3.1 Product Backlog | 54 |
2.3.2 Sprints | 56 |
2.3.3 Sprint-Planung | 57 |
2.3.4 Sprint-Ausführung | 58 |
2.3.5 Daily Scrum | 59 |
2.3.6 Fertig (Done) | 60 |
2.3.7 Sprint Review | 62 |
2.3.8 Sprint-Retrospektive | 63 |
2.4 Abschließende Bemerkungen | 63 |
Kapitel 3: Agile Prinzipien | 65 |
3.1 Überblick | 65 |
3.2 Veränderlichkeit und Unsicherheit | 68 |
3.2.1 Hilfreiche Veränderlichkeit bereitwillig annehmen | 68 |
3.2.2 Iterative und inkrementelle Entwicklung nutzen | 69 |
3.2.3 Ausnutzen der Veränderlichkeit durch Inspektion, Anpassung und Transparenz | 71 |
3.2.4 Gleichzeitiges Reduzieren aller Formen der Unsicherheit | 72 |
3.3 Vorhersage und Anpassung | 73 |
3.3.1 Optionen offen halten | 73 |
3.3.2 Akzeptieren, dass man es nicht gleich von Anfang an richtig machen kann | 74 |
3.3.3 Einen adaptiven, untersuchenden Ansatz bevorzugen | 76 |
3.3.4 Änderung auf eine ökonomisch sinnvolle Weise annehmen | 77 |
3.3.5 Vorhersagende, im Voraus erfolgende Arbeit mit adaptiver, bedarfsgerechter Arbeit abwägen | 80 |
3.4 Validiertes Wissen | 81 |
3.4.1 Schnelles Validieren wichtiger Annahmen | 81 |
3.4.2 Abwägen mehrerer gleichzeitiger Lernschleifen | 81 |
3.4.3 Organisieren des Workflows für schnelle Feedbacks | 82 |
3.5 Work in Process (WIP) | 84 |
3.5.1 Wirtschaftlich sinnvolle Batch-Größen benutzen | 84 |
3.5.2 Lagerbestände erkennen und sinnvoll verwalten | 86 |
3.5.3 Auf unerledigte Arbeit konzentrieren, nicht auf untätige Arbeiter | 87 |
3.5.4 Verzögerungskosten betrachten | 89 |
3.6 Fortschritt | 90 |
3.6.1 An Echtzeitinformationen anpassen und umplanen | 90 |
3.6.2 Fortschritt messen, indem man funktionierende Güter validiert | 91 |
3.6.3 Auf eine wertzentrierte Auslieferung konzentrieren | 91 |
3.7 Leistung | 92 |
3.7.1 Gehe schnell, aber hetze nicht | 92 |
3.7.2 Baue Qualität ein | 93 |
3.7.3 Mache alles ohne großes Zeremoniell | 93 |
3.8 Abschließende Bemerkungen | 94 |
Kapitel 4: Sprints | 97 |
4.1 Überblick | 97 |
4.2 Timeboxing | 98 |
4.2.1 Legt ein WIP-Limit fest | 98 |
4.2.2 Erzwingt eine Priorisierung | 98 |
4.2.3 Demonstriert Fortschritt | 99 |
4.2.4 Verhindert unnötigen Perfektionismus | 99 |
4.2.5 Motiviert die Fertigstellung | 99 |
4.2.6 Verbessert die Vorhersagbarkeit | 100 |
4.3 Kurze Zeitdauer | 100 |
4.3.1 Erleichterte Planung | 100 |
4.3.2 Schnelles Feedback | 101 |
4.3.3 Verbesserter Return on Investment | 101 |
4.3.4 Begrenzte Fehler | 101 |
4.3.5 Wiedererweckte Begeisterung | 101 |
4.3.6 Häufige Checkpoints | 102 |
4.4 Konsistente Dauer | 103 |
4.4.1 Vorteile der Kadenz | 104 |
4.4.2 Vereinfacht die Planung | 104 |
4.5 Keine das Ziel beeinflussenden Änderungen | 105 |
4.5.1 Was ist ein Sprint-Ziel? | 105 |
4.5.2 Gegenseitige Verpflichtung | 105 |
4.5.3 Änderungen versus Klärung | 106 |
4.5.4 Konsequenzen einer Änderung | 106 |
4.5.5 Pragmatisch sein | 108 |
4.5.6 Abnormaler Abbruch | 109 |
4.6 Definition von Fertig (Done) | 110 |
4.6.1 Wie lautet die Definition von Fertig? | 110 |
4.6.2 Die Definition von Fertig kann sich im Laufe der Zeit weiterentwickeln | 112 |
4.6.3 Definition von Fertig versus Akzeptanzkriterien | 114 |
4.6.4 Fertig versus Fertig-Fertig | 114 |
4.7 Abschließende Bemerkungen | 115 |
Kapitel 5: Anforderungen und User Stories | 117 |
5.1 Überblick | 117 |
5.2 Gespräche | 119 |
5.3 Progressive Verfeinerung | 120 |
5.4 Was sind User Stories? | 121 |
5.4.1 Card (Karte) | 121 |
5.4.2 Conversation (Gespräch) | 122 |
5.4.3 Confirmation (Bestätigung) | 123 |
5.5 Der Detaillierungsgrad | 124 |
5.6 In gute Stories INVESTieren | 127 |
5.6.1 Independent (unabhängig) | 127 |
5.6.2 Negotiable (verhandelbar) | 128 |
5.6.3 Valuable (werthaltig) | 128 |
5.6.4 Estimatable (schätzbar) | 130 |
5.6.5 Passende Größe (klein) | 130 |
5.6.6 Testable (prüfbar) | 131 |
5.7 Nichtfunktionale Anforderungen | 131 |
5.8 Stories zum Wissenserwerb | 132 |
5.9 Stories sammeln | 134 |
5.9.1 Workshop zum Schreiben von User Stories | 134 |
5.9.2 Story Mapping | 135 |
5.10 Abschließende Bemerkungen | 136 |
Kapitel 6: Das Product Backlog | 139 |
6.1 Überblick | 139 |
6.2 Product-Backlog-Elemente | 140 |
6.3 Merkmale guter Product Backlogs | 141 |
6.3.1 Detailed appropriately (ausreichend detailliert) | 141 |
6.3.2 Emergent | 142 |
6.3.3 Estimated (geschätzt) | 142 |
6.3.4 Prioritized (priorisiert) | 143 |
6.4 Pflege | 144 |
6.4.1 Was bedeutet Pflege? | 144 |
6.4.2 Wer führt die Pflege durch? | 145 |
6.4.3 Wann findet die Pflege statt? | 146 |
6.5 Die Definition von Bereit | 148 |
6.6 Flow Management | 150 |
6.6.1 Release Flow Management | 150 |
6.6.2 Sprint Flow Management | 151 |
6.7 Welche und wie viele Product Backlogs? | 152 |
6.7.1 Was ist ein Produkt? | 152 |
6.7.2 Große Produkte – hierarchische Backlogs | 154 |
6.7.3 Mehrere Teams – ein Product Backlog | 155 |
6.7.4 Ein Team – mehrere Produkte | 156 |
6.8 Abschließende Bemerkungen | 157 |
Kapitel 7: Schätzung und Velocity | 159 |
7.1 Überblick | 159 |
7.2 Was und wann wir schätzen | 160 |
7.2.1 Schätzungen für Portfolio-Backlog-Elemente | 161 |
7.2.2 Product-Backlog-Schätzungen | 161 |
7.2.3 Aufgabenschätzungen | 162 |
7.3 Schätzkonzepte für Product-Backlog-Elemente | 163 |
7.3.1 Als Team schätzen | 163 |
7.3.2 Schätzungen sind keine Verpflichtungen | 164 |
7.3.3 Exaktheit versus Präzision | 165 |
7.3.4 Relative Größenschätzung | 165 |
7.4 Schätzeinheiten für Product-Backlog-Elemente | 168 |
7.4.1 Story-Punkte | 168 |
7.4.2 Idealtage | 168 |
7.5 Planungspoker | 169 |
7.5.1 Schätzskala | 170 |
7.5.2 Wie man spielt | 171 |
7.5.3 Vorteile | 173 |
7.6 Was ist Velocity? | 173 |
7.7 Einen Velocity-Bereich berechnen | 174 |
7.8 Die Velocity vorhersagen | 175 |
7.9 Die Velocity beeinflussen | 176 |
7.10 Missbrauch der Velocity | 177 |
7.11 Abschließende Bemerkungen | 178 |
Kapitel 8: Technische Schulden | 179 |
8.1 Überblick | 179 |
8.2 Die Folgen technischer Schulden | 181 |
8.2.1 Unvorhersehbarer Wendepunkt | 182 |
8.2.2 Zunehmend verzögerte Auslieferung | 182 |
8.2.3 Beträchtliche Anzahl an Defekten | 182 |
8.2.4 Steigende Entwicklungs- und Support-Kosten | 182 |
8.2.5 Das Produkt verkümmert | 183 |
8.2.6 Schwindende Vorhersehbarkeit | 183 |
8.2.7 Leistungseinbruch | 183 |
8.2.8 Allgemeiner Frust | 184 |
8.2.9 Sinkende Kundenzufriedenheit | 184 |
8.3 Ursachen der technischen Schulden | 184 |
8.3.1 Druck hinsichtlich des Erreichens einer Deadline | 184 |
8.3.2 Erfolglose Versuche der Velocity-Beschleunigung | 185 |
8.3.3 Gerücht: Weniger Testen kann die Velocity beschleunigen | 186 |
8.3.4 Schulden bauen auf Schulden auf | 187 |
8.4 Technische Schulden müssen organisiert werden | 188 |
8.5 Die Zunahme technischer Schulden überwachen | 189 |
8.5.1 Bewährte technische Praktiken anwenden | 189 |
8.5.2 Eine starke Definition von Fertig benutzen | 190 |
8.5.3 Die wirtschaftlichen Aspekte technischer Schulden richtig verstehen | 190 |
8.6 Technische Schulden sichtbar machen | 193 |
8.6.1 Technische Schulden auf geschäftlicher Ebene sichtbar machen | 193 |
8.6.2 Technische Schulden auf der technischen Ebene sichtbar machen | 194 |
8.7 Technische Schulden abbauen | 196 |
8.7.1 Nicht alle technischen Schulden sollten abgebaut werden | 197 |
8.7.2 Wenden Sie die Pfadfinderregel an (Bauen Sie die Schulden ab, sobald sie Ihnen begegnen) | 199 |
8.7.3 Bauen Sie technische Schulden schrittweise ab | 199 |
8.7.4 Bauen Sie die technischen Schulden mit den höchsten Zinsen zuerst ab | 200 |
8.7.5 Technische Schulden abbauen, während man für den Kunden werthaltige Arbeit erledigt | 201 |
8.8 Abschließende Bemerkungen | 202 |
Teil II: Rollen | 203 |
Kapitel 9: Der Product Owner | 205 |
9.1 Überblick | 205 |
9.2 Hauptaufgaben | 206 |
9.2.1 Organisation der wirtschaftlichen Belange | 207 |
9.2.2 Mitwirkung an der Planung | 209 |
9.2.3 Pflege des Product Backlogs | 209 |
9.2.4 Definition und Verifikation der Akzeptanzkriterien | 209 |
9.2.5 Zusammenarbeit mit dem Entwicklungsteam | 210 |
9.2.6 Zusammenarbeit mit den Stakeholdern | 211 |
9.3 Eigenschaften/Fähigkeiten | 212 |
9.3.1 Fachwissen | 212 |
9.3.2 Soziale Kompetenz | 213 |
9.3.3 Entscheidungsfindung | 213 |
9.3.4 Verantwortung | 213 |
9.4 Der Alltag eines Product Owners | 214 |
9.5 Wer sollte Product Owner sein? | 216 |
9.5.1 Interne Entwicklung | 217 |
9.5.2 Gewerbliche Entwicklung | 218 |
9.5.3 Ausgelagerte Entwicklung | 220 |
9.5.4 Komponentenentwicklung | 221 |
9.6 Product Owner kombiniert mit anderen Rollen | 222 |
9.7 Das Product-Owner-Team | 222 |
9.7.1 Product-Owner-Stellvertreter | 223 |
9.7.2 Chief Product Owner | 224 |
9.8 Abschließende Bemerkungen | 225 |
Kapitel 10: ScrumMaster | 227 |
10.1 Überblick | 227 |
10.2 Wichtigste Aufgaben | 227 |
10.2.1 Coach | 227 |
10.2.2 »Dienende Führungskraft« | 228 |
10.2.3 Prozessautorität | 229 |
10.2.4 Schutz vor störenden Einflüssen | 229 |
10.2.5 Beseitigung von Hindernissen | 229 |
10.2.6 Berater in der Organisationsentwicklung | 229 |
10.3 Eigenschaften/Fähigkeiten | 230 |
10.3.1 Sachkundig | 230 |
10.3.2 Neugierig | 230 |
10.3.3 Geduldig | 231 |
10.3.4 Teamfähig | 231 |
10.3.5 Schützend | 231 |
10.3.6 Transparent | 232 |
10.4 Alltag | 232 |
10.5 Die Rolle ausfüllen | 233 |
10.5.1 Wer sollte ScrumMaster sein? | 233 |
10.5.2 Ist die Rolle des ScrumMasters eine Vollzeitbeschäftigung? | 234 |
10.5.3 ScrumMaster in Kombination mit anderen Rollen | 234 |
10.6 Abschließende Bemerkungen | 235 |
Kapitel 11: Das Entwicklungsteam | 237 |
11.1 Überblick | 237 |
11.2 Rollenspezifische Teams | 237 |
11.3 Wichtigste Aufgaben | 238 |
11.3.1 Durchführung des Sprints | 238 |
11.3.2 Tägliches Untersuchen und Anpassen (»Inspect and Adapt«) | 239 |
11.3.3 Pflege des Product Backlogs | 239 |
11.3.4 Den Sprint planen | 239 |
11.3.5 Produkt und Prozess untersuchen und anpassen | 239 |
11.4 Eigenschaften/Fertigkeiten | 240 |
11.4.1 Selbstorganisierend | 240 |
11.4.2 Funktionsübergreifend vielseitig | 242 |
11.4.3 T-förmige Fertigkeiten | 243 |
11.4.4 Die Musketier-Einstellung | 245 |
11.4.5 Kommunikation mit hoher Bandbreite | 247 |
11.4.6 Transparente Kommunikation | 248 |
11.4.7 Die richtige Größe | 248 |
11.4.8 Fokussiert und verpflichtet | 249 |
11.4.9 In einer nachhaltigen Geschwindigkeit arbeiten | 251 |
11.4.10 Langlebig | 252 |
11.5 Abschließende Bemerkungen | 254 |
Kapitel 12: Die Strukturen des Scrum-Teams | 255 |
12.1 Überblick | 255 |
12.2 Funktionsteams versus Komponententeams | 255 |
12.3 Koordination mehrerer Teams | 260 |
12.3.1 Scrum of Scrums | 260 |
12.3.2 Der Release-Train | 262 |
12.4 Abschließende Bemerkungen | 265 |
Kapitel 13: Manager | 267 |
13.1 Überblick | 267 |
13.2 Teams koordinieren | 268 |
13.2.1 Grenzen definieren | 269 |
13.2.2 Ein klares Ziel vorgeben | 269 |
13.2.3 Teams bilden | 270 |
13.2.4 Die Teamzusammensetzung ändern | 271 |
13.2.5 Teams bevollmächtigen | 271 |
13.3 Teams fördern | 273 |
13.3.1 Die Mitarbeiter anspornen | 273 |
13.3.2 Kompetenz entwickeln | 273 |
13.3.3 Fachliche Anleitung bieten | 274 |
13.3.4 Die Integrität des Teams bewahren | 275 |
13.4 Die Umgebung ausrichten und anpassen | 275 |
13.4.1 Agile Werte fördern | 275 |
13.4.2 Organisatorische Hindernisse entfernen | 276 |
13.4.3 Die internen Abteilungen ausrichten | 276 |
13.4.4 Die Partner ausrichten | 277 |
13.5 Den Wertschöpfungsfluss organisieren | 277 |
13.5.1 Die Sichtweise des Systems annehmen | 277 |
13.5.2 Die wirtschaftlichen Aspekte organisieren | 278 |
13.5.3 Messungen und Berichte überwachen | 278 |
13.6 Projektmanager | 279 |
13.6.1 Projektmanagementaufgaben in einem Scrum-Team | 279 |
13.6.2 Eine getrennte Projektmanager-Rolle bewahren | 281 |
13.7 Abschließende Bemerkungen | 285 |
Teil III: Planen | 287 |
Kapitel 14: Scrum-Planungsprinzipien | 289 |
14.1 Überblick | 289 |
14.2 Gehen Sie nicht davon aus, dass im Voraus erstellte Pläne korrekt sind | 290 |
14.3 Die Vorabplanung sollte hilfreich, aber nicht exzessiv sein | 290 |
14.4 Halten Sie sich die Planungsoptionen bis zum letzten verantwortbaren Augenblick offen | 291 |
14.5 Konzentrieren Sie sich stärker auf das Anpassen und Neuplanen als darauf, einem Plan zu genügen | 291 |
14.6 Den Planungsbestand richtig organisieren | 294 |
14.7 Bevorzugen Sie kleinere und häufigere Releases | 295 |
14.8 Lernen Sie schnell dazu und weichen Sie vom Plan ab, wenn es nötig sein sollte | 297 |
14.9 Abschließende Bemerkungen | 297 |
Kapitel 15: Planung auf mehreren Ebenen | 299 |
15.1 Überblick | 299 |
15.2 Portfolio-Planung | 301 |
15.3 Produktplanung (Visionsbildung) | 301 |
15.3.1 Die Vision | 301 |
15.3.2 Allgemeines Product Backlog | 302 |
15.3.3 Produkt-Roadmap | 302 |
15.4 Release-Planung | 304 |
15.5 Sprint-Planung | 306 |
15.6 Tägliche Planung | 306 |
15.7 Abschließende Bemerkungen | 307 |
Kapitel 16: Portfolio-Planung | 309 |
16.1 Überblick | 309 |
16.1.1 Das Timing | 309 |
16.1.2 Teilnehmer | 310 |
16.1.3 Der Prozess | 310 |
16.2 Zeitplanungsstrategien | 312 |
16.2.1 Optimierung der Rendite über die Lebensdauer | 313 |
16.2.2 Kalkulation der Verzögerungskosten | 314 |
16.2.3 Schätzungen mit Genauigkeit statt Präzision | 317 |
16.3 Zuflussstrategien | 318 |
16.3.1 Den wirtschaftlichen Filter anwenden | 318 |
16.3.2 Zufluss- und Abflussrate ausbalancieren | 319 |
16.3.3 Sich bietende Gelegenheiten schnell ergreifen | 321 |
16.3.4 Planen Sie kleinere, häufigere Releases | 322 |
16.4 Abflussstrategien | 324 |
16.4.1 Auf unerledigte Arbeit konzentrieren, nicht auf untätige Mitarbeiter | 324 |
16.4.2 Einrichten eines WIP-Limits | 324 |
16.4.3 Auf ein komplettes Team warten | 325 |
16.5 Strategien zur Überprüfung der in Bearbeitung befindlichen Produkte | 326 |
16.5.1 Die Grenznutzenrechnung verwenden | 327 |
16.6 Abschließende Bemerkungen | 328 |
Kapitel 17: Visionsfindung (Produktplanung) | 331 |
17.1 Überblick | 331 |
17.1.1 Das Timing | 332 |
17.1.2 Teilnehmer | 332 |
17.1.3 Der Prozess | 334 |
17.2 SR4U-Beispiel | 334 |
17.3 Die Entwicklung der Vision | 336 |
17.4 Erstellen eines allgemeinen Product Backlogs | 338 |
17.5 Die Definition der Produkt-Roadmap | 339 |
17.6 Andere Aktivitäten | 342 |
17.7 Wirtschaftlich vernünftige Visionsfindung | 344 |
17.7.1 Eine realistische Vertrauensschwelle anstreben | 345 |
17.7.2 Konzentrieren Sie sich auf einen kurzfristigen Planungshorizont | 346 |
17.7.3 Handeln Sie schnell | 347 |
17.7.4 Erwerben Sie validiertes Wissen | 347 |
17.7.5 Nutzen Sie eine inkrementelle Finanzierung | 348 |
17.7.6 Lernen Sie schnell dazu und weichen Sie ggf. vom Plan ab (aka Schnelles Scheitern) | 350 |
17.8 Abschließende Bemerkungen | 350 |
Kapitel 18: Release-Planung (längerfristige Planung) | 351 |
18.1 Überblick | 351 |
18.1.1 Das Timing | 352 |
18.1.2 Teilnehmer | 352 |
18.1.3 Der Prozess | 353 |
18.2 Release-Einschränkungen | 355 |
18.2.1 Alles fest | 355 |
18.2.2 Umfang und Termin fest | 356 |
18.2.3 Fester Umfang | 357 |
18.2.4 Fester Termin | 358 |
18.2.5 Variable Qualität | 358 |
18.2.6 Einschränkungen aktualisieren | 358 |
18.3 Das Product Backlog pflegen | 359 |
18.4 Die minimal freigebbaren Funktionen (Minimum Releasable Features, MRFs) verfeinern | 360 |
18.5 Sprint Mapping (Einordnung der Product-Backlog-Elemente) | 361 |
18.6 Release-Planung mit festem Termin | 363 |
18.7 Release-Planung mit festem Umfang | 368 |
18.8 Die Kosten berechnen | 370 |
18.9 Kommunizieren | 371 |
18.9.1 Den Fortschritt in einem Release mit festem Umfang kommunizieren | 371 |
18.9.2 Den Fortschritt in einem Release mit festem Termin kommunizieren | 374 |
18.10 Abschließende Bemerkungen | 375 |
Teil IV: Sprints | 377 |
Kapitel 19: Die Sprint-Planung | 379 |
19.1 Überblick | 379 |
19.1.1 Das Timing | 379 |
19.1.2 Teilnehmer | 379 |
19.1.3 Der Prozess | 380 |
19.2 Ansätze für die Sprint-Planung | 382 |
19.2.1 Zweiteilige Sprint-Planung | 382 |
19.2.2 Einteilige Sprint-Planung | 383 |
19.3 Die Kapazität ermitteln | 384 |
19.3.1 Was ist die Kapazität? | 384 |
19.3.2 Kapazität in Story-Punkten | 386 |
19.3.3 Die Kapazität in Aufwandsstunden | 386 |
19.4 Product-Backlog-Elemente auswählen | 387 |
19.5 Zuversicht erwerben | 388 |
19.6 Das Sprint-Ziel verfeinern | 390 |
19.7 Die Verpflichtung finalisieren | 390 |
19.8 Abschließende Bemerkungen | 390 |
Kapitel 20: Die Sprint-Ausführung | 391 |
20.1 Überblick | 391 |
20.1.1 Das Timing | 391 |
20.1.2 Teilnehmer | 392 |
20.1.3 Der Prozess | 392 |
20.2 Die Planung der Sprint-Ausführung | 393 |
20.3 Flow-Management | 393 |
20.3.1 Parallele Arbeit und Ausschwärmen | 394 |
20.3.2 Welche Arbeit begonnen werden soll | 396 |
20.3.3 Wie man die Arbeit an den Aufgaben organisiert | 397 |
20.3.4 Welche Arbeit muss erledigt werden? | 397 |
20.3.5 Wer erledigt die Arbeit? | 398 |
20.4 Daily Scrum | 398 |
20.5 Die Durchführung der Aufgaben – Technische Praktiken | 399 |
20.6 Kommunizieren | 400 |
20.6.1 Task Board | 400 |
20.6.2 Das Sprint-Burndown-Chart | 401 |
20.6.3 Das Sprint-Burnup-Chart | 404 |
20.7 Abschließende Bemerkungen | 405 |
Kapitel 21: Sprint Review | 407 |
21.1 Überblick | 407 |
21.2 Teilnehmer | 408 |
21.3 Vorarbeiten | 409 |
21.3.1 Entscheiden, wen man einlädt | 410 |
21.3.2 Die Aktivität zeitlich planen | 410 |
21.3.3 Bestätigen, dass die Sprint-Arbeit erledigt ist | 411 |
21.3.4 Auf die Demonstration vorbereiten | 412 |
21.3.5 Festlegen, wer was macht | 412 |
21.4 Das Vorgehen | 412 |
21.4.1 Zusammenfassen | 413 |
21.4.2 Demonstrieren | 414 |
21.4.3 Diskutieren | 415 |
21.4.4 Ändern | 415 |
21.5 Sprint-Review-Probleme | 416 |
21.5.1 Abnahmen der PBIs | 416 |
21.5.2 Sporadische Teilnahme | 416 |
21.5.3 Umfangreiche Entwicklungsprojekte | 417 |
21.6 Abschließende Bemerkungen | 417 |
Kapitel 22: Die Sprint-Retrospektive | 419 |
22.1 Überblick | 419 |
22.2 Teilnehmer | 421 |
22.3 Die Vorarbeit | 422 |
22.3.1 Den Fokus der Retrospektive definieren | 422 |
22.3.2 Die Übungen auswählen | 423 |
22.3.3 Objektive Daten sammeln | 423 |
22.3.4 Die Retrospektive strukturieren | 424 |
22.4 Das Vorgehen | 425 |
22.4.1 Die Atmosphäre gestalten | 426 |
22.4.2 Gemeinsamer Kontext | 427 |
22.4.3 Einsichten identifizieren | 429 |
22.4.4 Aktionen festlegen | 432 |
22.4.5 Die Retrospektive schließen | 435 |
22.5 Dranbleiben | 435 |
22.6 Probleme der Sprint-Retrospektive | 436 |
22.7 Abschließende Bemerkungen | 438 |
Kapitel 23: Der Weg nach vorn | 439 |
23.1 Es gibt keinen Endzustand | 439 |
23.2 Finden Sie Ihren eigenen Weg | 440 |
23.3 Best Practices mit anderen teilen | 440 |
23.4 Mit Scrum den Weg nach vorn finden | 441 |
23.5 Immer weiter! | 443 |
Anhang A: Referenzen | 445 |
Anhang B: Glossar | 449 |
Stichwortverzeichnis | 471 |