Scrum mit User Stories E-Book

Ralf Wirdemann

• Herausgeber: Carl Hanser Verlag GmbH & Co. KG
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Deutsch
• Veröffentlichungsjahr: 2022

Seitenzahl: 502

Beschreibung

- 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

Leseprobe

Ralf WirdemannAstrid RitscherJohannes Mainusch

Scrum mit User Stories

4., überarbeitete und erweiterte Auflage

Die Autor*innen:

Dipl.-Inform. Ralf Wirdemann, [email protected]

Dipl.-Inform. Astrid Ritscher, [email protected]

Dr. Johannes Mainusch, [email protected]

Alle in diesem Buch enthaltenen Informationen, Verfahren und Darstellungen wurden nach bestem Wissen zusammengestellt und mit Sorgfalt getestet. Dennoch sind Fehler nicht ganz auszuschließen. Aus diesem Grund sind die im vorliegenden Buch enthaltenen Informationen mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden. Autor:innen und Verlag übernehmen infolgedessen keine juristische Verantwortung und werden keine daraus folgende oder sonstige Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieser Informationen – oder Teilen davon – entsteht. Ebenso übernehmen Autor:innen und Verlag keine Gewähr dafür, dass beschriebene Verfahren usw. frei von Schutzrechten Dritter sind. Die Wiedergabe von Gebrauchsnamen, Handelsnamen,Warenbezeichnungen usw. in diesem Buch berechtigt deshalb auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.

Bibliografische Information der Deutschen Nationalbibliothek:Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

Dieses Werk ist urheberrechtlich geschützt.Alle Rechte, auch die der Übersetzung, des Nachdruckes und der Vervielfältigung des Buches, oder Teilen daraus, vorbehalten. Kein Teil des Werkes darf ohne schriftliche Genehmigung des Verlages in irgendeiner Form (Fotokopie, Mikrofilm oder ein anderes Verfahren) – auch nicht für Zwecke der Unterrichtsgestaltung – reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden.

© 2022 Carl Hanser Verlag München, www.hanser-fachbuch.deLektorat: Brigitte Bauer-SchiewekCopy editing: Petra Kienle, FürstenfeldbruckLayout: le-tex publishing services GmbHUmschlagdesign: Marc Müller-Bremer, www.rebranding.de, MünchenUmschlagrealisation: Max Kostopoulos

Print-ISBN:        978-3-446-47369-0E-Book-ISBN:   978-3-446-47438-3E-Pub-ISBN:     978-3-446-47526-7

Inhalt

Titelei

Impressum

Inhalt

Vorwort zur 4. Auflage

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.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.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

Vorwort zur 4. Auflage

Wenn diese 4. Ausgabe von Scrum mit User Stories erscheint, hat sich nach mehr als zwei Jahren Pandemie ein Teil der Arbeitswelt stark verändert, insbesondere Arbeit, die sich dank Informationstechnologie vom Büro nach Hause verlagern lässt. Und es ist abzusehen, dass mobiles Arbeiten bleibt und hybride Arbeitsweisen, die es Teammitgliedern ermöglichen, von zu Hause oder aus dem Büro miteinander zu arbeiten, weiterentwickelt werden.

Softwareteams standen Anfang 2020 von heute auf morgen vor der Herausforderung, ihren Arbeitsalltag vom Büro ins Homeoffice zu verlegen. Plötzlich wurden Teams getrennt, für die es zuvor selbstverständlich war, im selben Raum und mit extrem kurzen und effizienten Kommunikationswegen zusammenzuarbeiten. Diese Zäsur der Arbeitswelt ist die Hauptmotivation für die Neuauflage dieses Buches: Nach mehr als zwei Jahren im Homeoffice hatten wir das Bedürfnis aufzuschreiben, was für uns funktioniert hat und worauf es beim mobilen Arbeiten ankommt.

Ich (Ralf) persönlich habe die Umstellung auf das Homeoffice in der Rolle des Entwicklers und Architekten miterlebt. Entsprechend war ich nicht hauptverantwortlich für die Neustrukturierung unserer neuen Arbeitssituation, sondern habe die Umstellung in mehreren Teams aus der zweiten Reihe mehr beobachtend und beratend begleitet. Aus diesem Grund war es mir wichtig, die bei der Mobilisierung agiler Teams entstehenden Herausforderungen aus erster Hand zu bekommen. Es wurde Zeit für eine neue Co-Autorin.

Für die 4. Auflage meines Buches konnte ich dafür Astrid Ritscher gewinnen. Astrid ist Agile-Coach bei der Otto GmbH & Co KG in Hamburg und stand vor gut zwei Jahren vor der Herausforderung, ihre agil arbeitenden Teams auf das mobile Arbeiten vorzubereiten. Astrid hat ihre Erfahrungen mit dem neuen Kapitel „Mobiles Arbeiten“ beigesteuert, in dem sie beschreibt, was sie und ihre Teams in den letzten zwei Jahren gelernt haben.

Das neue Kapitel widmet sich den Auswirkungen mobilen Arbeitens und seinen Anforderungen und Möglichkeiten an die Arbeit eines Teams und seiner Stakeholder mit Scrum. Für mobiles Arbeiten allgemein und die Besonderheiten von Scrum-Meetings und anderen agilen Arbeitsweisen (z.B. Pairing) werden Alternativen, Ideen und Empfehlungen vorgestellt. Der letzte Abschnitt des Kapitels geht auf hybrides Arbeiten ein.

Wir hoffen, Ihnen mit diesem neuen Thema eine weitere wichtige Facette der Agilen Softwareentwicklung näherzubringen, die Ihnen bei dem Neueinstieg oder der Optimierung Ihrer agilen Arbeitswelt behilflich ist.

Hinweis zur Verwendung geschlechterneutraler Sprache

Wenn bei personellen Bezeichnungen die männliche Form gewählt wurde (z.B.Mitarbeiter, Techniker), so sind damit in gleicher Weise weibliche Mitarbeiter oder Transgender-Mitarbeiter gemeint.

Hamburg, im Mai 2022

Ralf Wirdemann, Astrid Ritscher und Dr. Johannes Mainusch

1Einführung

Das vorliegende Buch vereint zwei erfolgreiche Konzepte der Agilen Softwareentwicklung: Scrum und User Stories. Scrum ist ein Framework für das Management agiler Softwareprojekte. User Stories sind in der Sprache des Anwenders formulierte Anforderungen an das zu entwickelnde Softwaresystem. Ein in der Praxis erprobtes und häufig durchgeführtes Vorgehen ist die Verwendung von User Stories im Product Backlog als zentrales Werkzeug für die Planung und Priorisierung der Anforderungen eines Scrum-Projekts.

Anforderungen und Anforderungsmanagement sind die treibende Kraft in Software-Projekten. In Bezug auf Anforderungen beschränkt sich Scrum auf die Beschreibung, wie Anforderungen verwaltet werden, geht aber nicht darauf ein, woher sie kommen, wie man sie findet oder wie sie formuliert werden. Scrum ist ein sehr offenes Framework und macht bewusst keine Vorgaben über Art und Inhalt der Anforderungen im Product Backlog, dem zentralen Anforderungskatalog in Scrum. Dieses Buch optimiert Scrum hinsichtlich eines kundenorientierten Anforderungsmanagements, indem es die Verwendung von User Stories anstelle von „allgemeinen Items“ im Product Backlog vorschlägt. Dieser Ansatz ist sehr erfolgreich und in der Praxis weit verbreitet. Warum ist das so?

Schaltzentrale Product Owner

Entscheidend für die Beantwortung dieser Frage ist die Rolle des Product Owner, dem die Verwaltung des Product Backlog unterliegt. Der Product Owner eines Scrum-Projekts repräsentiert den Kunden und verfolgt dessen Interessen. Kunden denken geschäftsorientiert, das heißt, ein Kunde will wissen, was ihm die Umsetzung einer bestimmten Anforderung bringt. Und genau an diesem Punkt bieten User Stories einen entscheidenden Vorteil: Jede Story beschreibt einen greifbaren Mehrwert für den Kunden. Ein User-Story-basiertes Backlog macht es für den Product Owner viel einfacher, Entscheidungen zu treffen und Stories zu priorisieren, da er User Stories im Sinne einer wirtschaftlichen Kosten-Nutzen-Rechnung bewerten und einander gegenüberstellen kann.

Product Owner sind keine Techniker, das heißt, ein Product Owner kann im Regelfall mit der Anforderung „Refactoring der Datenbank-Zugriffsschicht“ wenig anfangen. Gelingt es uns aber, diese Refactoring-Aufgabe als Teil einer Mehrwert-erbringenden User Story zu formulieren, dann fällt es dem Product Owner wesentlich leichter, die Sinnhaftigkeit dieser Anforderung zu erkennen und sie entsprechend zu priorisieren.

Scrum mit User Stories kombinieren

User Stories spielen ihre Vorteile in unterschiedlichen Phasen und Elementen von Scrum aus: Product Backlogs enthalten sinnvolle, das heißt Geschäftswert-steigernde Produkterweiterungen. Die Sprint-Planung wird effektiver, da greifbarer Mehrwert analysiert und diskutiert wird. Eine an User Stories ausgerichtete Sprint-Durchführung ist zielgerichtet und lässt sich sinnvoll und mit Hilfe einfacher Regeln organisieren. Akzeptanztests orientieren sich an User Stories und geben vor, wann eine Story fertig und für den Anwender benutzbar ist.

Neben der Beschreibung, wie User Stories in den unterschiedlichen Phasen und Elementen von Scrum verwendet werden, ist das agile Schätzen und Planen mit Scrum und User Stories ein weiterer Schwerpunkt dieses Buches. Das Buch erklärt, wie ein Product Backlog in Story Points geschätzt wird, wie die Entwicklungsgeschwindigkeit eines Teams bestimmt und angepasst wird und wie sich basierend auf diesen Zahlen ein agiler Releaseplan sowie eine konkrete Sprint-Planung erstellen lassen.

Viele der Ideen in diesem Buch stammen von Ken Schwaber, Jeff Sutherland und Mike Beedle, den Begründern von Scrum, sowie von Mike Cohn, der für die zunehmende Popularität von User Stories verantwortlich ist. Was ich mit diesem Buch anbiete, ist eine Beschreibung, wie sich diese Ideen fortführen und effektiv kombinieren lassen und im Sinne eines hoch produktiven Softwareentwicklungsprozesses genutzt werden können.

1.1Warum dieses Buch?

User Stories sind eine in der Scrum-Gemeinschaft weit verbreitete Methode des Anforderungsmanagements. Egal, wohin Sie gucken, welches Forum Sie lesen oder in welches Scrum-Projekt Sie kommen, fast überall werden Anforderungen als User Stories beschrieben und im Product Backlog verwaltet. Schaut man sich hingegen die Literatur zum Thema an, dann findet man viele Bücher zu beiden Themen, aber bisher kein Buch, das die Themen kombiniert.

Ich habe während meiner Arbeit mit Scrum und User Stories gelernt, dass es viele Fragen gibt, die aus der Kombination dieser beiden Themen resultieren: Wie werden User Stories geschätzt und woher weiß ich, wie viele Stories in einen Sprint passen? Wie funktioniert eine effektive Sprint-Planung mit User Stories? Wie wird die Fehlerbehebung organisiert und geplant? Wie wirkt sich das auf die Entwicklungsgeschwindigkeit des Teams aus und muss ich das vorher berücksichtigen? Dies sind Beispiele für Fragen, auf die mir keines der existierenden Bücher Antworten liefern konnte. Entsprechend haben wir in den letzten Jahren sehr viel experimentiert und dazugelernt, indem wir uns für jeden Sprint etwas Neues überlegt und ausprobiert haben.

Sicher ist es so, dass jedes Team für sich und je nach Projektsituation seinen eigenen Weg finden muss. Dennoch denke ich, dass es eine Reihe bewährter Praktiken gibt, die wie in diesem Buch beschrieben oder entsprechend angepasst, auch in vielen anderen Projekten funktionieren und nicht von jedem Team mühsam aufs Neue erarbeitet werden müssen.

Dieses Buch beschreibt Scrum, so wie wir es benutzen, erhebt dabei aber keinen Anspruch auf Vollständigkeit oder darauf, den einzig richtigen Scrum-Weg zu beschreiben. Selbst wenn die beschriebenen Ansätze für Ihre Teams nicht immer funktionieren, so hege ich dennoch die Hoffnung, dass das Buch genügend Anreize und Impulse für die Entwicklung der für Sie funktionierenden Ideen liefert.

Die Arbeit mit User Stories hat mir darüber hinaus gezeigt, wie wichtig der Product Owner und dessen enge Zusammenarbeit mit dem Team ist. User Stories stellen den Product Owner in den Mittelpunkt des Geschehens und beziehen ihn eng in die Entwicklung und den Sprint mit ein. Dies ist ein Aspekt, den ich selbst erst lernen musste und deshalb in diesem Buch entsprechend darlegen will. Die Aufgabe des ScrumMaster ist es nicht nur, sich um das Team zu kümmern, sondern darüber hinaus, den Product Owner sehr stark in den Sprint mit einzubinden und dafür zu sorgen, dass Team und Product Owner eng zusammenarbeiten.

Das Schwierige an Scrum ist nicht, den Prozess zu verstehen, sondern ihn anzuwenden. Dieses Buch ist keine weitere theoretische Einführung in Scrum, sondern beschreibt einen praxiserprobten Ansatz. Es geht weniger um das „Was“ als um das „Wie“: Wie wende ich Scrum kombiniert mit User Stories erfolgreich an. „Scrum mit User Stories“ ist ein Handbuch für die Praxis, das beschreibt, wie wir Scrum einsetzen und wie die Kombination von Scrum und User Stories für uns funktioniert. Das Buch soll den Product Owner inspirieren, User Stories zu verwenden und im Rahmen von Scrum umzusetzen. Es soll CTOs motivieren, Scrum in zukünftigen Projekten auszuprobieren und Anforderungen mit Hilfe von User Stories zu beschreiben. Und das Buch soll dem Team dabei helfen, Spaß an der Arbeit zu haben, und durch die Verwendung von User Stories das Gefühl erzeugen, jeden Tag etwas Sinnvolles und Verwendbares zu produzieren.

1.2Struktur und Aufbau

Neben diesem Einführungskapitel enthält das Buch elf weitere Kapitel, die sich in vier logische Teile gliedern.

Teil 1: Grundlagen

Das Buch beginnt mit einem Grundlagenteil, bestehend aus einem Beispiel und einer allgemeinen Einführung in Scrum und User Stories. Das Kapitel 2, Beispiel Scrumcoaches.com, ist ein Rundumschlag, der alle in diesem Buch behandelten Themen anhand eines Beispiels kurz und in sehr komprimierter Form anreißt. Das Kapitel liefert einen Überblick dessen, was Sie in diesem Buch erwartet, und steckt den Rahmen des Buches ab.

Neben dem Beispiel enthält der Grundlagenteil die Kapitel 3, Die Grundlagen von Scrum, und Kapitel 4, User Stories. Beide Kapitel führen die Themen Scrum und User Stories zunächst unabhängig voneinander ein und legen so das Fundament für die weiteren Kapitel dieses Buches.

Teil 2: Agiles Schätzen und Planen mit User Stories

Teil 2 des Buches liefert mit Kapitel 5, Agiles Schätzen, und Kapitel 6, Agiles Planen, eine Einführung in das Schätzen und Planen mit User Stories im Kontext von Scrum. Geschätzte User Stories sind die wesentliche Zutat für die Sprint- und Releaseplanung. Das Team entwickelt über die Zeit ein Gefühl dafür, wie viele User Stories welcher Größe es in einem Sprint umsetzen kann, und der Product Owner erstellt basierend auf den vom Team geschätzten User Stories eine über mehrere Sprints hinausgehende Releaseplanung.

Aufbauend auf den Schätz- und Planungs-Kapiteln spannt Kapitel 7, User Stories fürs Product Backlog, den entscheidenden Bogen hin zur Kombination von Scrum und User Stories. Das Kapitel beschreibt, wie ein rein aus User Stories bestehendes Product Backlog erstellt wird und wie die Stories dafür priorisiert und auf die richtige Größe „geschnitten“ werden. Außerdem erklärt das Kapitel den Umgang mit Anforderungen, die sich nicht als User Stories beschreiben lassen.

Das in der 3. Auflage dieses Buches hinzugekommene Kapitel 8User Story Mapping beschreibt ein modernes Verfahren zur Anforderungsanalyse, bei dem von Anfang an ein ganzheitlicher Blick auf das Produkt eingenommen wird. Das Produkt wird dabei in ganzer Breite betrachtet und mit Hilfe von User Tasks visualisiert. Auf diese Art entsteht eine sinnstiftende Produktgeschichte, die verschiedensten Stakeholdern erzählt und mit ihnen gemeinsam fortgeschrieben wird. Als Ergebnis entsteht eine Story Map, als Basis für Releaseorientiert priorisierte Product Backlogs mit User Stories.

Teil 3: Sprint-Planung und -Durchführung

Das Herz und der Rhythmus von Scrum sind bestimmt durch Sprints, die eigentlichen Entwicklungsphasen in Scrum. Dieser Teil des Buches besteht aus vier Kapiteln, die sich mit der Planung und Durchführung von Sprints, dem Akzeptanztesten der im Sprint umgesetzten User Stories sowie dem Rückblick auf den Entwicklungsprozess beschäftigen. Das Kapitel 9, Sprint-Planung, beschreibt den zu Beginn eines Sprint durchgeführten Planungsworkshop, in dem das Scrum-Team die anstehenden User Stories analysiert und deren Software-Design erstellt. Weiter geht es mit Kapitel 10, Sprint-Durchführung, in dessen Mittelpunkt das Team und seine selbstorganisierte Arbeit stehen. Im Sprint arbeitet das Team in enger Zusammenarbeit mit dem Product Owner an der Umsetzung der geplanten User Stories und liefert zum Sprint-Ende getestete und funktionierende Software aus. Das Ergebnis des Sprint wird in einem öffentlichen Sprint-Review präsentiert, in dem alle Stakeholder zusammenkommen und Einfluss auf den weiteren Verlauf des Projekts nehmen.

Vor der abschließenden Sprint-Retrospektive führt Kapitel 11, User Stories Akzeptanztesten, einen Exkurs zum Thema Akzeptanztesten durch. Akzeptanztesten ist weit mehr als eine reine Testdisziplin und beginnt bereits vor dem Sprint mit dem Schreiben von Akzeptanzkriterien und Akzeptanztests. Akzeptanzkriterien geben den roten Faden vor und zeigen dem Team, worauf es bei jeder Story ankommt. Akzeptanztests erklären die einzelnen Akzeptanzkriterien anhand konkreter Beispiele und bilden die Basis für den abschließenden Abnahmetest der User Stories.

Zum Abschluss jedes Sprint wirft das Team einen in Kapitel 12, Sprint-Retrospektive, beschriebenen Rückblick auf seinen Entwicklungsprozess und analysiert, was gut war und was es in Zukunft zu verbessern gilt.

Teil 4: Releaseplanung

Der vorletzte Teil des Buches besteht aus einem einzigen Kapitel. Das Kapitel 13, Agile Releaseplanung, beschreibt die Releaseplanung in Scrum mit Hilfe von User Stories. Ziel der Releaseplanung ist die Erstellung eines Releaseplans, der beschreibt, zu welchem Zeitpunkt welche User Stories voraussichtlich geliefert werden.Der Kunde kann sich mit Hilfe des Plans darauf einstellen, was er wann für sein Geld bekommt, und darüber hinaus entscheiden, ob sich das Projekt grundsätzlich für ihn lohnt. Für das Scrum-Team erfüllt ein Releaseplan darüber hinaus die Funktion eines Wegweisers, der die Vision des Projekts aufzeigt und einen über einzelne Sprints hinausgehenden Kontext definiert.

Teil 5: Mobiles Arbeiten

Bis zum März 2020 waren mobil arbeitende Softwareteams die Ausnahme. Diese Ausnahmebedingungen wurden von heute auf morgen zum Normalzustand. Diesem Thema widmet sich das in der 4. Auflage neu hinzugekommene Kapitel 14, Mobiles Arbeiten. Das Kapitel beschreibt die Mobilisierung agil arbeitender Softwareteams und richtet den Fokus dabei speziell auf Scrummit seinen Abläufen und Meetings.

Teil 6: Fallbeispiel

Im letzten Teil dieses Buches berichtet Johannes Mainusch von seinen Erfahrungen als Entwicklungsleiter beim Relaunch des E-Commerce-Shopsystems von Otto in Hamburg. In Hochzeiten arbeiteten mehr als 60 Entwickler, aufgeteilt auf bis zu zehn Teams in diesem Projekt. Die Größe des Projekts erforderte nicht nur eine bestimmte Organisationsform, sondern auch eine auf diese Organisationsform abgestimmte Softwarearchitektur. Johannes beschreibt in diesem Kapitel, wie Scrum bei Otto eingesetzt und an die speziellen Gegebenheiten angepasst wurde.

1.3Dankeschön

Viele Menschen haben mir beim Schreiben dieses Buches geholfen, wertvolles Feedback gegeben und mich über die lange Zeit des Schreibens hin motiviert. Diesen Menschen möchte ich danken. Durch euch ist dieses Buch viel besser geworden.

Ich danke meinen Reviewern Thomas Baustert, Steffen Gemkow, Boris Gloger, Bjarne Jansen, Bernd Oestereich, Uwe Petschke, Hubert Rosicka, Katja Roth, Dr. Gernot Starke, Sascha Teske, Hans-Martin Winkler, Henning Wolf und Henning Zuzmann.

Ich danke meinen Lektorinnen Margarete Metzger und Brigitte Bauer-Schiewek für die gute Zusammenarbeit und das vor langer Zeit in mich gesetzte Vertrauen, ein weiteres Scrum-Buch im Hanser-Verlag zu veröffentlichen. Darüber hinaus möchte ich mich bei Irene Weilhart für die freundliche, immer kompetente und prompte Hilfe bei allen Herstellungsfragen bedanken.

Ganz besonders möchte ich mich bei meiner Mutter Waltraud Wirdemann bedanken, die nicht nur während meiner Schulzeit meine Rechtschreibung korrigiert hat, sondern das heute immer noch und gerne tut.

Mein ganz spezieller Dank gilt meiner Frau Astrid, die viel mehr fürmich getan hat, als das Cover dieses Buches zu gestalten und das Manuskript wieder und wieder zu lesen. Danke, dass du immer da bist.

1.4Feedback

Ich freue mich über Feedback jeglicher Art. Teilen Sie mir Ihre Hinweise, Korrekturen oder sonstigen Anmerkungen per E-Mail an ralf. [email protected] mit. Vielen Dank!

2Beispiel: Scrumcoaches.com