Sie sind hier
E-Book

Scrum mit User Stories

AutorRalf Wirdemann
VerlagCarl Hanser Fachbuchverlag
Erscheinungsjahr2017
Seitenanzahl287 Seiten
ISBN9783446450776
FormatPDF
KopierschutzWasserzeichen/DRM
GerätePC/MAC/eReader/Tablet
Preis25,99 EUR
Scrum als Framework für die Agile Softwareentwicklung kombiniert mit User Stories als ein unschlagbares Doppel:
Scrum definiert mit Hilfe einfacher Regeln und klarer Verantwortlichkeiten einen Rahmen für agile Softwareprojekte. User Stories beschreiben Anforderungen aus Sicht des Benutzers und liefern einen greifbaren Mehrwert.
- Dieses Buch erklärt die Grundlagen beider Konzepte und beschreibt, wie Sie User Stories in die Elemente und Abläufe von Scrum einbinden. Angefangen vom Schreiben und Priorisieren eines User-Story-basierten Product Backlog bis hin zur User-Story-getriebenen Sprint- und Releaseplanung lernen Sie alles, was für den erfolgreichen Einsatz von User Stories in Ihrem Scrum-Projekt wichtig ist.
- Erfahren Sie, wie Sie Anforderungen im Sinne des Kunden mit Hilfe von User Stories beschreiben und im Product Backlog verwalten.
- Erfahren Sie, wie User Stories den Flow eines Scrum-Projekts steuern und das Team bei der Entwicklung werthaltiger Software leiten.
- Lernen Sie, wie Sie die Geschäftsregeln einer User Story als Akzeptanztests beschreiben und so die Basis für Akzeptanztest-getriebene Entwicklung schaffen.
- Erlernen Sie die Anwendung von Story Maps als neue Methode zur ganzheitlichen Anforderungsanalyse.
- Erfahren Sie in einem Praxisbericht von Dr. Mainusch, wie Scrum in großen, aus mehreren Teams bestehenden Projektenbei Bosch funktioniert.
Egal ob man Scrum und User-Stories einsetzt oder nicht: Mit diesem Buch lernt wohl jeder noch etwas dazu.

Ralf Wirdemann ist erfahrener Software-Coach mit dem Schwerpunkt agile Softwareentwicklung. Er hat Scrum bereits in einer Reihe von Projekten eingeführt. Er ist Autor zahlreicher Fachartikel und gefragter Sprecher auf Konferenzen.

Kaufen Sie hier:

Horizontale Tabs

Blick ins Buch
Inhaltsverzeichnis
Inhalt6
Vorwort zur 3. Auflage16
1 Einführung18
1.1 Warum dieses Buch?19
1.2 Struktur und Aufbau20
1.3 Dankeschön22
1.4 Feedback23
2 Beispiel: Scrumcoaches.com24
2.1 Das Projekt25
2.2 Der Entwicklungsprozess26
2.3 Die Beteiligten26
2.4 Die Anforderungen27
2.5 Priorisieren und Schätzen des Product Backlog28
2.5.1 Priorisieren29
2.5.2 Schätzen30
2.6 Sprint-Planung31
2.6.1 Sprint-Ziel31
2.6.2 Entwicklungsgeschwindigkeit32
2.6.3 Analyse der User Stories32
2.6.4 Design der User Stories32
2.7 Sprint-Durchführung34
2.8 Messen des Sprint-Fortschritts36
2.9 Am Ende des Sprint37
2.9.1 Sprint-Review37
2.9.2 Sprint-Retrospektive37
2.10 Die Arbeit geht weiter39
2.11 Zusammenfassung40
2.12 Wie geht es weiter?40
3 Die Grundlagen von Scrum42
3.1 Was ist Scrum?42
3.2 Scrum, ein Framework?44
3.3 Überblick45
3.3.1 Scrum-Team45
3.3.2 Vision und Product Backlog45
3.3.3 Sprint Planning Meeting46
3.3.4 Sprints47
3.3.5 Daily Scrums47
3.3.6 Sprint-Review48
3.3.7 Sprint-Retrospektive48
3.4 Prinzipien48
3.4.1 Transparenz48
3.4.2 Beobachten und Anpassen49
3.4.3 Timeboxing50
3.4.4 Dinge abschließen50
3.4.5 Maximierung von Geschäftswert51
3.4.6 Teams scheitern nicht52
3.4.7 Ergebnisorientierung52
3.5 Die Rollen53
3.5.1 Das Team54
3.5.2 Der ScrumMaster55
3.5.2.1 Dienstleistender Anführer und Problembeseitiger55
3.5.2.2 Scrum implementieren56
3.5.2.3 Entscheider56
3.5.2.4 Müssen ScrumMaster programmieren können?57
3.5.2.5 Product Owner-Coaching57
3.5.2.6 Belastbare Persönlichkeit57
3.5.2.7 Scrum in der Organisation verbreiten58
3.5.3 Der Product Owner58
3.5.3.1 Den Kunden repräsentieren59
3.5.3.2 User Stories und Product Backlog59
3.5.3.3 Mit dem Team durch den Sprint60
3.5.3.4 Bestimmen, wann was fertig ist60
3.5.4 Nebenrolle Kunde60
3.6 Die ideale Arbeitsumgebung62
3.7 Empirisches Management63
3.8 Zusammenfassung65
3.9 Wie geht es weiter?65
4 User Stories66
4.1 Was sind User Stories?67
4.1.1 Story-Karte68
4.1.2 Konversation69
4.1.3 Akzeptanzkriterien69
4.2 Warum User Stories?70
4.3 User Stories schreiben71
4.3.1 Die Sprache des Kunden72
4.3.2 Benutzerrollen72
4.3.3 User-Story-Muster74
4.3.4 Epics74
4.3.5 Themen76
4.3.6 Wie viel Detail?77
4.3.7 Keine Technik78
4.3.8 Keine Benutzeroberfläche78
4.4 Eigenschaften guter User Stories78
4.4.1 Independent – Unabhängige User Stories78
4.4.2 Negotiable – Verhandelbare User Stories79
4.4.3 Valuable – Wertvolle User Stories79
4.4.4 Estimatable – Schätzbare User Stories80
4.4.5 Small – Kleine User Stories80
4.4.6 Testable – Testbare User Stories81
4.5 Zusammenfassung82
4.6 Wie geht es weiter?82
5 Agiles Schätzen84
5.1 Was ist agiles Schätzen?85
5.1.1 Relative Größe statt Dauer85
5.1.2 Schätzen in Story Points86
5.1.3 Wo bleibt die Dauer?87
5.1.4 Argumentationshilfe für Story Points87
5.2 Schätzen von User Stories88
5.2.1 Größenordnungen und Punktesequenzen89
5.2.2 Planungspoker91
5.2.2.1 Schätzen im Team93
5.2.2.2 Referenz-Story und Triangularisierung93
5.2.2.3 Planungspoker funktioniert95
5.2.3 Wann schätzen?95
5.3 Zusammenfassung96
5.4 Wie geht es weiter?96
6 Agiles Planen98
6.1 Was macht Planung agil?98
6.2 Velocity100
6.2.1 Tatsächliche Velocity100
6.2.2 Angenommene Velocity101
6.2.2.1 Angenommene Velocity = Tatsächliche Velocity102
6.2.2.2 Mittlere Velocity103
6.2.3 Velocity-basierte Planung104
6.2.4 Nachhaltige Velocity105
6.3 Agile Planung funktioniert107
6.3.1 Velocity korrigiert Schätzfehler107
6.3.2 Neubewertung von User Stories108
6.3.3 Urlaub, Krankheit und ähnliche Ereignisse109
6.3.4 Der Plan entsteht109
6.4 Zusammenfassung110
6.5 Wie geht es weiter?110
7 User Stories fürs Product Backlog112
7.1 Das Product Backlog112
7.2 Das Product Backlog füllen115
7.2.1 Anforderungsworkshops116
7.2.2 Interviews, Markt-Feedback und Abstimmungsrunden117
7.2.3 Überarbeitung und Pflege des Product Backlog118
7.3 User Stories priorisieren119
7.3.1 Finanzieller Wert119
7.3.2 Kosten120
7.3.3 Kundenzufriedenheit nach Kano121
7.3.4 Risiko122
7.3.5 Abhängigkeiten123
7.3.6 Priorisierende Faktoren abwägen123
7.3.7 MuSCoW-Priorisierung124
7.4 User Stories schneiden125
7.4.1 Vertikales Schneiden126
7.4.2 Schneiden nach Daten127
7.4.3 Schneiden nach Aufwand128
7.4.4 Schneiden nach Forschungsanteilen128
7.4.5 Schneiden nach Qualität129
7.4.6 Schneiden nach Benutzerrolle130
7.4.7 Schneiden nach Akzeptanzkriterien130
7.4.8 Schneiden nach technischer Voraussetzung131
7.5 Andere Anforderungen132
7.5.1 Anforderungen umformulieren132
7.5.2 Constraints133
7.5.3 Fehler134
7.5.4 Technisches Backlog134
7.6 Zusammenfassung135
7.7 Wie geht es weiter?136
8 User Story Mapping138
8.1 User Story Maps139
8.2 Eine Story Map erstellen140
8.2.1 Schritt 1: User Tasks ermitteln141
8.2.2 Schritt 2: Gruppen bilden – User Activities142
8.2.3 Schritt 3: Ordnung schaffen143
8.2.4 Schritt 4: User Tasks durchlaufen = Geschichten erzählen143
8.2.5 Schritt 5: User Stories schreiben144
8.3 Warum Story Mapping?145
8.3.1 Basis für gute Product Backlogs145
8.3.2 Kleinstmögliche Releases146
8.3.3 Motivation und Einsicht für alle Stakeholder146
8.3.4 Lückenlosigkeit146
8.3.5 Softwarearchitektur147
8.3.6 Multi-Team-Setups147
8.4 Von der Story Map zum Product Backlog147
8.4.1 User Stories schreiben150
8.4.2 Die Story Map ersetzt das Product Backlog150
8.5 Zusammenfassung150
8.6 Wie geht es weiter?151
9 Sprint-Planung152
9.1 Überblick und Ablauf152
9.2 Beteiligte153
9.3 Ergebnisse153
9.4 Vorbereitung156
9.4.1 Sprint Velocity156
9.4.1.1 Anpassen der Velocity156
9.4.1.2 Bugfixing, Refactoring und andere Aufgaben157
9.4.2 Story-Auswahl158
9.4.3 Sprint-Länge159
9.5 Sprint Planning 1160
9.5.1 Ablauf160
9.5.2 Sprint-Ziel – Warum führen wir den Sprint durch?161
9.5.3 Vorstellung, Analyse und Commitment161
9.5.4 Fehler und andere technische Aufgaben163
9.6 Sprint Planning 2164
9.6.1 Ablauf165
9.6.2 Story-Design166
9.6.3 Tasks schneiden167
9.6.3.1 Taskgröße168
9.6.3.2 Schneidetechniken168
9.6.3.3 Ungeplante Tasks169
9.6.4 Tasks schätzen?169
9.6.4.1 Taskschätzungen sind sinnvoll170
9.6.4.2 Taskschätzungen sind unsinnig170
9.6.4.3 Keine Empfehlung171
9.6.5 Das Sprint Backlog172
9.6.6 Fehler und andere technischen Aufgaben verteilen173
9.6.7 Was tun, wenn es länger wird?173
9.7 Abschluss174
9.8 Zusammenfassung175
9.9 Wie geht es weiter?175
10 Sprint-Durchführung176
10.1 Die eigentliche Arbeit beginnt176
10.2 Wer macht was?178
10.2.1 Das Team178
10.2.2 Der Product Owner179
10.2.3 Der ScrumMaster179
10.3 Story für Story Richtung Sprint-Ziel180
10.3.1 Wie viele User Stories zurzeit?181
10.3.2 Arbeit an einer User Story181
10.3.3 Definition of Done181
10.3.4 Abnahme fertiger User Stories182
10.3.4.1 Entwicklertest182
10.3.4.2 Akzeptanztest183
10.3.4.3 QA-Abnahme183
10.3.4.4 Frühestmögliche Fehlerbehebung184
10.4 Daily Scrum184
10.4.1 Aktualisierung des Taskboard185
10.4.2 Ein guter Zeitpunkt186
10.4.3 Ein guter Ort187
10.4.4 Wer ist noch dabei?187
10.4.5 Was macht der ScrumMaster?188
10.5 Unterbrechungen189
10.6 Messen und Anpassen190
10.6.1 Bug- und technische Burndown-Charts191
10.6.2 Was tun, wenn es eng wird?192
10.7 Reguläres Sprint-Ende193
10.8 Sprint-Review194
10.8.1 Vorbereitung194
10.8.2 Ort, Zeitpunkt und Teilnehmer194
10.8.3 Ziel195
10.8.4 Ablauf195
10.9 Das Team organisiert sich196
10.9.1 Verantwortung übernehmen196
10.9.2 Das Team machen lassen und aus Fehlern lernen197
10.9.3 Den Product Owner einbeziehen197
10.9.4 Software-Pull-Systeme198
10.9.5 Das Team bei der Arbeit mit Tasks coachen199
10.9.6 Einzelgespräche199
10.10 Sprint Best Practices200
10.10.1 Source Code Management und Story-Branches200
10.10.2 Kontinuierliches Integrieren201
10.10.3 Automatisierung201
10.10.4 Verständlicher Quellcode202
10.10.5 Elektronische Sprint Backlogs und Burndown-Charts202
10.11 Zusammenfassung203
10.12 Wie geht es weiter?203
11 User Stories Akzeptanztesten204
11.1 Was ist Akzeptanztesten?204
11.1.1 Akzeptanzkriterien205
11.1.1.1 Akzeptanzkriterien sind Erwartungen205
11.1.1.2 Akzeptanzkriterien sind Geschäftsregeln206
11.1.2 Akzeptanztests206
11.1.3 Akzeptanztesten207
11.2 Akzeptanzkriterien schreiben208
11.2.1 Vom Akzeptanzkriterium zum Akzeptanztest208
11.2.2 Merkmale guter Akzeptanzkriterien209
11.2.3 Akzeptanzkriterien auch für Epics?211
11.3 Beispiel: Suche nach Coaches211
11.4 Kleine Bausteine: Auf dem Weg zur DSL212
11.5 Akzeptanztesten während des Sprint213
11.6 Die hohe Schule: Akzeptanztest-getriebene Entwicklung215
11.6.1 ATDD-Beispiel: Suche nach Coaches216
11.6.2 Product Owner love writing Tests?218
11.6.2.1 Alternative JCriteria218
11.7 Lohnt sich das Ganze?219
11.8 Zusammenfassung219
11.9 Wie geht es weiter?220
12 Sprint-Retrospektive222
12.1 Nach dem Sprint ist vor dem Sprint223
12.2 Ablauf von Retrospektiven223
12.3 Retrospektiven vorbereiten225
12.4 Retrospektiven leiten225
12.5 Agenda und Check-in226
12.6 Phase 1: Daten sammeln227
12.6.1 Erstellung einer Timeline228
12.6.2 Erweiterung der Timeline um Energiepunkte229
12.7 Phase 2: Einsichten generieren230
12.7.1 Positiv- / Delta-Liste230
12.7.2 Warum-Fragen231
12.8 Phase 3: Entscheiden, was zu tun ist231
12.9 Phase 4: Ziele formulieren und Aktionen planen232
12.10 Abschluss233
12.11 Themenorientierte Retrospektiven234
12.12 Zusammenfassung235
12.13 Wie geht es weiter?236
13 Agile Releaseplanung238
13.1 Releaseplanung238
13.1.1 Themen-Releases238
13.1.2 Datum-Releases239
13.1.3 Releaseplanungs-Workshop240
13.1.4 Was macht die Planung agil?240
13.2 Planungs-Velocity241
13.2.1 Durchführung von Test-Sprints241
13.2.2 Historische Daten242
13.2.3 Das Team bestimmen lassen242
13.2.4 Auswahl eines Verfahrens242
13.3 Der Releaseplan243
13.4 Sichere Planung244
13.4.1 Sichere Velocity244
13.4.2 Sicherheit durch weniger wichtige User Stories245
13.5 Monitoring und Aktualisierung246
13.6 Zusammenfassung247
13.7 Wie geht es weiter?247
14 Verticals – SCRUM@OTTO248
14.1 Warum ich über diese Geschichte schreibe248
14.2 Die Vorgeschichte250
14.3 Das Lhotse-Projekt – Zahlen, Daten, Fakten251
14.4 Das Team – Menschen im Mittelpunkt252
14.5 Triaden – die Führung eines Teams254
14.6 Die Triade – Rollenbeschreibungen254
14.6.1 Der Projektmanager – Project-Lead255
14.6.2 Der Produktmanager – Business-Designer256
14.6.3 Der Team-Architekt – Technical-Designer256
14.7 Die TD-Runde258
14.8 Die Otto-Architektur in Vertikalen259
14.8.1 Warum die klassische IT versagt259
14.8.2 Warum vertikale Schnitte helfen262
14.8.3 Was eine Vertikale ist263
14.8.4 Wie vertikale Schnitte gefunden werden können265
14.9 Makro- und Mikroarchitektur267
14.9.1 Makroarchitektur268
14.9.2 Mikroarchitektur268
14.10 Werte und Leitplanken statt Richtlinien und Governance269
14.11 Das klassische Management in der agiler werdenden Organisation269
14.12 Scrum@Otto – 100 Sprints später271
14.13 Fazit273
Glossar274
Literatur282
Stichwortverzeichnis282

Weitere E-Books zum Thema: Informatik - Algorithmen - Softwaresysteme

Softwaretechnik

E-Book Softwaretechnik
Format: PDF

Software-Projekte geraten oft in Schwierigkeiten: Zeit und Budget werden überschritten; das Projekt tritt auf der Stelle; im schlimmsten Fall wird es ohne Ergebnis abgebrochen. Manche…

Softwaretechnik

E-Book Softwaretechnik
Format: PDF

Software-Projekte geraten oft in Schwierigkeiten: Zeit und Budget werden überschritten; das Projekt tritt auf der Stelle; im schlimmsten Fall wird es ohne Ergebnis abgebrochen. Manche…

Softwaretechnik

E-Book Softwaretechnik
Format: PDF

Software-Projekte geraten oft in Schwierigkeiten: Zeit und Budget werden überschritten; das Projekt tritt auf der Stelle; im schlimmsten Fall wird es ohne Ergebnis abgebrochen. Manche…

Software Engineering

E-Book Software Engineering
Architektur-Design und Prozessorientierung Format: PDF

Das Lehrbuch behandelt alle Aspekte der Software-Entwicklung, besonders aber Methoden und Richtlinien zur Herstellung großer und qualitativ hochwertiger Softwareprodukte. Es vermittelt das zur…

Software Engineering

E-Book Software Engineering
Architektur-Design und Prozessorientierung Format: PDF

Das Lehrbuch behandelt alle Aspekte der Software-Entwicklung, besonders aber Methoden und Richtlinien zur Herstellung großer und qualitativ hochwertiger Softwareprodukte. Es vermittelt das zur…

Weitere Zeitschriften

Menschen. Inklusiv leben

Menschen. Inklusiv leben

MENSCHEN. das magazin informiert über Themen, die das Zusammenleben von Menschen in der Gesellschaft bestimmen -und dies konsequent aus Perspektive der Betroffenen. Die Menschen, um die es geht, ...

Atalanta

Atalanta

Atalanta ist die Zeitschrift der Deutschen Forschungszentrale für Schmetterlingswanderung. Im Atalanta-Magazin werden Themen behandelt wie Wanderfalterforschung, Systematik, Taxonomie und Ökologie. ...

AUTOCAD Magazin

AUTOCAD Magazin

Die herstellerunabhängige Fachzeitschrift wendet sich an alle Anwender und Entscheider, die mit Softwarelösungen von Autodesk arbeiten. Das Magazin gibt praktische ...

Der Steuerzahler

Der Steuerzahler

Der Steuerzahler ist das monatliche Wirtschafts- und Mitgliedermagazin des Bundes der Steuerzahler und erreicht mit fast 230.000 Abonnenten einen weitesten Leserkreis von 1 ...

Die Versicherungspraxis

Die Versicherungspraxis

Behandlung versicherungsrelevanter Themen. Erfahren Sie mehr über den DVS. Der DVS Deutscher Versicherungs-Schutzverband e.V, Bonn, ist der Interessenvertreter der versicherungsnehmenden Wirtschaft. ...

Evangelische Theologie

Evangelische Theologie

Über »Evangelische Theologie« In interdisziplinären Themenheften gibt die Evangelische Theologie entscheidende Impulse, die komplexe Einheit der Theologie wahrzunehmen. Neben den Themenheften ...

F- 40

F- 40

Die Flugzeuge der Bundeswehr, Die F-40 Reihe behandelt das eingesetzte Fluggerät der Bundeswehr seit dem Aufbau von Luftwaffe, Heer und Marine. Jede Ausgabe befasst sich mit der genaue Entwicklungs- ...