Cover: Scrum mit User Stories - Hanser

Scrum mit User Stories

Ralf Wirdemann(Author)

Hanser (Publisher)

4th Edition

Published on 11. July 2022

294 pages

E-Book

PDF with digital watermarking

System requirements

978-3-446-47438-3 (ISBN)

€34.99incl. 7% vat

System requirements

for PDF with digital watermarking

E-Book Single Licence

Available for download

Description

Alles über E-Books | Antworten auf Fragen rund um E-Books, Kopierschutz und Dateiformate finden Sie in unserem Info- & Hilfebereich.

Alles über E-Books, Kopierschutz & Dateiformate finden Sie in unserem Info- & Hilfebereich.

- Erfahren Sie, wie Sie Anforderungen im Sinne des Kunden mit Hilfe von User Stories beschreiben und im Product Backlog verwalten. - Lesen 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 akzeptanzgetriebene Entwicklung schaffen. - Erlernen Sie die Anwendung von Story Maps als neue Methode zur ganzheitlichen Anforderungsanalyse. - Lernen Sie, wie Sie Scrum in mobilen Arbeitsumgebungen einführen und dem Team über die ersten Hürden hinweghelfen. - Ihr exklusiver Vorteil: E-Book inside beim Kauf des gedruckten Buches Scrum als Framework für die Agile Softwareentwicklung erfreut sich zunehmender Beliebtheit. Kombiniert mit User Stories wird daraus 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 Anwendenden 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. Das neue Kapitel "Mobiles Arbeiten" beschäftigt sich mit den Anforderungen und Möglichkeiten des agilen Arbeitens in mobilen Kontexten. Es beschreibt unsere Erfahrungen beim Arbeiten mit mobilen Scrum-Teams und liefert Tipps und Ideen für das Führen solcher Teams. "Egal, ob man Scrum und User Stories einsetzt oder nicht: Mit diesem Buch lernt wohl jeder noch etwas dazu." Steffen Gemkow, ObjectFab AUS DEM INHALT // - Einführung - Beispiel: Scrumcoaches.com - Die Grundlagen von Scrum - User Stories - Agiles Schätzen - Agiles Planen - User Stories für das Product Backlog - User Story Mapping - Sprint-Planung - Sprint-Durchführung - User Stories Akzeptanztesten - Sprint-Retrospektive - Agile Releaseplanung - Mobiles Arbeiten - Verticals - SCRUM@OTTO - Glossar

More details

Other editions

Person

Content

Intro
Inhalt
Vorwort zur 4. Auf?lage
1 Einführung
1.1 Warum dieses Buch?
1.2 Struktur und Aufbau
1.3 Dankeschön
1.4 Feedback
2 Beispiel: Scrumcoaches.com
2.1 Das Projekt
2.2 Der Entwicklungsprozess
2.3 Die Beteiligten
2.4 Die Anforderungen
2.5 Priorisieren und Schätzen des Product Backlog
2.5.1 Priorisieren
2.5.2 Schätzen
2.6 Sprint-Planung
2.6.1 Sprint-Ziel
2.6.2 Entwicklungsgeschwindigkeit
2.6.3 Analyse der User Stories
2.6.4 Design der User Stories
2.7 Sprint-Durchführung
2.8 Messen des Sprint-Fortschritts
2.9 Am Ende des Sprint
2.9.1 Sprint-Review
2.9.2 Sprint-Retrospektive
2.10 Die Arbeit geht weiter
2.11 Zusammenfassung
2.12 Wie geht es weiter?
3 Die Grundlagen von Scrum
3.1 Was ist Scrum?
3.2 Scrum, ein Framework?
3.3 Überblick
3.3.1 Scrum-Team
3.3.2 Vision und Product Backlog
3.3.3 Sprint Planning Meeting
3.3.4 Sprints
3.3.5 Daily Scrums
3.3.6 Sprint-Review
3.3.7 Sprint-Retrospektive
3.4 Prinzipien
3.4.1 Transparenz
3.4.2 Beobachten und Anpassen
3.4.3 Timeboxing
3.4.4 Dinge abschließen
3.4.5 Maximierung von Geschäftswert
3.4.6 Teams scheitern nicht
3.4.7 Ergebnisorientierung
3.5 Die Rollen
3.5.1 Das Team
3.5.2 Der ScrumMaster
3.5.2.1 Dienstleistender Anführer und Problembeseitiger
3.5.2.2 Scrum implementieren
3.5.2.3 Entscheider
3.5.2.4 Müssen ScrumMaster programmieren können?
3.5.2.5 Product Owner-Coaching
3.5.2.6 Belastbare Persönlichkeit
3.5.2.7 Scrum in der Organisation verbreiten
3.5.3 Der Product Owner
3.5.3.1 Den Kunden repräsentieren
3.5.3.2 User Stories und Product Backlog
3.5.3.3 Mit dem Team durch den Sprint
3.5.3.4 Bestimmen, wann was fertig ist
3.5.4 Nebenrolle Kunde
3.6 Die ideale Arbeitsumgebung
3.7 Empirisches Management
3.8 Zusammenfassung
3.9 Wie geht es weiter?
4 User Stories
4.1 Was sind User Stories?
4.1.1 Story-Karte
4.1.2 Konversation
4.1.3 Akzeptanzkriterien
4.2 Warum User Stories?
4.3 User Stories schreiben
4.3.1 Die Sprache des Kunden
4.3.2 Benutzerrollen
4.3.3 User-Story-Muster
4.3.4 Epics
4.3.5 Themen
4.3.6 Wie viel Detail?
4.3.7 Keine Technik
4.3.8 Keine Benutzeroberfläche
4.4 Eigenschaften guter User Stories
4.4.1 Independent - unabhängige User Stories
4.4.2 Negotiable - verhandelbare User Stories
4.4.3 Valuable - wertvolle User Stories
4.4.4 Estimatable - schätzbare User Stories
4.4.5 Small - kleine User Stories
4.4.6 Testable - testbare User Stories
4.5 Zusammenfassung
4.6 Wie geht es weiter?
5 Agiles Schätzen
5.1 Was ist agiles Schätzen?
5.1.1 Relative Größe statt Dauer
5.1.2 Schätzen in Story Points
5.1.3 Wo bleibt die Dauer?
5.1.4 Argumentationshilfe für Story Points
5.2 Schätzen von User Stories
5.2.1 Größenordnungen und Punktesequenzen
5.2.2 Planungspoker
5.2.2.1 Schätzen im Team
5.2.2.2 Referenz-Story und Triangularisierung
5.2.2.3 Planungspoker funktioniert
5.2.3 Wann schätzen?
5.3 Zusammenfassung
5.4 Wie geht es weiter?
6 Agiles Planen
6.1 Was macht Planung agil?
6.2 Velocity
6.2.1 Tatsächliche Velocity
6.2.2 Angenommene Velocity
6.2.2.1 Angenommene Velocity = Tatsächliche Velocity
6.2.2.2 Mittlere Velocity
6.2.3 Velocity-basierte Planung
6.2.4 Nachhaltige Velocity
6.3 Agile Planung funktioniert
6.3.1 Velocity korrigiert Schätzfehler
6.3.2 Neubewertung von User Stories
6.3.3 Urlaub, Krankheit und ähnliche Ereignisse
6.3.4 Der Plan entsteht
6.4 Zusammenfassung
6.5 Wie geht es weiter?
7 User Stories fürs Product Backlog
7.1 Das Product Backlog
7.2 Das Product Backlog füllen
7.2.1 Anforderungsworkshops
7.2.2 Interviews, Markt-Feedback und Abstimmungsrunden
7.2.3 Überarbeitung und Pflege des Product Backlog
7.3 User Stories priorisieren
7.3.1 Finanzieller Wert
7.3.2 Kosten
7.3.3 Kundenzufriedenheit nach Kano
7.3.4 Risiko
7.3.5 Abhängigkeiten
7.3.6 Priorisierende Faktoren abwägen
7.3.7 MuSCoW-Priorisierung
7.4 User Stories schneiden
7.4.1 Vertikales Schneiden
7.4.2 Schneiden nach Daten
7.4.3 Schneiden nach Aufwand
7.4.4 Schneiden nach Forschungsanteilen
7.4.5 Schneiden nach Qualität
7.4.6 Schneiden nach Benutzerrolle
7.4.7 Schneiden nach Akzeptanzkriterien
7.4.8 Schneiden nach technischer Voraussetzung
7.5 Andere Anforderungen
7.5.1 Anforderungen umformulieren
7.5.2 Constraints
7.5.3 Fehler
7.5.4 Technisches Backlog
7.6 Zusammenfassung
7.7 Wie geht es weiter?
8 User Story Mapping
8.1 User Story Maps
8.2 Eine Story Map erstellen
8.2.1 Schritt 1: User Tasks ermitteln
8.2.2 Schritt 2: Gruppen bilden - User Activities
8.2.3 Schritt 3: Ordnung schaffen
8.2.4 Schritt 4: User Tasks durchlaufen = Geschichten erzählen
8.2.5 Schritt 5: User Stories schreiben
8.3 Warum Story Mapping?
8.3.1 Basis für gute Product Backlogs
8.3.2 Kleinstmögliche Releases
8.3.3 Motivation und Einsicht für alle Stakeholder
8.3.4 Lückenlosigkeit
8.3.5 Softwarearchitektur
8.3.6 Multi-Team-Setups
8.4 Von der Story Map zum Product Backlog
8.4.1 User Stories schreiben
8.4.2 Die Story Map ersetzt das Product Backlog
8.5 Zusammenfassung
8.6 Wie geht es weiter?
9 Sprint-Planung
9.1 Überblick und Ablauf
9.2 Beteiligte
9.3 Ergebnisse
9.4 Vorbereitung
9.4.1 Sprint Velocity
9.4.1.1 Anpassen der Velocity
9.4.1.2 Bugfixing, Refactoring und andere Aufgaben
9.4.2 Story-Auswahl
9.4.3 Sprint-Länge
9.5 Sprint Planning 1
9.5.1 Ablauf
9.5.2 Sprint-Ziel - warum führen wir den Sprint durch?
9.5.3 Vorstellung, Analyse und Commitment
9.5.4 Fehler und andere technische Aufgaben
9.6 Sprint Planning 2
9.6.1 Ablauf
9.6.2 Story-Design
9.6.3 Tasks schneiden
9.6.3.1 Taskgröße
9.6.3.2 Schneidetechniken
9.6.3.3 Ungeplante Tasks
9.6.4 Tasks schätzen?
9.6.4.1 Taskschätzungen sind sinnvoll
9.6.4.2 Taskschätzungen sind unsinnig
9.6.4.3 Keine Empfehlung
9.6.5 Das Sprint Backlog
9.6.6 Fehler und andere technischen Aufgaben verteilen
9.6.7 Was tun, wenn es länger wird?
9.7 Abschluss
9.8 Zusammenfassung
9.9 Wie geht es weiter?
10 Sprint-Durchführung
10.1 Die eigentliche Arbeit beginnt
10.2 Wer macht was?
10.2.1 Das Team
10.2.2 Der Product Owner
10.2.3 Der ScrumMaster
10.3 Story für Story Richtung Sprint-Ziel
10.3.1 Wie viele User Stories zurzeit?
10.3.2 Arbeit an einer User Story
10.3.3 Definition of Done
10.3.4 Abnahme fertiger User Stories
10.3.4.1 Entwicklertest
10.3.4.2 Akzeptanztest
10.3.4.3 QA-Abnahme
10.3.4.4 Frühestmögliche Fehlerbehebung
10.4 Daily Scrum
10.4.1 Aktualisierung des Taskboard
10.4.2 Ein guter Zeitpunkt
10.4.3 Ein guter Ort
10.4.4 Wer ist noch dabei?
10.4.5 Was macht der ScrumMaster?
10.5 Unterbrechungen
10.6 Messen und Anpassen
10.6.1 Bug- und technische Burndown-Charts
10.6.2 Was tun, wenn es eng wird?
10.7 Reguläres Sprint-Ende
10.8 Sprint-Review
10.8.1 Vorbereitung
10.8.2 Ort, Zeitpunkt und Teilnehmer
10.8.3 Ziel
10.8.4 Ablauf
10.9 Das Team organisiert sich
10.9.1 Verantwortung übernehmen
10.9.2 Das Team machen lassen und aus Fehlern lernen
10.9.3 Den Product Owner einbeziehen
10.9.4 Software-Pull-Systeme
10.9.5 Das Team bei der Arbeit mit Tasks coachen
10.9.6 Einzelgespräche
10.10 Sprint Best Practices
10.10.1 Source Code Management und Story-Branches
10.10.2 Kontinuierliches Integrieren
10.10.3 Automatisierung
10.10.4 Verständlicher Quellcode
10.10.5 Elektronische Sprint Backlogs und Burndown-Charts
10.11 Zusammenfassung
10.12 Wie geht es weiter?
11 User Stories Akzeptanztesten
11.1 Was ist Akzeptanztesten?
11.1.1 Akzeptanzkriterien
11.1.1.1 Akzeptanzkriterien sind Erwartungen
11.1.1.2 Akzeptanzkriterien sind Geschäftsregeln
11.1.2 Akzeptanztests
11.1.3 Akzeptanztesten
11.2 Akzeptanzkriterien schreiben
11.2.1 Vom Akzeptanzkriterium zum Akzeptanztest
11.2.2 Merkmale guter Akzeptanzkriterien
11.2.3 Akzeptanzkriterien auch für Epics?
11.3 Beispiel: Suche nach Coaches
11.4 Kleine Bausteine: Auf dem Weg zur DSL
11.5 Akzeptanztesten während des Sprint
11.6 Die hohe Schule: Akzeptanztest-getriebene Entwicklung
11.6.1 ATDD-Beispiel: Suche nach Coaches
11.6.2 Product Owner love writing Tests?
11.6.2.1 Alternative JCriteria
11.7 Lohnt sich das Ganze?
11.8 Zusammenfassung
11.9 Wie geht es weiter?
12 Sprint-Retrospektive
12.1 Nach dem Sprint ist vor dem Sprint
12.2 Ablauf von Retrospektiven
12.3 Retrospektiven vorbereiten
12.4 Retrospektiven leiten
12.5 Agenda und Check-in
12.6 Phase 1: Daten sammeln
12.6.1 Erstellung einer Timeline
12.6.2 Erweiterung der Timeline um Energiepunkte
12.7 Phase 2: Einsichten generieren
12.7.1 Positiv/Delta-Liste
12.7.2 Warum-Fragen
12.8 Phase 3: Entscheiden, was zu tun ist
12.9 Phase 4: Ziele formulieren und Aktionen planen
12.10 Abschluss
12.11 Themenorientierte Retrospektiven
12.12 Zusammenfassung
12.13 Wie geht es weiter?
13 Agile Releaseplanung
13.1 Releaseplanung
13.1.1 Themen-Releases
13.1.2 Datum-Releases
13.1.3 Releaseplanungs-Workshop
13.1.4 Was macht die Planung agil?
13.2 Planungs-Velocity
13.2.1 Durchführung von Test-Sprints
13.2.2 Historische Daten
13.2.3 Das Team bestimmen lassen
13.2.4 Auswahl eines Verfahrens
13.3 Der Releaseplan
13.4 Sichere Planung
13.4.1 Sichere Velocity
13.4.2 Sicherheit durch weniger wichtige User Stories
13.5 Monitoring und Aktualisierung
13.6 Zusammenfassung
13.7 Wie geht es weiter?
14 Mobiles Arbeiten
14.1 Herausforderungen
14.2 Start ins mobile Arbeiten
14.3 Mobiles Arbeiten in Scrum
14.3.1 Werkzeuge
14.3.1.1 Das digitale Whiteboard
14.3.1.2 Das digitale Taskboard
14.3.1.3 Mobiles Pair Programming
14.3.2 Meetings
14.3.2.1 Mobiler Start-Workshop
14.3.2.2 Mobiles Daily Scrum
14.3.2.3 Mobile Sprint-Planung
14.3.2.4 Mobile Retrospektive
14.3.2.5 Beispiel für ein Retrospektive Board
14.3.2.6 Mobiles Review
14.4 Die Zukunft: hybrides Arbeiten
14.4.1 Hybrid starten
14.4.2 Hybrid im Alltag
14.5 Zusammenfassung
14.6 Wie geht es weiter?
15 Verticals - SCRUM@OTTO
15.1 Warum ich über diese Geschichte schreibe
15.2 Die Vorgeschichte
15.3 Das Lhotse-Projekt - Zahlen, Daten, Fakten
15.4 Das Team - Menschen im Mittelpunkt
15.5 Triaden - die Führung eines Teams
15.6 Die Triade - Rollenbeschreibungen
15.6.1 Der Projektmanager - Project-Lead
15.6.2 Der Produktmanager - Business-Designer
15.6.3 Der Team-Architekt - Technical-Designer
15.7 Die TD-Runde
15.8 Die Otto-Architektur in Vertikalen
15.8.1 Warum die klassische IT versagt
15.8.2 Warum vertikale Schnitte helfen
15.8.3 Was eine Vertikale ist
15.8.4 Wie vertikale Schnitte gefunden werden können
15.9 Makro- und Mikroarchitektur
15.9.1 Makroarchitektur
15.9.2 Mikroarchitektur
15.10 Werte und Leitplanken statt Richtlinien und Governance
15.11 Das klassische Management in der agiler werdenden Organisation
15.12 Scrum@Otto - 100 Sprints später
15.13 Fazit
Glossar
Literatur
Stichwortverzeichnis

System requirements

Save as PDF Copy link into clipboard