ralf WIRDEMANN SCRUM MIT USER STORIES 2. Auflage

ralf WIRDEMANN SCRUM MIT USER STORIES 2. Auflage

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.......................... 54 4.2 Warum User Stories?............................. 55 4.3 User Stories schreiben............................ 57 4.3.1 Die Sprache des Kunden....................... 57

Inhaltsverzeichnis VII 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...................... 63 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?............................ 80 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 6.3 Agile Planung funktioniert.......................... 93

VIII Inhaltsverzeichnis 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........................... 104 7.3.2 Kosten................................. 105 7.3.3 Kundenzufriedenheit nach Kano.................. 106 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 Akzeptanzkriterien................ 116 7.4.8 Schneiden nach technischer Voraussetzung............ 117 7.5 Andere Anforderungen........................... 118 7.5.1 Anforderungen umformulieren................... 118 7.5.2 Constraints.............................. 119 7.5.3 Fehler................................. 120 7.5.4 Technisches Backlog......................... 121 7.6 Zusammenfassung.............................. 121 7.7 Wie geht es weiter?.............................. 122

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 zurzeit?................... 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 User Stories Akzeptanztesten........................... 179 10.1 Was ist Akzeptanztesten?.......................... 179 10.1.1 Akzeptanzkriterien.......................... 180 10.1.2 Akzeptanztests............................ 181 10.1.3 Akzeptanztesten........................... 182 10.2 Akzeptanzkriterien schreiben........................ 183

Inhaltsverzeichnis XI 10.2.1 Vom Akzeptanzkriterium zum Akzeptanztest.......... 184 10.2.2 Merkmale guter Akzeptanzkriterien................ 185 10.2.3 Akzeptanzkriterien auch für Epics?................ 186 10.3 Beispiel: Suche nach Coaches........................ 186 10.4 Kleine Bausteine: Auf dem Weg zur DSL.................. 188 10.5 Akzeptanztesten während des Sprint.................... 189 10.6 Die hohe Schule: Akzeptanztest-getriebene Entwicklung........ 191 10.6.1 ATDD-Beispiel: Suche nach Coaches................ 192 10.6.2 Product Owner love writing Tests?................. 193 10.7 Lohnt sich das Ganze?............................ 194 10.8 Zusammenfassung.............................. 195 10.9 Wie geht es weiter?.............................. 196 11 Sprint-Retrospektive................................ 197 11.1 Nach dem Sprint ist vor dem Sprint.................... 198 11.2 Ablauf von Retrospektiven......................... 198 11.3 Retrospektiven vorbereiten......................... 200 11.4 Retrospektiven leiten............................. 201 11.5 Agenda und Check-in............................ 201 11.6 Phase 1: Daten sammeln........................... 203 11.6.1 Erstellung einer Timeline...................... 203 11.6.2 Erweiterung der Timeline um Energiepunkte........... 205 11.7 Phase 2: Einsichten generieren........................ 205 11.7.1 Positiv- / Delta-Liste......................... 205 11.7.2 Warum-Fragen............................ 206 11.8 Phase 3: Entscheiden, was zu tun ist.................... 207 11.9 Phase 4: Ziele formulieren und Aktionen planen............. 208 11.10 Abschluss................................... 209 11.11 Themenorientierte Retrospektiven..................... 209 11.12 Zusammenfassung.............................. 211 11.13 Wie geht es weiter?.............................. 211 12 Agile Releaseplanung............................... 213 12.1 Releaseplanung................................ 213 12.1.1 Themen-Releases........................... 213 12.1.2 Datum-Releases............................ 214 12.1.3 Releaseplanungs-Workshop..................... 215 12.1.4 Was macht die Planung agil?.................... 216

XII Inhaltsverzeichnis 12.2 Planungs-Velocity............................... 216 12.2.1 Durchführung von Test-Sprints................... 216 12.2.2 Historische Daten........................... 217 12.2.3 Das Team bestimmen lassen..................... 217 12.2.4 Auswahl eines Verfahrens...................... 217 12.3 Der Releaseplan................................ 218 12.4 Sichere Planung................................ 219 12.4.1 Sichere Velocity............................ 220 12.4.2 Sicherheit durch weniger wichtige User Stories.......... 221 12.5 Monitoring und Aktualisierung....................... 221 12.6 Zusammenfassung.............................. 222 12.7 Wie geht es weiter?.............................. 223 Glossar.......................................... 225 Literaturverzeichnis.................................. 233 Stichwortverzeichnis.................................. 237

Kapitel 2 Beispiel: Scrumcoaches.com Dieses Kapitel beschreibt Scrum und User Stories am Beispiel der Entwicklung von Scrumcoaches.com, einer webbasierten Plattform für die Vermittlung von Dienstleistungen im Scrum-Umfeld. Das Beispiel streift alle wichtigen Phasen und Bestandteile von Scrum unter Einbeziehung von User Stories als Werkzeug fürs Anforderungsmanagement. Abbildung 2.1: Das Scrumcoaches-Team bei der Arbeit Das Kapitel begleitet das Scrumcoaches-Projektteam bei der Arbeit. Nach einer kurzen Einführung in den zugrunde liegenden Entwicklungsprozess und in die beteiligten Rollen werden die initiale Anforderungsanalyse im Rahmen eines Workshops und die Formulierung der resultierenden Anforderungen mit Hilfe von User Stories beschrieben, die User Stories geschätzt und hinsichtlich ihres Geschäftswerts priori-

8 2 Beispiel: Scrumcoaches.com siert. Anschließend startet das Team in seine erste Iteration, in Scrum Sprint genannt. Im Sprint Planning Meeting, der Planungsphase eines Sprint, bespricht das Team eine Reihe von User Stories und zerbricht sie in konkrete Einzeltasks. In den kommenden zwei Wochen, der eigentlichen Entwicklungsphase des Sprint, arbeitet das Team die Tasks und damit die ausgewählten Stories nach und nach ab. Am Ende des Sprint liefert es funktionierende Software, die im Sprint-Review allen interessierten Personen präsentiert wird. Den Abschluss des Sprint markiert die Sprint-Retrospektive, in der das Team seinen Entwicklungsprozess analysiert und Ideen für Verbesserungen entwickelt. Außerdem ermittelt das Team seine tatsächliche Entwicklungsgeschwindigkeit und kann für die folgenden Sprints besser einschätzen, wie viele User Stories in einen Sprint passen. Das Kapitel ermöglicht Ihnen, einen Schritt zurückzutreten und einen Gesamtblick auf ein Scrum-Projekt zu werfen. Ausgestattet mit diesem Überblick, geht es in den folgenden Kapiteln in die Details von Scrum und User Stories, in denen die hier nur kurz und exemplarisch vorgestellten Konzepte aufgegriffen und ausführlich beschrieben werden. 2.1 Das Projekt Scrum-Projekte beginnen mit einer Vision, welche die zentrale Idee des Vorhabens auf den Punkt bringt: Wir wollen eine Web-Anwendung entwickeln, mit der Scrum-Coaches neue Projekte und Projektanbieter qualifizierte Scrum-Coaches finden können. Basierend auf dieser Vision erstellt der Product Owner ein Konzeptpapier, das die Kernidee und Basisfunktionalität von Scrumcoaches.com zusammenfasst. Der folgende Abschnitt enthält einen Auszug aus diesem Konzeptpapier. Produktkonzept: Scrumcoaches.com Scrumcoaches.com soll eine webbasierte Plattform für die Vermittlung von Dienstleistungen im Scrum-Umfeld werden. Scrum-Coaches können ihr Profil hinterlegen und die Projektdatenbank nach offenen Projekten durchsuchen. Projektanbieter können Projekte einstellen und für die Suche freigeben oder gezielt nach Scrum- Coaches suchen. Beide Parteien können über die Plattform Kontakt zueinander aufnehmen. Darüber hinaus bietet das System eine Bewertungsfunktion, mit der Projektanbieter die Arbeit von Scrum-Coaches bewerten und diesen zu einer guten Reputation verhelfen können. Ein wesentliches Merkmal von Scrumcoaches.com ist die Vermittlung von qualitativ hochwertigem Scrum-Know-how. Scrumcoaches.com-Kunden sollen sich sicher sein, dass die registrierten Coaches über umfangreiche Erfahrung aus mehreren Scrum-Projekten verfügen. Die Schlüsselelemente hierfür sind Reputation und Vertrauen. Ein registrierter Scrum-Coach erlangt oder steigert seine Reputation, indem er sich von ehemaligen Kunden oder Teams bewerten lässt. Coaches geben also

2.2 Der Entwicklungsprozess 9 nicht nur selber ihre Fähigkeiten an, sondern übertragen diese Aufgabe an diejenigen, die bereits mit dem Coach zusammengearbeitet haben. Darüber hinaus kann ein Scrum-Coach seine eigene Reputation auf andere Coaches übertragen, indem er diese weiterempfiehlt. Coaches stehen dann mit ihrem Namen für andere Coaches ein. Als Refinanzierung von Scrumcoaches.com ist derzeit eine abgestufte Rechnungsstellung angedacht. Coaches sollen die Anwendung in ihrer Basisversion kostenlos nutzen können. Der Weg für kostenpflichtige Dienste für Coaches soll jedoch offen gehalten werden. Projektanbieter zahlen bei erfolgreicher Vermittlung und für das Einstellen von Anzeigen. 2.2 Der Entwicklungsprozess Scrumcoaches.com wird mit Scrum entwickelt, einem Framework für das Management agiler Softwareprojekte. Scrum ist kein Entwicklungsprozess oder Vorgehensmodell im herkömmlichen Sinne, in welchem von Anfang an klar definiert ist, wann und in welcher Reihenfolge welche Ergebnisse zu liefern sind. Stattdessen beschreibt Scrum ausschließlich einen Rahmen, in dem sich das Entwicklungsteam und andere Interessenvertreter des Projekts relativ frei bewegen und arbeiten können. Dieser Abschnitt gibt einen kurzen Überblick über die wesentlichen Bestandteile, Rollen und Artefakte von Scrum. Alle Anforderungen eines Scrum-Projekts werden in einem zentralen Anforderungskatalog, dem Product Backlog, verwaltet. Das Product Backlog enthält eine Liste von User Stories. Eine User Story beschreibt eine konkrete Funktionalität aus Sicht des Anwenders. Scrum-Entwicklungsteams arbeiten in Sprints. Ein Sprint ist eine Entwicklungsperiode von 1 bis 4 Wochen Länge. In einem Sprint setzt das Team selbstorganisiert und eigenverantwortlich einen Teil der User Stories des Product Backlog in funktionierende Software um. Scrum beschreibt einen iterativen Prozess der Softwareentwicklung, bestehend aus den folgenden vier Phasen: 1 Tag 1 4 Wochen zusammen ein halber Tag Sprint-Planung Sprint-Durchführung Überprüfung von Ergebnis und Prozess Verbesserung und Anpassung Abbildung 2.2: Die vier Phasen von Scrum In der Sprint-Planung werden die User Stories aus dem Product Backlog ausgewählt, die im anstehenden Sprint umgesetzt werden sollen. In der Sprint-Durchführung werden die ausgewählten User Stories vom Team programmiert und ins Gesamtsystem integriert. Am Ende des Sprint werden das Ergebnis vom Kunden und der Entwicklungsprozess vom Team überprüft. Die daraus resultierenden Verbesserungs-

10 2 Beispiel: Scrumcoaches.com vorschläge werden im folgenden Sprint berücksichtigt und umgesetzt. Der beschriebene Kreislauf setzt sich über die gesamte Laufzeit des Projekts fort. 2.3 Die Beteiligten An der Entwicklung von Scrumcoaches.com sind drei Rollen beteiligt: der Product Owner, das Team und der ScrumMaster. Der Product Owner repräsentiert den Kunden und somit den Anforderer. Er verfügt über das notwendige Domänenwissen, um Anforderungen zu formulieren und Detailfragen beantworten zu können. Der Product Owner ist der fachliche Projektleiter und für den Gesamterfolg des Projekts verantwortlich. Das Team besteht aus drei Softwareentwicklern und einem HTML-Designer. Es ist für die erfolgreiche Umsetzung der User Stories eines Sprint verantwortlich. Das Team arbeitet selbstorganisiert im geschützten Raum des Sprint. Es gibt keinen Projektleiter, der dem Team sagt, was es zu tun oder zu lassen hat. Der ScrumMaster 1 ist für die Einführung und Umsetzung von Scrum zuständig. Er coacht das Team, gibt aber keine Handlungsanweisungen oder weist Aufgaben zu. Ein ScrumMaster ist kein Vorgesetzter. Ein ScrumMaster räumt Hindernisse aus dem Weg und sorgt für optimale Arbeitsbedingungen. Der ScrumMaster hält dem Team den Rücken frei. Neben diesen drei Hauptrollen gibt es in Scrum-Projekten auch immer die Rolle des Kunden, das heißt desjenigen, der die Software in Auftrag gibt und nach ihrer Entwicklung betreibt, nutzt oder verkauft. Im Fall von Scrumcoaches.com ist der Kunde ein junges Startup-Unternehmen, dessen Geschäftsidee die beschriebene Plattform ist. Das Unternehmen besteht aus den beiden Gründern, die die Software bei einem auf Scrum spezialisierten Softwarehaus in Auftrag geben. 2.4 Die Anforderungen Anforderungen werden in Scrum im zentralen Product Backlog verwaltet. Das Product Backlog enthält eine Liste mit priorisierten und geschätzten User Stories. Eine User Story ist eine in der Sprache des Kunden beschriebene Anforderung an das System, die einen konkreten und für den Kunden sichtbaren Mehrwert liefert. User Stories werden in einem aktiven Stil geschrieben, der in ein bis zwei Sätzen den Kern der Anforderung auf den Punkt bringt. Ein Beispiel: Als Scrum-Coach will ich nach Projekten suchen. 1 Für die Rolle des ScrumMaster hat sich die Camel-Case-Schreibweise etabliert. Leider konnte ich keinen Hinweis darauf finden, warum das so ist. Auch Ken Schwaber verwendet in seinem Original-Scrum-Buch noch die getrennte Schreibweise,,Scrum Master [Schwaber und Beedle, 2001], stellt dann aber in seinen weiteren Büchern kommentarlos auf,,scrummaster um [Schwaber 2004].

2.5 Priorisieren und Schätzen des Product Backlog 11 Für das Schreiben der User Stories und deren Verwaltung im Product Backlog ist der Product Owner zuständig. Nur er darf neue Stories hinzufügen, die Priorität vorhandener Stories ändern oder auch mit der Zeit unwichtig gewordene Stories aus dem Backlog entfernen. Natürlich kann der Product Owner das Product Backlog nicht ganz alleine füllen. Dafür gibt es zu viele wichtige Ideen anderer Interessenvertreter, die der Product Owner sammeln und als User Stories formuliert ins Backlog übertragen muss. Deshalb führt der Product Owner zu Beginn des Projekts einen Anforderungsworkshop mit allen an Scrumcoaches.com interessierten Personen durch. Gemeinsam wird eine Mindmap mit den zentralen Ideen und Inhalten der Plattform erstellt. Dazu schlüpft das Anforderungsteam in die verschiedenen Benutzerrollen (graue Kästchen in Abbildung 2.3) und überlegt sich, was Scrum-Coaches und Projektanbieter, aber auch ehemalige Auftraggeber oder Administratoren mit dem System erreichen wollen. Ich will Coaches finden Ich will Coaches vergleichen Projektanbieter Ehemaliger Auftraggeber Ich will Coaches bewerten Scrumcoaches.com Ich will Projekte finden Ich will meine Reputation verbessern Scrum-Coach Administrator Ich will Benutzer verwalten Ich will Coaches weiterempfehlen Abbildung 2.3: Mindmap mit den Zielen einzelner Benutzerrollen Im Anschluss an den Workshop zieht sich der Product Owner einige Stunden zurück und formuliert auf Basis der erstellten Mindmap eine Reihe von User Stories und trägt sie ins Product Backlog ein (Tabelle 2.1 auf der nächsten Seite). 2.5 Priorisieren und Schätzen des Product Backlog Das Product Backlog ist ein dynamisches Dokument. Im Laufe des Projekts ändern sich Anforderungen, es kommen neue hinzu, Prioritäten ändern sich, oder Anforderungen fallen ganz weg. Außerdem nimmt der Detailgrad einer User Story zu, je näher die Story an ihre konkrete Umsetzung, das heißt an den nächsten Sprint rückt. Und genau dies ist die nächste Aufgabe des Product Owner. Er muss entscheiden, welche Stories im Product Backlog am wichtigsten sind, und sie entsprechend priorisieren. 2.5.1 Priorisieren Bei seinen Erwägungen, welche User Stories am wichtigsten sind, überlegt sich der Product Owner als Erstes, was die Anwendung minimal leisten muss, damit sie in einer Basisversion nutzbar ist. Er beschließt, dass das System in einer Minimalversion potenziellen Projektanbietern Zugriff auf die Profile der registrierten Scrum-

Stichwortverzeichnis A Acceptance Test-driven Development Cucumber........................ 192 Definition.........................191 JCriteria.......................... 194 Agiles Planen...............siehe Planen Agiles Schätzen...........siehe Schätzen Akzeptanzkriterien.............. 54, 180 Merkmale........................ 185 Akzeptanztest.................. 156, 181 Automatisierung................. 192 Akzeptanztesten.................... 179 Akzeptanztest-Taskboard......... 190 Während des Sprint...............189 Anforderungsworkshop..... 11, 101, 104 Angenommene Velocity...........15, 87 ATDD..... siehe Acceptance Test-driven Development Automatisierung.................... 176 B Benutzerinterviews................. 103 Benutzermodellierung............... 58 Benutzerrollen................... 58, 102 Beobachten und Anpassen... 32, 47, 197 Brainstorming...............58, 102, 140 Branch.............................. 174 Bugfixing................... siehe Fehler Bugtracking-System................. 120 C CCC................................. 53 Change-Manager.....................41 Chicken............................. 161 Commitment.......... 125, 126, 135, 170 Cone of Uncertainty.................216 Constraints................. 63, 102, 119 Continuous Integration............ siehe Kontinuierliches Integrieren Cross-funktional..................... 38 Cucumber.......................... 192 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...................... 214 Dauer............................ 72, 84 Definition of Done.......... 92, 121, 155 Fehlerbehebung.................. 157 User Stories abnehmen............156 Delta-Liste.......................... 205 Detaillierungsgrad................... 62 Domain-Specific Language.......... 188 Done................................. 34 Dot Voting.......................... 207 DSL.... siehe Domain-Specific Language E Einzelgespräche.....................173 Empirische Prozesskontrolle......... 47 Entscheidungsplan.................. 218 Entwicklertest.......................156 Entwicklungsgeschwindigkeit.... 15, 85

238 Stichwortverzeichnis Epic.................................. 60 Akzeptanzkriterien............... 186 Zerschneiden..................... 111 Extreme Programming.............. 174 F Fehler............................... 120 Aus Fehlern lernen............... 171 Behebung................157, 163, 167 Burndown-Chart................. 164 Einplanen............... 129, 135, 145 Planbare Fehler.............. 120, 163 Produktionsfehler................ 120 Schätzen.......................... 129 Sofort-Fehler................. 120, 163 Fibonacci-Folge...................... 75 Fischfang-Metapher................. 100 Flow................................. 27 Fokusfaktor......................... 142 Forschungs-Story................... 114 G Geschäftswert....................... 104 Given, When, Then................. 192 Größe................................ 70 H Historische Daten................... 217 Horizontales Schneiden............. 112 I Impediment...................... 19, 39 Impediment Backlog........ 39, 153, 158 Inspect and Adapt.siehe Beobachten und Anpassen J JCriteria.............................194 K Kaizen.............................. 197 Kanban-System..................... 172 Kano................................ 106 Kontinuierliches Integrieren......... 175 Kosten......................... 105, 150 Kritischer Pfad................. 130, 165 Kunde............................ 10, 45 L Leuchtspur-Story................... 138 M Markt-Feedback.....................103 Median.............................. 89 Mehrarbeit.......................... 150 Meilenstein......................... 222 Messen Release-Burndown-Chart......... 221 Sprint-Burndown-Chart.......... 164 Sprint-Fortschritt................. 164 Velocity-Verteilung............... 220 Mindmap................... 11, 102, 140 Moderation.......................... 40 Daily Scrum...................... 161 Sprint Planning.............. 134, 141 Sprint-Retrospektive.............. 201 Sprint-Review.................... 168 MuSCoW-Priorisierung............. 110 N Nachhaltige Velocity................. 91 Nicht-funktionale Anforderungen.. 107, 118 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................... 213 Schätzfehler....................... 93 Schätzungen korrigieren........ 86, 93 Sprint-Planung.................... 89 Tatsächliche Velocity............... 85 Urlaub und Krankheit......... 94, 221 Velocity............................ 85

Stichwortverzeichnis 239 Velocity-basierte Planung.......... 89 Velocity-Median................... 88 Ziele............................... 83 Planning Poker..... siehe Planungspoker Planungs-Velocity.............. 213, 216 Planungspoker....................... 76 Planungsworkshop................. 215 Positiv-Liste........................ 205 Prinzipien....... siehe Scrum-Prinzipien Priorisieren...................... 11, 104 Abhängigkeiten...................109 Faktoren abwägen................ 109 Finanzieller Wert................. 104 Kano............................. 106 Kosten............................ 105 Kundenzufriedenheit............. 106 MuSCoW......................... 110 Risiko............................ 108 Themen.......................... 105 Product Backlog............... 10, 29, 98 Überarbeitung und Pflege.........103 Andere Anforderungen........... 118 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................... 218 User Stories schreiben.......... 44, 57 User Stories vorstellen............ 133 Produktionsfehler................... 120 Produktionssupport.................163 Produktkonzept.....................101 Punktesequenz....................... 74 Q QA-Abnahme....................... 157 Qualität............................. 150 R Refactoring......................... 121 Burndown-Chart................. 164 Einplanen.................... 135, 145 Referenz-Story....................... 79 Regressionstest......................167 Relative Größe....................... 70 Release............................. 213 Release-Burndown-Chart........... 221 Release-Sprints.................. 30, 167 Releaseplan..............26, 90, 217, 218 Aktualisierung....................222 Form............................. 218 Releaseplanung..................90, 213 Datum-basiert.................... 214 Sichere Planung.................. 219 Themen-basiert................... 213 Workshop........................ 215 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?.................... 80 Schätzrunde..........................76 Schneiden von User Stories..........111 nach Akzeptanzkriterien.......... 116 nach Aufwand............... 113, 117 nach Benutzerrolle................ 116 nach Daten....................... 113 nach Forschungsanteilen.......... 114

240 Stichwortverzeichnis nach Qualität..................... 115 Vertikales Schneiden.............. 111 SCM.... siehe Source Code Management Scrum................................. 9 Überblick.......................... 28 Arbeitsumgebung..................46 Einführen.......................... 40 Framework........................ 27 Kultur und Werte.................. 28 Meetings...........................28 Prinzipien......................... 28 Rollen............................. 36 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............. 201 Scrum implementieren............. 40 Sprint Planning moderieren....... 134 Team coachen.....................153 Selbstorganisation....... 17, 38, 151, 170 Selected Backlog............. 16, 30, 125 Sichere Planung..................... 219 Puffer.............................221 Sichere Velocity................... 220 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..... 165 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 Überblick und Ablauf............. 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 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, 197 Ablauf und Phasen........... 199, 201 Abschluss und Ergebnis.......... 209 Aktivitäten....................... 199 Debriefing................... 200, 204 Teilnehmer....................... 198 Themenorientiert................. 209 Ziele......................... 197, 208

Stichwortverzeichnis 241 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 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...... 118 Einplanen........................ 135 Technische Schuld...........92, 155, 210 Technisches Backlog.................121 Test-Sprints......................... 216 Thema...........................62, 105 Themen-Release.................... 213 Themenorientierte Retrospektiven... 209 Timeboxing....................... 33, 78 Timeline............................ 203 Transparenz.......................... 47 Triangularisierung................... 79 Trunk............................... 174 U Ungeplante Tasks........... 18, 141, 154 Urlaub und Krankheit........... 94, 221 User Story........................ 10, 52 Abnahme......................... 156 Akzeptanzkriterien.............. siehe Akzeptanzkriterien Akzeptanztest.... siehe Akzeptanztest Akzeptanztesten................. siehe Akzeptanztesten 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.................. 165 Ziel.............................53, 59 V Velocity........................... 15, 85 Angenommene.. siehe Angenommene Velocity Berechnung...................... 87 f.

242 Stichwortverzeichnis Median........................88, 220 Messung........................... 85 Nachhaltige........................91 Planungs..... siehe Planungs-Velocity Range............................ 216 Reduzierung.................. 22, 220 Sichere........................... 220 Tatsächliche siehe Tatsächliche Velocity Team bestimmt................... 217 Velocity-Chart..................... 88 Verteilung........................ 220 Vorhersage....................... 216 Vertikales Schneiden................ 111 Verwendbare Software.............. 150 Vision............................. 8, 29 W Workshop Anforderungen................... 101 Releaseplanung................... 215 X XP..........siehe Extreme Programming Y Yesterday s Weather.... siehe Historische Daten

UNSCHLAGBARES DOPPEL // Lernen Sie, wie Sie Scrum und User Stories gemeinsam erfolgreich in Ihrem Projekt einsetzen. Erfahren Sie, wie Sie Anforderungen im Sinne des Kunden mit Hilfe von User Stories beschreiben und im Product Backlog verwalten. Lernen Sie, wie Sie User Stories schätzen und eine zuverlässige Sprint- und Releaseplanung erstellen. 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. SCRUM MIT USER STORIES // Scrum als Framework für die Agile Software ent - wicklung 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 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 Schrei ben 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. Neu in der 2. Auflage ist das Kapitel»User Stories Akzeptanztesten«. Vom Schrei - ben sinnvoller Akzeptanzkriterien bis hin zur Akzeptanztest-getriebenen Entwick - lung (ATDD) erfahren Sie darin, worauf es bei der Entwicklung und beim Akzeptanz - testen von User Stories ankommt. // Ganz besonders interessant wird es, wenn man Scrum und User-Stories kombiniert. Und genau hier liegt der eigentliche Wert des Buches. Die Kombination macht vieles einfacher! Mein Fazit: Wir alle lernen ja ständig irgendwelche Kleinigkeiten. Aber wenn man auch mit 25 Jahren Berufserfahrung nochmal ein solches Aha-Erlebnis hat, das ist schon was Besonderes. // Steffen Gemkow, ObjectFab 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. www.hanser.de/computer 29,90 [D] 30,80 [A] ISBN 978-3-446-42660-3 Produktmanager, ScrumMaster, Projektleiter, Softwareentwickler, CTOs 9 7 8 3 4 4 6 4 2 6 6 0 3 Systemvoraussetzungen für ebook-inside: Internet-Verbindung und ebookreader Adobe Digital Editions.