Sie sind hier

E-Book

Scrum mit User Stories

Autor	Ralf Wirdemann
Verlag	Carl Hanser Fachbuchverlag
Erscheinungsjahr	2017
Seitenanzahl	287 Seiten
ISBN	9783446450776
Format	PDF
Kopierschutz	Wasserzeichen/DRM
Geräte	PC/MAC/eReader/Tablet
Preis	25,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

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

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

Einführung in die Informatik für Naturwissenschaftler und Ingenieure

Format: PDF

Grundlagenwissen im Bereich Informatik Es gibt kaum ein technisches oder naturwissenschaftliches Problem, das nicht von der Informatik beeinflusst wird. Deshalb gehören die Grundlagen der…

Einführung in die Informatik für Naturwissenschaftler und Ingenieure

Format: PDF

Grundlagenwissen im Bereich Informatik Es gibt kaum ein technisches oder naturwissenschaftliches Problem, das nicht von der Informatik beeinflusst wird. Deshalb gehören die Grundlagen der…

Einführung in die Informatik für Naturwissenschaftler und Ingenieure

Format: PDF

Grundlagenwissen im Bereich Informatik Es gibt kaum ein technisches oder naturwissenschaftliches Problem, das nicht von der Informatik beeinflusst wird. Deshalb gehören die Grundlagen der…

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

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

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

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

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…

Corporate Performance Management mit Business Intelligence Werkzeugen

Format: PDF

Vertrauen ist gut - Corporate Performance Management ist besser - Management- und Technologieaspekte werden gemeinsam und verständlich dargestellt - Zahlreiche Praxisbeispiele aus der…

Corporate Performance Management mit Business Intelligence Werkzeugen

Format: PDF

Vertrauen ist gut - Corporate Performance Management ist besser - Management- und Technologieaspekte werden gemeinsam und verständlich dargestellt - Zahlreiche Praxisbeispiele aus der…

Weitere Zeitschriften

FESTIVAL Christmas

Fachzeitschriften für Weihnachtsartikel, Geschenke, Floristik, Papeterie und vieles mehr! FESTIVAL Christmas: Die erste und einzige internationale Weihnachts-Fachzeitschrift seit 1994 auf dem ...

A&D - Automation & Digitalisierung

Rubriken: Digital Factory - Industrielle Softwarelösungen - Robotik & Handling - Antreiben & Bewegen - Industrielle Kommunikation - Steuerungstechnik - Sensorik & Messtechnik - ...

Altenheim - Lösungen fürs Management

Altenheim ist die Fachzeitschrift für Träger, Heimleitungen und leitende Mitarbeiter/innen der teilstationären und stationären Altenhilfe. Hier erfahren Sie, wie Sie Ihre Einrichtung zu ...

arznei-telegramm

Das arznei-telegramm® informiert bereits im 53. Jahrgang Ärzte, Apotheker und andere Heilberufe über Nutzen und Risiken von Arzneimitteln. Das arznei-telegramm® ist neutral und ...

aufstieg

Zeitschrift der NaturFreunde in Württemberg Die Natur ist unser Lebensraum: Ort für Erholung und Bewegung, zum Erleben und Forschen; sie ist ein schützenswertes Gut. Wir sind aktiv in der Natur ...

care konkret

care konkret ist die Wochenzeitung für Entscheider in der Pflege. Ambulant wie stationär. Sie fasst topaktuelle Informationen und Hintergründe aus der Pflegebranche kompakt und kompetent für Sie ...

SPORT in BW (Württemberg)

SPORT in BW (Württemberg) ist das offizielle Verbandsorgan des Württembergischen Landessportbund e.V. (WLSB) und Informationsmagazin für alle im Sport organisierten Mitglieder in Württemberg. ...

ea evangelische aspekte

evangelische Beiträge zum Leben in Kirche und Gesellschaft Die Evangelische Akademikerschaft in Deutschland ist Herausgeberin der Zeitschrift evangelische aspekte Sie erscheint viermal im Jahr. In ...

building & automation

Das Fachmagazin building & automation bietet dem Elektrohandwerker und Elektroplaner eine umfassende Übersicht über alle Produktneuheiten aus der Gebäudeautomation, der Installationstechnik, dem ...

Euro am Sonntag

Deutschlands aktuelleste Finanz-Wochenzeitung Jede Woche neu bietet €uro am Sonntag Antworten auf die wichtigsten Fragen zu den Themen Geldanlage und Vermögensaufbau. Auch komplexe Sachverhalte ...