ralf WIRDEMANN SCRUM MIT USER STORIES 2. Auflage

Transkript

1 ralf WIRDEMANN SCRUM MIT USER STORIES 2. Auflage

2 Inhaltsverzeichnis 1 Einführung Warum dieses Buch? Struktur und Aufbau Dankeschön Feedback Beispiel: Scrumcoaches.com Das Projekt Der Entwicklungsprozess Die Beteiligten Die Anforderungen Priorisieren und Schätzen des Product Backlog Priorisieren Schätzen Sprint-Planung Sprint-Ziel Entwicklungsgeschwindigkeit Analyse der User Stories Design der User Stories Sprint-Durchführung Messen des Sprint-Fortschritts Am Ende des Sprint Sprint-Review Sprint-Retrospektive Die Arbeit geht weiter Zusammenfassung Wie geht es weiter?

3 VI Inhaltsverzeichnis 3 Die Grundlagen von Scrum Was ist Scrum? Scrum, ein Framework? Überblick Scrum-Team Vision und Product Backlog Sprint Planning Meeting Sprints Daily Scrums Sprint-Review Sprint-Retrospektive Prinzipien Transparenz Beobachten und Anpassen Timeboxing Dinge abschließen Maximierung von Geschäftswert Teams scheitern nicht Ergebnisorientierung Die Rollen Das Team Der ScrumMaster Der Product Owner Nebenrolle Kunde Die ideale Arbeitsumgebung Empirisches Management Zusammenfassung Wie geht es weiter? User Stories Was sind User Stories? Story-Karte Konversation Akzeptanzkriterien Warum User Stories? User Stories schreiben Die Sprache des Kunden

4 Inhaltsverzeichnis VII Benutzerrollen User-Story-Muster Epics Themen Wie viel Detail? Keine Technik Keine Benutzeroberfläche Eigenschaften guter User Stories Independent Unabhängige User Stories Negotiable Verhandelbare User Stories Valuable Wertvolle User Stories Estimatable Schätzbare User Stories Small Kleine User Stories Testable Testbare User Stories Zusammenfassung Wie geht es weiter? Agiles Schätzen Was ist agiles Schätzen? Relative Größe statt Dauer Schätzen in Story Points Wo bleibt die Dauer? Argumentationshilfe für Story Points Schätzen von User Stories Größenordnungen und Punktesequenzen Planungspoker Wann schätzen? Zusammenfassung Wie geht es weiter? Agiles Planen Was macht Planung agil? Velocity Tatsächliche Velocity Angenommene Velocity Velocity-basierte Planung Nachhaltige Velocity Agile Planung funktioniert

5 VIII Inhaltsverzeichnis Velocity korrigiert Schätzfehler Neubewertung von User Stories Urlaub, Krankheit und ähnliche Ereignisse Der Plan entsteht Zusammenfassung Wie geht es weiter? User Stories fürs Product Backlog Das Product Backlog Das Product Backlog füllen Anforderungsworkshops Interviews, Markt-Feedback und Abstimmungsrunden Überarbeitung und Pflege des Product Backlog User Stories priorisieren Finanzieller Wert Kosten Kundenzufriedenheit nach Kano Risiko Abhängigkeiten Priorisierende Faktoren abwägen MuSCoW-Priorisierung User Stories schneiden Vertikales Schneiden Schneiden nach Daten Schneiden nach Aufwand Schneiden nach Forschungsanteilen Schneiden nach Qualität Schneiden nach Benutzerrolle Schneiden nach Akzeptanzkriterien Schneiden nach technischer Voraussetzung Andere Anforderungen Anforderungen umformulieren Constraints Fehler Technisches Backlog Zusammenfassung Wie geht es weiter?

6 Inhaltsverzeichnis IX 8 Sprint-Planung Überblick und Ablauf Beteiligte Ergebnisse Vorbereitung Sprint Velocity Story-Auswahl Sprint-Länge Sprint Planning Ablauf Sprint-Ziel Warum führen wir den Sprint durch? Vorstellung, Analyse und Commitment Fehler und andere technische Aufgaben Sprint Planning Ablauf Story-Design Tasks schneiden Tasks schätzen? Das Sprint Backlog Fehler und andere technischen Aufgaben verteilen Was tun, wenn es länger wird? Abschluss Zusammenfassung Wie geht es weiter? Sprint-Durchführung Die eigentliche Arbeit beginnt Wer macht was? Das Team Der Product Owner Der ScrumMaster Story für Story Richtung Sprint-Ziel Wie viele User Stories zurzeit? Arbeit an einer User Story Definition of Done Abnahme fertiger User Stories Daily Scrum

7 X Inhaltsverzeichnis Aktualisierung des Taskboard Ein guter Zeitpunkt Ein guter Ort Wer ist noch dabei? Was macht der ScrumMaster? Unterbrechungen Messen und Anpassen Bug- und technische Burndown-Charts Was tun, wenn es eng wird? Reguläres Sprint-Ende Sprint-Review Vorbereitung Ort, Zeitpunkt und Teilnehmer Ziel Ablauf Das Team organisiert sich Verantwortung übernehmen Das Team machen lassen und aus Fehlern lernen Den Product Owner einbeziehen Software-Pull-Systeme Das Team bei der Arbeit mit Tasks coachen Einzelgespräche Sprint Best Practices Source Code Management und Story-Branches Kontinuierliches Integrieren Automatisierung Verständlicher Quellcode Elektronische Sprint Backlogs und Burndown-Charts Zusammenfassung Wie geht es weiter? User Stories Akzeptanztesten Was ist Akzeptanztesten? Akzeptanzkriterien Akzeptanztests Akzeptanztesten Akzeptanzkriterien schreiben

8 Inhaltsverzeichnis XI Vom Akzeptanzkriterium zum Akzeptanztest Merkmale guter Akzeptanzkriterien Akzeptanzkriterien auch für Epics? Beispiel: Suche nach Coaches Kleine Bausteine: Auf dem Weg zur DSL Akzeptanztesten während des Sprint Die hohe Schule: Akzeptanztest-getriebene Entwicklung ATDD-Beispiel: Suche nach Coaches Product Owner love writing Tests? Lohnt sich das Ganze? Zusammenfassung Wie geht es weiter? Sprint-Retrospektive Nach dem Sprint ist vor dem Sprint Ablauf von Retrospektiven Retrospektiven vorbereiten Retrospektiven leiten Agenda und Check-in Phase 1: Daten sammeln Erstellung einer Timeline Erweiterung der Timeline um Energiepunkte Phase 2: Einsichten generieren Positiv- / Delta-Liste Warum-Fragen Phase 3: Entscheiden, was zu tun ist Phase 4: Ziele formulieren und Aktionen planen Abschluss Themenorientierte Retrospektiven Zusammenfassung Wie geht es weiter? Agile Releaseplanung Releaseplanung Themen-Releases Datum-Releases Releaseplanungs-Workshop Was macht die Planung agil?

9 XII Inhaltsverzeichnis 12.2 Planungs-Velocity Durchführung von Test-Sprints Historische Daten Das Team bestimmen lassen Auswahl eines Verfahrens Der Releaseplan Sichere Planung Sichere Velocity Sicherheit durch weniger wichtige User Stories Monitoring und Aktualisierung Zusammenfassung Wie geht es weiter? Glossar Literaturverzeichnis Stichwortverzeichnis

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

11 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

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

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

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

15 Stichwortverzeichnis A Acceptance Test-driven Development Cucumber Definition JCriteria Agiles Planen siehe Planen Agiles Schätzen siehe Schätzen Akzeptanzkriterien , 180 Merkmale Akzeptanztest , 181 Automatisierung Akzeptanztesten Akzeptanztest-Taskboard Während des Sprint Anforderungsworkshop , 101, 104 Angenommene Velocity , 87 ATDD..... siehe Acceptance Test-driven Development Automatisierung B Benutzerinterviews Benutzermodellierung Benutzerrollen , 102 Beobachten und Anpassen... 32, 47, 197 Brainstorming , 102, 140 Branch Bugfixing siehe Fehler Bugtracking-System C CCC Change-Manager Chicken Commitment , 126, 135, 170 Cone of Uncertainty Constraints , 102, 119 Continuous Integration siehe Kontinuierliches Integrieren Cross-funktional Cucumber D Daily Scrum , 31, 158 Aktualisierung des Taskboard Chickens and Pigs Coaching des Teams Moderation , 161 Ort Selbstorganisation Vorbereitung Zeitpunkt Datum-Release Dauer , 84 Definition of Done , 121, 155 Fehlerbehebung User Stories abnehmen Delta-Liste Detaillierungsgrad Domain-Specific Language Done Dot Voting DSL.... siehe Domain-Specific Language E Einzelgespräche Empirische Prozesskontrolle Entscheidungsplan Entwicklertest Entwicklungsgeschwindigkeit , 85

16 238 Stichwortverzeichnis Epic Akzeptanzkriterien Zerschneiden Extreme Programming F Fehler Aus Fehlern lernen Behebung , 163, 167 Burndown-Chart Einplanen , 135, 145 Planbare Fehler , 163 Produktionsfehler Schätzen Sofort-Fehler , 163 Fibonacci-Folge Fischfang-Metapher Flow Fokusfaktor Forschungs-Story G Geschäftswert Given, When, Then Größe H Historische Daten Horizontales Schneiden I Impediment , 39 Impediment Backlog , 153, 158 Inspect and Adapt.siehe Beobachten und Anpassen J JCriteria K Kaizen Kanban-System Kano Kontinuierliches Integrieren Kosten , 150 Kritischer Pfad , 165 Kunde , 45 L Leuchtspur-Story M Markt-Feedback Median Mehrarbeit Meilenstein Messen Release-Burndown-Chart Sprint-Burndown-Chart Sprint-Fortschritt Velocity-Verteilung Mindmap , 102, 140 Moderation Daily Scrum Sprint Planning , 141 Sprint-Retrospektive Sprint-Review MuSCoW-Priorisierung N Nachhaltige Velocity Nicht-funktionale Anforderungen.. 107, 118 f. O Outsourcing P Pair Programming , 73, 174 Pareto-Prinzip Personentag Pig Planen Angenommene Velocity Dauer Entwicklungsgeschwindigkeit Messen der Geschwindigkeit Nachhaltige Velocity Releaseplanung Schätzfehler Schätzungen korrigieren , 93 Sprint-Planung Tatsächliche Velocity Urlaub und Krankheit , 221 Velocity

17 Stichwortverzeichnis 239 Velocity-basierte Planung Velocity-Median Ziele Planning Poker..... siehe Planungspoker Planungs-Velocity , 216 Planungspoker Planungsworkshop Positiv-Liste Prinzipien siehe Scrum-Prinzipien Priorisieren , 104 Abhängigkeiten Faktoren abwägen Finanzieller Wert Kano Kosten Kundenzufriedenheit MuSCoW Risiko Themen Product Backlog , 29, 98 Überarbeitung und Pflege Andere Anforderungen Priorisieren siehe Priorisieren Tools Product Owner , 43 Arbeit mit dem Team , 44, 152 Aufgaben im Sprint Commitment Kunden repräsentieren Product Backlog verwalten , 103 Releaseplanung User Stories schreiben , 57 User Stories vorstellen Produktionsfehler Produktionssupport Produktkonzept Punktesequenz Q QA-Abnahme Qualität R Refactoring Burndown-Chart Einplanen , 145 Referenz-Story Regressionstest Relative Größe Release Release-Burndown-Chart Release-Sprints , 167 Releaseplan , 90, 217, 218 Aktualisierung Form Releaseplanung , 213 Datum-basiert Sichere Planung Themen-basiert Workshop Retrospektive. siehe Sprint-Retrospektive Review siehe Sprint-Review Risikomanagement Rollen , 36 Product Owner ScrumMaster Team S Schätzen , 70 Dauer ableiten Epics , 78 Fibonacci-Folge Größenklassen Größenordnungen Pair Programming Planungspoker Punktesequenz Referenz-Story , 79 Relative Größe Schätzfehler Schätzungen korrigieren , 93 Story Points Tasks schätzen Triangularisierung Wann schätzen? Schätzrunde Schneiden von User Stories nach Akzeptanzkriterien nach Aufwand , 117 nach Benutzerrolle nach Daten nach Forschungsanteilen

18 240 Stichwortverzeichnis nach Qualität Vertikales Schneiden SCM.... siehe Source Code Management Scrum Überblick Arbeitsumgebung Einführen Framework Kultur und Werte Meetings Prinzipien Rollen und Extreme Programming Ursprung Was ist Scrum? Scrum-Prinzipien Beobachten und Anpassen Dinge abschließen Ergebnisorientierung Maximierung von Geschäftswert.. 35, 162 Teams scheitern nicht Timeboxing Transparenz Scrum-Team , 28, 36 ScrumMaster , 39 Aufgaben im Sprint Einzelgespräche führen Entscheidungen treffen Führungskraft Persönlichkeit Problembeseitiger , 152 Product Owner-Coaching Retrospektiven leiten Scrum implementieren Sprint Planning moderieren Team coachen Selbstorganisation , 38, 151, 170 Selected Backlog , 30, 125 Sichere Planung Puffer Sichere Velocity Software Design Software-Pull-System Source Code Management Sprint Abbruch Ankündigung Best Practices Durchführung , 150 Ende Fehlerbehebung , 163 Fortschritt messen , 164 Funktionsumfang reduzieren Gelieferte Funktionalität Gelieferte Qualität Länge Planung , 123 Rhythmus Unterbrechungen Sprint Backlog , 30, 125, 144, 176 Sprint Planning , 131 Sprint Planning , 136 Sprint Planning Meeting , 30, 123 Überblick und Ablauf Abschluss Angenommene Velocity Beteiligte Commitment Ergebnisse Fehler einplanen , 145 Refactorings einplanen , 145 Sprint Planning Sprint Planning Stories auswählen Tasks schneiden , 139 Timeboxing Urlaub und Feiertage berücksichtigen 128 Veränderte Teamgröße Vorbereitung Sprint-Burndown-Chart , 164 Sprint-Planung.... siehe Sprint Planning Meeting Sprint-Retrospektive , 31, 197 Ablauf und Phasen , 201 Abschluss und Ergebnis Aktivitäten Debriefing , 204 Teilnehmer Themenorientiert Ziele , 208

19 Stichwortverzeichnis 241 Sprint-Review , 31, 168 Sprint-Ziel , 125, 132, 170 Gefährdung Kreative Lösungen Kritischer Pfad Story-Auswahl Stakeholder Story Points , 71 Argumente für Story Points Schätzen Sprint-Burndown-Chart Story-Karte T Task , 139 Größe Schätzen Schneiden Schneidetechniken Ungeplante Tasks Taskboard , 144, 153 Aktualisierung im Daily Scrum Arbeiten mit dem Taskboard Software-Pull-System Team coachen Taskkarte Tatsächliche Velocity Team , 37 Aufgaben im Sprint Commitment Größe Teamraum Technical Debt.. siehe Technische Schuld Technische Anforderungen Als User Stories formulieren Einplanen Technische Schuld , 155, 210 Technisches Backlog Test-Sprints Thema , 105 Themen-Release Themenorientierte Retrospektiven Timeboxing , 78 Timeline Transparenz Triangularisierung Trunk U Ungeplante Tasks , 141, 154 Urlaub und Krankheit , 221 User Story , 52 Abnahme Akzeptanzkriterien siehe Akzeptanzkriterien Akzeptanztest.... siehe Akzeptanztest Akzeptanztesten siehe Akzeptanztesten Analyse im Sprint Planning... 15, 133 Basis-Stories Begeisterungs-Stories Benutzerrolle f. Design im Sprint Planning , 138 Geschäftswert , 104 Größe , 70 Gründe für User Stories INVEST-Kriterien Karte Konversation Kostenbestimmung Muster Parallele Bearbeitung Priorisieren siehe Priorisieren Relative Größe Risiko Schätzen siehe Schätzen, 73 Schneiden... siehe Schneiden von User Stories Schreiben Story Points siehe Story Points Tasks schneiden , 139 Testen Verhandlung Vertikal Vorstellung im Sprint Planning Wegfallen lassen Ziel , 59 V Velocity , 85 Angenommene.. siehe Angenommene Velocity Berechnung f.

20 242 Stichwortverzeichnis Median , 220 Messung Nachhaltige Planungs..... siehe Planungs-Velocity Range Reduzierung , 220 Sichere Tatsächliche siehe Tatsächliche Velocity Team bestimmt Velocity-Chart Verteilung Vorhersage Vertikales Schneiden Verwendbare Software Vision , 29 W Workshop Anforderungen Releaseplanung X XP siehe Extreme Programming Y Yesterday s Weather.... siehe Historische Daten

21 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. 29,90 [D] 30,80 [A] ISBN Produktmanager, ScrumMaster, Projektleiter, Softwareentwickler, CTOs Systemvoraussetzungen für ebook-inside: Internet-Verbindung und ebookreader Adobe Digital Editions.