ralf WIRDEMANN Scrum MIT USER STORIES

ralf WIRDEMANN Scrum MIT USER STORIES

Inhaltsverzeichnis 1 Einführung..................................... 1 1.1 Warum dieses Buch?............................. 2 1.2 Struktur und Aufbau............................. 3 1.3 Dankeschön.................................. 5 1.4 Feedback.................................... 5 2 Beispiel: Scrumcoaches.com........................... 7 2.1 Das Projekt................................... 8 2.2 Der Entwicklungsprozess.......................... 9 2.3 Die Beteiligten................................. 10 2.4 Die Anforderungen.............................. 10 2.5 Priorisieren und Schätzen des Product Backlog.............. 11 2.5.1 Priorisieren.............................. 11 2.5.2 Schätzen................................ 13 2.6 Sprint-Planung................................ 14 2.6.1 Sprint-Ziel............................... 14 2.6.2 Entwicklungsgeschwindigkeit................... 15 2.6.3 Analyse der User Stories....................... 15 2.6.4 Design der User Stories....................... 16 2.7 Sprint-Durchführung............................. 17 2.8 Messen des Sprint-Fortschritts........................ 19 2.9 Am Ende des Sprint.............................. 20 2.9.1 Sprint-Review............................. 21 2.9.2 Sprint-Retrospektive......................... 21 2.10 Die Arbeit geht weiter............................ 22 2.11 Zusammenfassung.............................. 23 2.12 Wie geht es weiter?.............................. 24

VI Inhaltsverzeichnis 3 Die Grundlagen von Scrum............................ 25 3.1 Was ist Scrum?................................. 26 3.2 Scrum, ein Framework?........................... 27 3.3 Überblick.................................... 28 3.3.1 Scrum-Team.............................. 28 3.3.2 Vision und Product Backlog..................... 29 3.3.3 Sprint Planning Meeting....................... 30 3.3.4 Sprints................................. 30 3.3.5 Daily Scrums............................. 31 3.3.6 Sprint-Review............................. 31 3.3.7 Sprint-Retrospektive......................... 31 3.4 Prinzipien................................... 32 3.4.1 Transparenz.............................. 32 3.4.2 Beobachten und Anpassen..................... 32 3.4.3 Timeboxing.............................. 33 3.4.4 Dinge abschließen.......................... 34 3.4.5 Maximierung von Geschäftswert.................. 35 3.4.6 Teams scheitern nicht........................ 36 3.4.7 Ergebnisorientierung......................... 36 3.5 Die Rollen................................... 36 3.5.1 Das Team............................... 37 3.5.2 Der ScrumMaster........................... 39 3.5.3 Der Product Owner.......................... 43 3.5.4 Nebenrolle Kunde.......................... 45 3.6 Die ideale Arbeitsumgebung........................ 46 3.7 Empirisches Management.......................... 47 3.8 Zusammenfassung.............................. 49 3.9 Wie geht es weiter?.............................. 50 4 User Stories..................................... 51 4.1 Was sind User Stories?............................ 52 4.1.1 Story-Karte.............................. 53 4.1.2 Konversation............................. 54 4.1.3 Akzeptanzkriterien.......................... 55 4.2 Warum User Stories?............................. 55 4.3 User Stories schreiben............................ 57

Inhaltsverzeichnis VII 4.3.1 Die Sprache des Kunden....................... 57 4.3.2 Benutzerrollen............................ 58 4.3.3 User-Story-Muster.......................... 59 4.3.4 Epics.................................. 60 4.3.5 Themen................................ 62 4.3.6 Wie viel Detail?............................ 62 4.3.7 Keine Technik............................. 63 4.3.8 Keine Benutzeroberfläche...................... 64 4.4 Eigenschaften guter User Stories...................... 64 4.4.1 Independent Unabhängige User Stories............. 64 4.4.2 Negotiable Verhandelbare User Stories............. 65 4.4.3 Valuable Wertvolle User Stories.................. 65 4.4.4 Estimatable Schätzbare User Stories............... 66 4.4.5 Small Kleine User Stories..................... 66 4.4.6 Testable Testbare User Stories................... 67 4.5 Zusammenfassung.............................. 68 4.6 Wie geht es weiter?.............................. 68 5 Agiles Schätzen................................... 69 5.1 Was ist agiles Schätzen?........................... 70 5.1.1 Relative Größe statt Dauer...................... 70 5.1.2 Schätzen in Story Points....................... 71 5.1.3 Wo bleibt die Dauer?......................... 72 5.1.4 Argumentationshilfe für Story Points............... 72 5.2 Schätzen von User Stories.......................... 73 5.2.1 Größenordnungen und Punktesequenzen............. 74 5.2.2 Planungspoker............................ 76 5.2.3 Wann schätzen?............................ 81 5.3 Zusammenfassung.............................. 81 5.4 Wie geht es weiter?.............................. 81 6 Agiles Planen.................................... 83 6.1 Was macht Planung agil?........................... 83 6.2 Velocity..................................... 85 6.2.1 Tatsächliche Velocity......................... 85 6.2.2 Angenommene Velocity....................... 87 6.2.3 Velocity-basierte Planung...................... 89 6.2.4 Nachhaltige Velocity......................... 91

VIII Inhaltsverzeichnis 6.3 Agile Planung funktioniert.......................... 93 6.3.1 Velocity korrigiert Schätzfehler................... 93 6.3.2 Neubewertung von User Stories.................. 93 6.3.3 Urlaub, Krankheit und ähnliche Ereignisse............ 94 6.3.4 Der Plan entsteht........................... 95 6.4 Zusammenfassung.............................. 95 6.5 Wie geht es weiter?.............................. 96 7 User Stories fürs Product Backlog........................ 97 7.1 Das Product Backlog............................. 98 7.2 Das Product Backlog füllen......................... 100 7.2.1 Anforderungsworkshops...................... 101 7.2.2 Interviews, Markt-Feedback und Abstimmungsrunden..... 103 7.2.3 Überarbeitung und Pflege des Product Backlog......... 103 7.3 User Stories priorisieren........................... 104 7.3.1 Finanzieller Wert........................... 105 7.3.2 Kosten................................. 106 7.3.3 Kundenzufriedenheit nach Kano.................. 107 7.3.4 Risiko................................. 108 7.3.5 Abhängigkeiten............................ 109 7.3.6 Priorisierende Faktoren abwägen.................. 109 7.3.7 MuSCoW-Priorisierung....................... 110 7.4 User Stories schneiden............................ 111 7.4.1 Vertikales Schneiden......................... 111 7.4.2 Schneiden nach Daten........................ 113 7.4.3 Schneiden nach Aufwand...................... 113 7.4.4 Schneiden nach Forschungsanteilen................ 114 7.4.5 Schneiden nach Qualität....................... 115 7.4.6 Schneiden nach Benutzerrolle.................... 116 7.4.7 Schneiden nach technischer Voraussetzung............ 116 7.5 Andere Anforderungen........................... 117 7.5.1 Anforderungen umformulieren................... 117 7.5.2 Constraints.............................. 118 7.5.3 Fehler................................. 119 7.5.4 Technisches Backlog......................... 120 7.6 Zusammenfassung.............................. 121 7.7 Wie geht es weiter?.............................. 121

Inhaltsverzeichnis IX 8 Sprint-Planung................................... 123 8.1 Überblick und Ablauf............................. 123 8.2 Beteiligte.................................... 124 8.3 Ergebnisse................................... 125 8.4 Vorbereitung.................................. 127 8.4.1 Sprint Velocity............................ 127 8.4.2 Story-Auswahl............................ 129 8.4.3 Sprint-Länge............................. 130 8.5 Sprint Planning 1............................... 131 8.5.1 Ablauf................................. 131 8.5.2 Sprint-Ziel Warum führen wir den Sprint durch?........ 132 8.5.3 Vorstellung, Analyse und Commitment.............. 133 8.5.4 Fehler und andere technische Aufgaben.............. 135 8.6 Sprint Planning 2............................... 136 8.6.1 Ablauf................................. 137 8.6.2 Story-Design............................. 137 8.6.3 Tasks schneiden............................ 139 8.6.4 Tasks schätzen?............................ 141 8.6.5 Das Sprint Backlog.......................... 144 8.6.6 Fehler und andere technischen Aufgaben verteilen....... 145 8.6.7 Was tun, wenn es länger wird?................... 145 8.7 Abschluss................................... 146 8.8 Zusammenfassung.............................. 147 8.9 Wie geht es weiter?.............................. 148 9 Sprint-Durchführung............................... 149 9.1 Die eigentliche Arbeit beginnt........................ 149 9.2 Wer macht was?................................ 151 9.2.1 Das Team............................... 151 9.2.2 Der Product Owner.......................... 152 9.2.3 Der ScrumMaster........................... 152 9.3 Story für Story Richtung Sprint-Ziel.................... 153 9.3.1 Wie viele User Stories zur Zeit?................... 154 9.3.2 Arbeit an einer User Story...................... 154 9.3.3 Definition of Done.......................... 155 9.3.4 Abnahme fertiger User Stories................... 156 9.4 Daily Scrum.................................. 158

X Inhaltsverzeichnis 9.4.1 Aktualisierung des Taskboard................... 159 9.4.2 Ein guter Zeitpunkt......................... 160 9.4.3 Ein guter Ort............................. 160 9.4.4 Wer ist noch dabei?.......................... 161 9.4.5 Was macht der ScrumMaster?.................... 161 9.5 Unterbrechungen............................... 162 9.6 Messen und Anpassen............................ 164 9.6.1 Bug- und technische Burndown-Charts.............. 164 9.6.2 Was tun, wenn es eng wird?..................... 165 9.7 Reguläres Sprint-Ende............................ 167 9.8 Sprint-Review................................. 168 9.8.1 Vorbereitung............................. 168 9.8.2 Ort, Zeitpunkt und Teilnehmer................... 168 9.8.3 Ziel................................... 168 9.8.4 Ablauf................................. 169 9.9 Das Team organisiert sich.......................... 170 9.9.1 Verantwortung übernehmen.................... 170 9.9.2 Das Team machen lassen und aus Fehlern lernen......... 171 9.9.3 Den Product Owner einbeziehen.................. 171 9.9.4 Software-Pull-Systeme........................ 172 9.9.5 Das Team bei der Arbeit mit Tasks coachen............ 173 9.9.6 Einzelgespräche............................ 173 9.10 Sprint Best Practices............................. 174 9.10.1 Source Code Management und Story-Branches.......... 174 9.10.2 Kontinuierliches Integrieren..................... 175 9.10.3 Automatisierung........................... 176 9.10.4 Verständlicher Quellcode...................... 176 9.10.5 Elektronische Sprint Backlogs und Burndown-Charts...... 176 9.11 Zusammenfassung.............................. 177 9.12 Wie geht es weiter?.............................. 178 10 Sprint-Retrospektive................................ 179 10.1 Nach dem Sprint ist vor dem Sprint.................... 180 10.2 Ablauf von Retrospektiven......................... 180 10.3 Retrospektiven vorbereiten......................... 182 10.4 Retrospektiven leiten............................. 183 10.5 Agenda und Check-in............................ 183

Inhaltsverzeichnis XI 10.6 Phase 1: Daten sammeln........................... 185 10.6.1 Erstellung einer Timeline...................... 185 10.6.2 Erweiterung der Timeline um Energiepunkte........... 187 10.7 Phase 2: Einsichten generieren........................ 187 10.7.1 Positiv- / Delta-Liste......................... 187 10.7.2 Warum-Fragen............................ 188 10.8 Phase 3: Entscheiden, was zu tun ist.................... 189 10.9 Phase 4: Ziele formulieren und Aktionen planen............. 190 10.10Abschluss................................... 191 10.11Themenorientierte Retrospektiven..................... 191 10.12Zusammenfassung.............................. 193 10.13Wie geht es weiter?.............................. 193 11 Agile Releaseplanung............................... 195 11.1 Releaseplanung................................ 195 11.1.1 Themen-Releases........................... 195 11.1.2 Datum-Releases............................ 196 11.1.3 Releaseplanungs-Workshop..................... 197 11.1.4 Was macht die Planung agil?.................... 198 11.2 Planungs-Velocity............................... 198 11.2.1 Durchführung von Test-Sprints................... 198 11.2.2 Historische Daten........................... 199 11.2.3 Das Team bestimmen lassen..................... 199 11.2.4 Auswahl eines Verfahrens...................... 199 11.3 Der Releaseplan................................ 200 11.4 Sichere Planung................................ 201 11.4.1 Sichere Velocity............................ 202 11.4.2 Sicherheit durch weniger wichtige User Stories.......... 203 11.5 Monitoring und Aktualisierung....................... 203 11.6 Zusammenfassung.............................. 204 11.7 Wie geht es weiter?.............................. 205 Glossar.......................................... 207 Literaturverzeichnis.................................. 213 Stichwortverzeichnis.................................. 215

Kapitel 1 Einfü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-Projektes. 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-Projektes 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.

2 1 Einführung 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äftswertsteigernde 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.1 Warum 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

1.2 Struktur und Aufbau 3 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.2 Struktur und Aufbau Neben diesem Einführungskapitel enthält das Buch zehn 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

4 1 Einführung 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. 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 drei Kapiteln, die sich mit der Planung und Durchführung von Sprints sowie dem Rückblick auf den Entwicklungsprozess beschäftigen. Das Kapitel 8, 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 9, 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 Projektes nehmen. Zum Abschluss jedes Sprint wirft das Team einen in Kapitel 10, 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 letzte Teil des Buches besteht aus einem einzigen Kapitel. Das Kapitel 11, Agile Releaseplanung, beschreibt die Releaseplanung in Scrum mit Hilfe von User Sto-

1.3 Dankeschön 5 ries. 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. 1.3 Dankeschö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, Bernd Oestereich, Uwe Petschke, Hubert Rosicka, Katja Roth, Dr. Gernot Starke, Sascha Teske, Hans-Martin Winkler, Henning Wolf und Henning Zuzmann. Ich danke meiner Lektorin Margarete Metzger 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 Lektorats-Fragen 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 lieben Frau Astrid, die viel mehr für mich getan hat, als das Manuskript wieder und wieder zu lesen. Danke, dass Du immer da bist. 1.4 Feedback Ich freue mich über Feedback jeglicher Art. Teilen Sie mir Ihre Hinweise, Korrekturen oder sonstigen Anmerkungen per E-Mail an ralf@ralfwirdemann.de mit. Vielen Dank!

Stichwortverzeichnis A Agiles Planen...............siehe Planen Agiles Schätzen...........siehe Schätzen Akzeptanzkriterien...................55 Akzeptanztest...................... 156 Anforderungsworkshop..... 11, 101, 104 Angenommene Velocity...........15, 87 Automatisierung.................... 176 B Benutzerinterviews................. 103 Benutzermodellierung............... 58 Benutzerrollen................... 58, 102 Beobachten und Anpassen... 32, 47, 179 Brainstorming...............58, 102, 140 Branch.............................. 174 Bugfixing................... siehe Fehler Bugtracking-System................. 119 C CCC................................. 53 Change-Manager.....................41 Chicken............................. 161 Commitment.......... 125, 126, 135, 170 Cone of Uncertainty................. 198 Constraints................. 63, 103, 118 Continuous Integration............ siehe Kontinuierliches Integrieren Cross-funktional..................... 38 D Daily Scrum.................. 19, 31, 158 Aktualisierung des Taskboard..... 159 Chickens and Pigs................ 161 Coaching des Teams.............. 162 Moderation.................. 158, 161 Ort............................... 160 Selbstorganisation................ 158 Vorbereitung......................158 Zeitpunkt......................... 160 Datum-Release...................... 196 Dauer............................ 72, 84 Definition of Done.......... 92, 120, 155 Fehlerbehebung.................. 157 User Stories abnehmen............156 Delta-Liste.......................... 187 Detaillierungsgrad................... 62 Done................................. 34 Dot Voting.......................... 189 E Einzelgespräche.....................173 Empirische Prozesskontrolle......... 47 Entscheidungsplan.................. 200 Entwicklertest.......................156 Entwicklungsgeschwindigkeit.... 15, 85 Epic.................................. 60 Zerschneiden..................... 111 Extreme Programming.............. 174 F Fehler............................... 119 Aus Fehlern lernen............... 171 Behebung................157, 163, 167 Burndown-Chart................. 164

216 Stichwortverzeichnis Einplanen............... 129, 135, 145 Planbare Fehler.............. 119, 163 Produktionsfehler................ 119 Schätzen.......................... 129 Sofort-Fehler................. 119, 163 Fibonacci-Folge...................... 75 Fischfang-Metapher................. 100 Flow................................. 27 Fokusfaktor......................... 142 Forschungs-Story................... 114 G Geschäftswert....................... 104 Größe................................ 70 H Historische Daten................... 199 Horizontales Schneiden............. 113 I Impediment...................... 19, 39 Impediment Backlog........ 39, 153, 158 Inspect and Adapt.siehe Beobachten und Anpassen K Kaizen.............................. 179 Kanban-System..................... 172 Kano................................ 107 Kontinuierliches Integrieren......... 175 Kosten......................... 106, 150 Kritischer Pfad................. 130, 166 Kunde............................ 10, 45 L Leuchtspur-Story................... 138 M Markt-Feedback.....................103 Median.............................. 89 Mehrarbeit.......................... 150 Meilenstein......................... 204 Messen Release-Burndown-Chart......... 203 Sprint-Burndown-Chart.......... 164 Sprint-Fortschritt................. 164 Velocity-Verteilung............... 202 Mindmap................... 11, 102, 140 Moderation.......................... 40 Daily Scrum...................... 161 Sprint Planning.............. 134, 141 Sprint-Retrospektive.............. 183 Sprint-Review.................... 168 MuSCoW-Priorisierung............. 110 N Nachhaltige Velocity................. 91 Nicht-funktionale Anforderungen.. 107, 117 f. O Outsourcing........................ 166 P Pair Programming............46, 73, 174 Pareto-Prinzip........................86 Personentag.......................... 73 Pig.................................. 161 Planen............................... 83 Angenommene Velocity............ 87 Dauer..............................84 Entwicklungsgeschwindigkeit..... 85 Messen der Geschwindigkeit....... 84 Nachhaltige Velocity............... 91 Releaseplanung................... 195 Schätzfehler....................... 93 Schätzungen korrigieren........ 86, 93 Sprint-Planung.................... 89 Tatsächliche Velocity............... 85 Urlaub und Krankheit......... 94, 203 Velocity............................ 85 Velocity-basierte Planung.......... 89 Velocity-Median................... 88 Ziele............................... 83 Planning Poker..... siehe Planungspoker Planungs-Velocity.............. 195, 198 Planungspoker....................... 76 Planungsworkshop................. 197 Positiv-Liste........................ 187

Stichwortverzeichnis 217 Prinzipien....... siehe Scrum-Prinzipien Priorisieren...................... 11, 104 Abhängigkeiten...................109 Faktoren abwägen................ 109 Finanzieller Wert................. 105 Kano............................. 107 Kosten............................ 106 Kundenzufriedenheit............. 107 MuSCoW......................... 110 Risiko............................ 108 Themen.......................... 105 Product Backlog............... 10, 29, 98 Überarbeitung und Pflege.........103 Andere Anforderungen........... 117 Priorisieren.......... siehe Priorisieren Tools...............................98 Product Owner................... 10, 43 Arbeit mit dem Team...... 17, 44, 152 Aufgaben im Sprint............... 152 Commitment..................... 126 Kunden repräsentieren............. 43 Product Backlog verwalten.... 44, 103 Releaseplanung................... 200 User Stories schreiben.......... 44, 57 User Stories vorstellen............ 133 Produktionsfehler................... 119 Produktionssupport.................163 Produktkonzept.....................101 Punktesequenz....................... 74 Q QA-Abnahme....................... 157 Qualität............................. 150 R Refactoring......................... 120 Burndown-Chart................. 164 Einplanen.................... 135, 145 Referenz-Story....................... 79 Regressionstest......................167 Relative Größe....................... 70 Release............................. 195 Release-Burndown-Chart........... 203 Release-Sprints.................. 30, 167 Releaseplan..............26, 90, 199, 200 Aktualisierung....................204 Form............................. 200 Releaseplanung..................90, 195 Datum-basiert.................... 196 Sichere Planung.................. 201 Themen-basiert................... 195 Workshop........................ 197 Retrospektive. siehe Sprint-Retrospektive Review............. siehe Sprint-Review Risikomanagement..................108 Rollen............................ 10, 36 Product Owner.................... 43 ScrumMaster...................... 39 Team.............................. 37 S Schätzen.......................... 13, 70 Dauer ableiten..................... 72 Epics........................... 76, 78 Fibonacci-Folge.................... 75 Größenklassen..................... 71 Größenordnungen................. 74 Pair Programming................. 73 Planungspoker.....................76 Punktesequenz.................... 74 Referenz-Story................. 71, 79 Relative Größe..................... 70 Schätzfehler....................... 93 Schätzungen korrigieren........ 86, 93 Story Points........................ 71 Tasks schätzen.................... 142 Triangularisierung................. 79 Wann schätzen?.................... 81 Schätzrunde..........................76 Schneiden von User Stories..........111 nach Aufwand............... 113, 116 nach Benutzerrolle................ 116 nach Daten....................... 113 nach Forschungsanteilen.......... 114 nach Qualität..................... 115 Vertikales Schneiden.............. 111 SCM.... siehe Source Code Management Scrum................................. 9 Arbeitsumgebung..................46 Einführen.......................... 40 Framework........................ 27

218 Stichwortverzeichnis Kultur und Werte.................. 28 Meetings...........................28 Prinzipien......................... 28 Rollen............................. 36 Überblick.......................... 28 und Extreme Programming........ 26 Ursprung.......................... 26 Was ist Scrum?..................... 26 Scrum-Prinzipien.................... 32 Beobachten und Anpassen......... 32 Dinge abschließen................. 34 Ergebnisorientierung...............36 Maximierung von Geschäftswert.. 35, 162 Teams scheitern nicht.............. 36 Timeboxing........................ 33 Transparenz....................... 32 Scrum-Team................... 10, 28, 36 ScrumMaster..................... 10, 39 Aufgaben im Sprint............... 152 Einzelgespräche führen........... 173 Entscheidungen treffen............ 40 Führungskraft..................... 39 Persönlichkeit......................41 Problembeseitiger............. 39, 152 Product Owner-Coaching.......... 41 Retrospektiven leiten............. 183 Scrum implementieren............. 40 Sprint Planning moderieren....... 134 Team coachen.....................153 Selbstorganisation....... 17, 38, 151, 170 Selected Backlog............. 16, 30, 125 Sichere Planung..................... 201 Puffer.............................203 Sichere Velocity................... 202 Software Design.................... 137 Software-Pull-System............... 172 Source Code Management...........174 Sprint................................ 30 Abbruch.......................... 166 Ankündigung.................... 126 Best Practices..................... 174 Durchführung................. 17, 150 Ende..............................167 Fehlerbehebung.............. 157, 163 Fortschritt messen............. 19, 164 Funktionsumfang reduzieren..... 166 Gelieferte Funktionalität.......... 150 Gelieferte Qualität................ 150 Länge.............................130 Planung....................... 14, 123 Rhythmus........................ 131 Unterbrechungen................. 162 Sprint Backlog...... 16, 30, 125, 144, 176 Sprint Planning 1............... 124, 131 Sprint Planning 2............... 124, 136 Sprint Planning Meeting..... 14, 30, 123 Abschluss........................ 146 Angenommene Velocity...........127 Beteiligte......................... 124 Commitment..................... 146 Ergebnisse........................ 125 Fehler einplanen............. 128, 145 Refactorings einplanen....... 128, 145 Sprint Planning 1................. 124 Sprint Planning 2................. 124 Stories auswählen................ 129 Tasks schneiden.............. 136, 139 Timeboxing....................... 145 Überblick und Ablauf............. 123 Urlaub und Feiertage berücksichtigen 128 Veränderte Teamgröße............ 128 Vorbereitung......................127 Sprint-Burndown-Chart......... 20, 164 Sprint-Planung.... siehe Sprint Planning Meeting Sprint-Retrospektive......... 21, 31, 179 Ablauf und Phasen........... 181, 183 Abschluss und Ergebnis.......... 191 Aktivitäten....................... 181 Debriefing................... 182, 186 Teilnehmer....................... 180 Themenorientiert................. 191 Ziele......................... 179, 190 Sprint-Review................ 21, 31, 168 Sprint-Ziel..............14, 125, 132, 170 Gefährdung...................... 167 Kreative Lösungen................ 166 Kritischer Pfad....................130 Story-Auswahl....................129 Stakeholder.......................... 45

Stichwortverzeichnis 219 Story Points.......................13, 71 Argumente für Story Points........ 72 Schätzen........................... 71 Sprint-Burndown-Chart.......... 164 Story-Karte...........................53 T Task............................. 16, 139 Größe............................ 140 Schätzen.......................... 142 Schneiden........................ 139 Schneidetechniken................ 140 Ungeplante Tasks................. 141 Taskboard...................16, 144, 153 Aktualisierung im Daily Scrum... 159 Arbeiten mit dem Taskboard...... 154 Software-Pull-System............. 172 Team coachen.....................173 Taskkarte........................... 140 Tatsächliche Velocity................. 85 Team............................. 10, 37 Aufgaben im Sprint............... 151 Commitment..................... 125 Größe..............................38 Teamraum........................... 47 Technical Debt.. siehe Technische Schuld Technische Anforderungen Als User Stories formulieren...... 117 Einplanen........................ 135 Technische Schuld...........92, 155, 192 Technisches Backlog.................120 Test-Sprints......................... 198 Thema...........................62, 105 Themen-Release.................... 195 Themenorientierte Retrospektiven... 191 Timeboxing....................... 33, 78 Timeline............................ 185 Transparenz.......................... 47 Triangularisierung................... 79 Trunk............................... 174 U Ungeplante Tasks........... 17, 141, 154 Urlaub und Krankheit........... 94, 203 User Story........................ 10, 52 V Abnahme......................... 156 Akzeptanzkriterien................ 55 Analyse im Sprint Planning... 15, 133 Basis-Stories...................... 107 Begeisterungs-Stories............. 107 Benutzerrolle.....................58 f. Design im Sprint Planning..... 16, 138 Geschäftswert................. 65, 104 Größe.......................... 66, 70 Gründe für User Stories............ 55 INVEST-Kriterien.................. 64 Karte.............................. 53 Konversation...................... 54 Kostenbestimmung............... 106 Muster.............................59 Parallele Bearbeitung............. 154 Priorisieren.......... siehe Priorisieren Relative Größe..................... 70 Risiko............................ 108 Schätzen............ siehe Schätzen, 73 Schneiden... siehe Schneiden von User Stories Schreiben.......................... 57 Story Points......... siehe Story Points Tasks schneiden.............. 136, 139 Testen............................. 67 Verhandlung....................... 65 Vertikal........................... 111 Vorstellung im Sprint Planning... 133 Wegfallen lassen.................. 166 Ziel.............................53, 59 Velocity........................... 15, 85 Angenommene.. siehe Angenommene Velocity Berechnung...................... 87 f. Median........................88, 202 Messung........................... 85 Nachhaltige........................91 Planungs..... siehe Planungs-Velocity Range............................ 198 Reduzierung.................. 22, 202 Sichere........................... 202 Tatsächliche siehe Tatsächliche Velocity Team bestimmt................... 199

220 Stichwortverzeichnis Velocity-Chart..................... 88 Verteilung........................ 202 Vorhersage....................... 198 Vertikales Schneiden................ 111 Verwendbare Software.............. 150 Vision............................. 8, 29 W Workshop Anforderungen................... 101 X Releaseplanung................... 197 XP..........siehe Extreme Programming Y Yesterday s Weather.... siehe Historische Daten