Sie sind auf Seite 1von 482

»Agile Coaches werden von Essential Scrum begeistert sein!

Kenny Rubin stellt uns mit seinem


Werk einen unentbehrlichen Fundus an wertvollen Informationen zur Verfügung. Sie haben
es mit einem Management zu tun, das »es« einfach nicht einsehen will? Dann geben Sie ihnen
Kapitel 3 zu lesen, das in umfassender Art und Weise und unter Einbeziehung relevanter wirt-
schaftlicher Aspekte darlegt, inwiefern Scrum deutlich weniger Risikopotenzial birgt als her-
kömmliche plangesteuerte Entwicklungsverfahren. Sie wollen die Entwicklungsteams beim
Erreichen eines gemeinsamen Verständnisses von Scrum unterstützen? Die in diesem Nach-
schlagewerk präsentierte neuartige visuelle Beschreibungssprache Visual AGILExicon wird
Ihnen bei der Bewältigung dieser Aufgabe wertvolle Dienste leisten. Und das sind nur zwei
von vielen weiteren Möglichkeiten, wie Ihnen dieses Buch beim Coachen von Scrum-Teams
behilflich sein kann. Nutzen Sie es zu Ihrem Vorteil!«
– Lyssa Adkins, Trainerin für agile Coaches, Agile Coaching Institute;
Autorin von Coaching Agile Teams

»Dieses Buch liefert die besten und weitreichendsten Erläuterungen zum Thema Scrum-
Framework, die man sich nur wünschen kann! Essential Scrum richtet sich an alle, die an den
wesentlichen Aspekten des Entwicklungsprozesses interessiert sind – unabhängig davon, ob
bereits Scrum-Vorkenntnisse vorhanden sind oder nicht. Unter Zuhilfenahme gemeinver-
ständlicher visueller Elemente veranschaulicht Kenny die Kernprinzipien des Scrum-Frame-
works in bestechend nachvollziehbarer Weise. Bei meiner Arbeit als Scrum-Coach greife ich
fortlaufend auf Referenzmaterial zurück, das neue Wege einschlägt, um den Teams beim
Erlernen und der Nutzung des Frameworks zu helfen. Dennoch musste ich in den vergange-
nen mehr als zehn Jahren immer wieder erleben, dass Scrum sowohl vonseiten der großen
Unternehmen als auch der Toolanbieter regelmäßig falsch interpretiert und schlecht umge-
setzt wird. Dieses Buch richtet den Fokus jedoch wieder auf den Kern der Sache und konzen-
triert sich auf das, was in diesem Zusammenhang wirklich wichtig ist.«
– Joe Balistrieri, Process Development Manager, Rockwell Automation

»Kennys weitreichender Erfahrungsschatz aus seiner Tätigkeit als Berater, Trainer und ehema-
liger Managing Director der Scrum Alliance kommt in diesem Werk voll und ganz zur Gel-
tung. Neben der ausführlichen Auseinandersetzung mit den elementaren Aspekten des
Scrum-Prinzips beschäftigt sich dieses Buch auch mit der Frage aller Fragen: Was geschieht
mit den Projektmanagern? Essential Scrum zeichnet ein verständliches Bild des großen Gan-
zen und demonstriert sehr anschaulich, wie sich die Unternehmensleitung einbringen und
ihre Scrum-Teams bei der erfolgreichen Umstellung auf agile Methoden unterstützen kann.«
– Sameer S. Bendre, Certified ScrumMaster (CSM) & Project Management Professional (PMP),
Senior Consultant, 3i Infotech Inc.

»Wenn agile Vorgehensmodelle oder das Scrum-Verfahren Neuland für Sie sind, wird Ihnen
dieses Buch zu einem »fliegenden Start« verhelfen. Die Beispiele und Beschreibungen sind
klar verständlich und lebendig formuliert, und Sie werden feststellen, dass ein Thema oder
eine Frage, die sich Ihnen aufdrängt, oftmals schon unmittelbar im nächsten Moment ange-
sprochen wird.«
– Johannes Brodwall, Principal Solution Architect, Steria Norway
»Kennys sorgfältig strukturierte Ausführungen spiegeln die Sensibilität der Programmierspra-
che Smalltalk wider – der Entwicklungsumgebung, in der er jahrelang gearbeitet hat und aus
der sowohl Scrum als auch das Extreme Programming hervorgingen. Essential Scrum greift die
maßgeblichen Agile-Management-Prinzipien auf und geleitet seine Leserschaft zielsicher auf
den Weg zu einem effizienteren agilen Entwicklungsansatz.«
– Rowan Bunning, Gründer, Scrum WithStyle

»Es gibt heutzutage eine ganze Reihe von Referenzmaterial zum Thema Scrum – Essential
Scrum betrachtet die Dinge allerdings aus einer ganz neuen Perspektive: in Form eines »Rea-
lity-Checks« für praktizierende Softwareentwickler. Kenny zeigt anhand von unmissverständ-
lich illustrierten Beispielen aus der realen Arbeitswelt auf, wie sich ein solides Fundament für
die erfolgreiche agile Entwicklung legen lässt. Er vermittelt dem Leser unter anderem ein kla-
res Verständnis vom Wert der Qualitätsimplementierung und liefert schlüssige Antworten auf
die Frage, warum wir als Entwickler nicht schon im Voraus alles richtig machen können – son-
dern vielmehr inkrementell arbeiten und im Laufe des Prozesses hinzulernen müssen. Trotz
der ausdrücklichen Nennung des Begriffs »Scrum« im Titel werden in diesem Buch darüber
hinaus aber auch andere effiziente Praktiken aus dem agilen Universum thematisiert, um
Managern und ihren Teams zum Erfolg zu verhelfen.«
– Lisa Crispin, Co-Autorin von Agile Testing

»Kenny Rubin hat es fertiggebracht, ein Buch zu schreiben, das meiner Meinung nach wirk-
lich jeder, der mit dem Vorgehensmodell Scrum zu tun hat, lesen sollte! Seine Ausführungen
repräsentieren eine lückenlose Darstellung dessen, was man über Scrum wissen muss, und
noch vieles mehr!«
– Martine Devos, europäische Scrum-Pionierin und Certified ScrumMaster
»Nachdem ich in den vergangenen Jahren eine ganze Reihe von Büchern über agile Methoden
rezensiert habe, drängt sich mir natürlich die Frage auf: »Brauchen wir denn wirklich noch
eins?« Nun, im Fall von Essential Scrum kann ich dies nur mit einem überzeugten »Ja« beant-
worten. Anders als die gewohnten Nachschlagewerke dieser Art bringt Kenny dem Leser
außergewöhnliche, von Erfahrung geprägte Perspektiven näher, die wertvolle neue Einblicke
gewähren. Zweifellos einzigartig an diesem Buch ist die innovative »Ikonografie« – die Bild-
sprache, die Kenny selbst speziell für Scrum und andere agile Methoden entwickelt hat. Für
mich steht fest: Dieses Buch bietet eine unverzichtbare Hilfestellung für den Ausbau eigener
Ideen im Hinblick auf den erfolgreichen Einsatz des Scrum-Modells.«
– Scott Duncan, Agile/Scrum-Coach und -Trainer

»Wer ein Scrum-Training absolviert hat oder schon einmal in einem Scrum-Team tätig war,
wird in Essential Scrum eine großartige Aufbaulektüre finden. Dieses Buch demonstriert in
eindrucksvoller Weise, wie Sie durch die Adaption von Scrum-Prozessen agiler werden und
wie sich komplexe Projekte in handhabbare Segmente (bzw. »Sprints«) gliedern lassen. Kenny
Rubin beschreibt eine Vielzahl von praxisorientierten Fallstudien, die offenbaren, was in diver-
sen Organisationen funktioniert hat und was nicht. Das geordnete Layout und die professio-
nellen Grafiken in diesem Buch gewährleisten eine gute Übersichtlichkeit und erleichtern das
schnelle Auffinden bestimmter Themenbereiche. Organisationen, die sich vom traditionellen
Wasserfall-Modell weg und hin zu einem agileren Entwicklungsverfahren orientieren möch-
ten, finden in Essential Scrum einen verlässlichen Wegweiser und Ratgeber.«
– Julia Frazier, Produktmanagerin
Kenneth S. Rubin

Essential Scrum
Umfassendes Scrum-Wissen
aus der Praxis

Übersetzung aus dem Englischen


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

ISBN 978-3-8266-8473-9
1. Auflage 2014

www.mitp.de
E-Mail: kundenservice@hjr-verlag.de
Telefon: +49 6221 / 489 -555
Telefax: +49 6221 / 489 -410

© 2014 mitp, eine Marke der Verlagsgruppe Hüthig Jehle Rehm GmbH Heidelberg,
München, Landsberg, Frechen, Hamburg
Dieses Werk, einschließlich aller seiner Teile, ist urheberrechtlich geschützt. Jede Verwer-
tung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des
Verlages unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Überset-
zungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen
Systemen.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in die-
sem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass sol-
che Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu
betrachten wären und daher von jedermann benutzt werden dürften.

Authorized translation from the English language edition, entitled ESSENTIAL SCRUM:
A PRACTICAL GUIDE TO THE MOST POPULAR AGILE PROCESS, 1st Edition,
0137043295 by RUBIN, KENNETH S., published by Pearson Education, Inc, publishing as
Addison-Wesley Professional, Copyright © 2013 by Pearson Education, Inc.
All rights reserved. No part of this book may be reproduced or transmitted in any form or by
any means, electronic or mechanical, including photocopying, recording or by any informa-
tion storage retrieval system, without permission from Pearson Education, Inc. GERMAN
language edition published by mitp, an imprint of Verlagsgruppe Hüthig Jehle Rehm
GmbH, Copyright © 2014.

Lektorat: Sabine Schulz


Sprachkorrektorat: Maren Feilen
Satz: III-satz, Husby, www.drei-satz.de
Inhaltsverzeichnis

Zitate – Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Vorwort von Mike Cohn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Vorwort von Ron Jeffries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Einleitung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Danksagungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Über den Autor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

1 Einführung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.1 Was ist Scrum? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.2 Die Ursprünge von Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
1.3 Wieso Scrum? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.4 Ergebnisse bei Genomica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
1.5 Kann Scrum Ihnen helfen?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
1.5.1 Die Complex-Domäne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
1.5.2 Die Complicated-Domäne . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
1.5.3 Die Simple-Domäne. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
1.5.4 Die Chaotic-Domäne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
1.5.5 Disorder (Nicht-Wissen, Regellosigkeit). . . . . . . . . . . . . . . . . 41
1.5.6 Unterbrechungsgesteuerte Arbeit . . . . . . . . . . . . . . . . . . . . . . 42
1.6 Abschließende Bemerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Teil I Kernkonzepte 45

2 Das Scrum-Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.2 Scrum-Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.2.1 Product Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.2.2 ScrumMaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5
Inhaltsverzeichnis

2.2.3 Das Entwicklungsteam. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50


2.3 Scrum-Aktivitäten und Artefakte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.3.1 Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.3.2 Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2.3.3 Sprint-Planung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.3.4 Sprint-Ausführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.3.5 Daily Scrum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.3.6 Fertig (Done) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.3.7 Sprint Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2.3.8 Sprint-Retrospektive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.4 Abschließende Bemerkungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3 Agile Prinzipien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.2 Veränderlichkeit und Unsicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.2.1 Hilfreiche Veränderlichkeit bereitwillig annehmen . . . . . . . 66
3.2.2 Iterative und inkrementelle Entwicklung nutzen. . . . . . . . . . 67
3.2.3 Ausnutzen der Veränderlichkeit durch Inspektion,
Anpassung und Transparenz. . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.2.4 Gleichzeitiges Reduzieren aller Formen der Unsicherheit . . 70
3.3 Vorhersage und Anpassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.3.1 Optionen offen halten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.3.2 Akzeptieren, dass man es nicht gleich von Anfang
an richtig machen kann . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.3.3 Einen adaptiven, untersuchenden Ansatz bevorzugen . . . . . 74
3.3.4 Änderung auf eine ökonomisch sinnvolle Weise
annehmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.3.5 Vorhersagende, im Voraus erfolgende Arbeit mit
adaptiver, bedarfsgerechter Arbeit abwägen . . . . . . . . . . . . . . 78
3.4 Validiertes Wissen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.4.1 Schnelles Validieren wichtiger Annahmen . . . . . . . . . . . . . . 79
3.4.2 Abwägen mehrerer gleichzeitiger Lernschleifen . . . . . . . . . . 79
3.4.3 Organisieren des Workflows für schnelle Feedbacks . . . . . . 80
3.5 Work in Process (WIP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.5.1 Wirtschaftlich sinnvolle Batch-Größen benutzen . . . . . . . . . 82
3.5.2 Lagerbestände erkennen und sinnvoll verwalten . . . . . . . . . . 84
3.5.3 Auf unerledigte Arbeit konzentrieren, nicht auf
untätige Arbeiter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.5.4 Verzögerungskosten betrachten . . . . . . . . . . . . . . . . . . . . . . . 87

6
Inhaltsverzeichnis

3.6 Fortschritt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
3.6.1 An Echtzeitinformationen anpassen und umplanen. . . . . . . 88
3.6.2 Fortschritt messen, indem man funktionierende
Güter validiert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
3.6.3 Auf eine wertzentrierte Auslieferung konzentrieren. . . . . . . 89
3.7 Leistung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
3.7.1 Gehe schnell, aber hetze nicht . . . . . . . . . . . . . . . . . . . . . . . . 90
3.7.2 Baue Qualität ein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
3.7.3 Mache alles ohne großes Zeremoniell . . . . . . . . . . . . . . . . . . 91
3.8 Abschließende Bemerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

4 Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.2 Timeboxing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.2.1 Legt ein WIP-Limit fest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.2.2 Erzwingt eine Priorisierung. . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.2.3 Demonstriert Fortschritt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.2.4 Verhindert unnötigen Perfektionismus . . . . . . . . . . . . . . . . . 97
4.2.5 Motiviert die Fertigstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.2.6 Verbessert die Vorhersagbarkeit . . . . . . . . . . . . . . . . . . . . . . . 98
4.3 Kurze Zeitdauer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.3.1 Erleichterte Planung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.3.2 Schnelles Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.3.3 Verbesserter Return on Investment . . . . . . . . . . . . . . . . . . . . 99
4.3.4 Begrenzte Fehler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.3.5 Wiedererweckte Begeisterung . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.3.6 Häufige Checkpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.4 Konsistente Dauer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.4.1 Vorteile der Kadenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.4.2 Vereinfacht die Planung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.5 Keine das Ziel beeinflussenden Änderungen . . . . . . . . . . . . . . . . . . . 103
4.5.1 Was ist ein Sprint-Ziel? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.5.2 Gegenseitige Verpflichtung . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.5.3 Änderungen versus Klärung . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.5.4 Konsequenzen einer Änderung. . . . . . . . . . . . . . . . . . . . . . . . 104
4.5.5 Pragmatisch sein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.5.6 Abnormaler Abbruch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
4.6 Definition von Fertig (Done) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.6.1 Wie lautet die Definition von Fertig? . . . . . . . . . . . . . . . . . . . 108

7
Inhaltsverzeichnis

4.6.2 Die Definition von Fertig kann sich im Laufe der Zeit
weiterentwickeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.6.3 Definition von Fertig versus Akzeptanzkriterien . . . . . . . . . . 112
4.6.4 Fertig versus Fertig-Fertig . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.7 Abschließende Bemerkungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

5 Anforderungen und User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115


5.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
5.2 Gespräche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.3 Progressive Verfeinerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
5.4 Was sind User Stories? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
5.4.1 Card (Karte) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
5.4.2 Conversation (Gespräch) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
5.4.3 Confirmation (Bestätigung) . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
5.5 Der Detaillierungsgrad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
5.6 In gute Stories INVESTieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
5.6.1 Independent (unabhängig) . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
5.6.2 Negotiable (verhandelbar) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.6.3 Valuable (werthaltig). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.6.4 Estimatable (schätzbar) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
5.6.5 Passende Größe (klein) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
5.6.6 Testable (prüfbar) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
5.7 Nichtfunktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
5.8 Stories zum Wissenserwerb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
5.9 Stories sammeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
5.9.1 Workshop zum Schreiben von User Stories. . . . . . . . . . . . . . 132
5.9.2 Story Mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
5.10 Abschließende Bemerkungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

6 Das Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137


6.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
6.2 Product-Backlog-Elemente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
6.3 Merkmale guter Product Backlogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
6.3.1 Detailed appropriately (ausreichend detailliert) . . . . . . . . . . . 139
6.3.2 Emergent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
6.3.3 Estimated (geschätzt) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
6.3.4 Prioritized (priorisiert) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
6.4 Pflege . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
6.4.1 Was bedeutet Pflege? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

8
Inhaltsverzeichnis

6.4.2 Wer führt die Pflege durch?. . . . . . . . . . . . . . . . . . . . . . . . . . . 143


6.4.3 Wann findet die Pflege statt?. . . . . . . . . . . . . . . . . . . . . . . . . . 144
6.5 Die Definition von Bereit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
6.6 Flow Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
6.6.1 Release Flow Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
6.6.2 Sprint Flow Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
6.7 Welche und wie viele Product Backlogs? . . . . . . . . . . . . . . . . . . . . . . . 150
6.7.1 Was ist ein Produkt?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
6.7.2 Große Produkte – hierarchische Backlogs . . . . . . . . . . . . . . . 152
6.7.3 Mehrere Teams – ein Product Backlog. . . . . . . . . . . . . . . . . . 153
6.7.4 Ein Team – mehrere Produkte . . . . . . . . . . . . . . . . . . . . . . . . 154
6.8 Abschließende Bemerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

7 Schätzung und Velocity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157


7.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
7.2 Was und wann wir schätzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
7.2.1 Schätzungen für Portfolio-Backlog-Elemente . . . . . . . . . . . . 159
7.2.2 Product-Backlog-Schätzungen . . . . . . . . . . . . . . . . . . . . . . . . 159
7.2.3 Aufgabenschätzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
7.3 Schätzkonzepte für Product-Backlog-Elemente . . . . . . . . . . . . . . . . . 161
7.3.1 Als Team schätzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
7.3.2 Schätzungen sind keine Verpflichtungen . . . . . . . . . . . . . . . 162
7.3.3 Exaktheit versus Präzision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
7.3.4 Relative Größenschätzung. . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
7.4 Schätzeinheiten für Product-Backlog-Elemente . . . . . . . . . . . . . . . . . 166
7.4.1 Story-Punkte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
7.4.2 Idealtage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
7.5 Planungspoker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
7.5.1 Schätzskala . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
7.5.2 Wie man spielt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
7.5.3 Vorteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
7.6 Was ist Velocity? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
7.7 Einen Velocity-Bereich berechnen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
7.8 Die Velocity vorhersagen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
7.9 Die Velocity beeinflussen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
7.10 Missbrauch der Velocity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
7.11 Abschließende Bemerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

9
Inhaltsverzeichnis

8 Technische Schulden. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177


8.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
8.2 Die Folgen technischer Schulden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
8.2.1 Unvorhersehbarer Wendepunkt . . . . . . . . . . . . . . . . . . . . . . . 180
8.2.2 Zunehmend verzögerte Auslieferung . . . . . . . . . . . . . . . . . . . 180
8.2.3 Beträchtliche Anzahl an Defekten . . . . . . . . . . . . . . . . . . . . . . 180
8.2.4 Steigende Entwicklungs- und Support-Kosten . . . . . . . . . . . . 180
8.2.5 Das Produkt verkümmert. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
8.2.6 Schwindende Vorhersehbarkeit. . . . . . . . . . . . . . . . . . . . . . . . 181
8.2.7 Leistungseinbruch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
8.2.8 Allgemeiner Frust. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
8.2.9 Sinkende Kundenzufriedenheit. . . . . . . . . . . . . . . . . . . . . . . . 182
8.3 Ursachen der technischen Schulden . . . . . . . . . . . . . . . . . . . . . . . . . . 182
8.3.1 Druck hinsichtlich des Erreichens einer Deadline. . . . . . . . . 182
8.3.2 Erfolglose Versuche der Velocity-Beschleunigung. . . . . . . . . 183
8.3.3 Gerücht: Weniger Testen kann die Velocity
beschleunigen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
8.3.4 Schulden bauen auf Schulden auf. . . . . . . . . . . . . . . . . . . . . . 185
8.4 Technische Schulden müssen organisiert werden . . . . . . . . . . . . . . . 186
8.5 Die Zunahme technischer Schulden überwachen . . . . . . . . . . . . . . . 187
8.5.1 Bewährte technische Praktiken anwenden . . . . . . . . . . . . . . . 187
8.5.2 Eine starke Definition von Fertig benutzen . . . . . . . . . . . . . . 188
8.5.3 Die wirtschaftlichen Aspekte technischer Schulden
richtig verstehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
8.6 Technische Schulden sichtbar machen . . . . . . . . . . . . . . . . . . . . . . . . 191
8.6.1 Technische Schulden auf geschäftlicher Ebene
sichtbar machen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
8.6.2 Technische Schulden auf der technischen Ebene
sichtbar machen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
8.7 Technische Schulden abbauen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
8.7.1 Nicht alle technischen Schulden sollten abgebaut
werden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
8.7.2 Wenden Sie die Pfadfinderregel an (Bauen Sie die
Schulden ab, sobald sie Ihnen begegnen). . . . . . . . . . . . . . . . 197
8.7.3 Bauen Sie technische Schulden schrittweise ab. . . . . . . . . . . 197
8.7.4 Bauen Sie die technischen Schulden mit den
höchsten Zinsen zuerst ab . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

10
Inhaltsverzeichnis

8.7.5 Technische Schulden abbauen, während man für den


Kunden werthaltige Arbeit erledigt . . . . . . . . . . . . . . . . . . . . 199
8.8 Abschließende Bemerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

Teil II Rollen 201

9 Der Product Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203


9.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
9.2 Hauptaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
9.2.1 Organisation der wirtschaftlichen Belange . . . . . . . . . . . . . . 205
9.2.2 Mitwirkung an der Planung . . . . . . . . . . . . . . . . . . . . . . . . . . 207
9.2.3 Pflege des Product Backlogs . . . . . . . . . . . . . . . . . . . . . . . . . . 207
9.2.4 Definition und Verifikation der Akzeptanzkriterien . . . . . . . 207
9.2.5 Zusammenarbeit mit dem Entwicklungsteam . . . . . . . . . . . 208
9.2.6 Zusammenarbeit mit den Stakeholdern. . . . . . . . . . . . . . . . . 209
9.3 Eigenschaften/Fähigkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
9.3.1 Fachwissen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
9.3.2 Soziale Kompetenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
9.3.3 Entscheidungsfindung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
9.3.4 Verantwortung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
9.4 Der Alltag eines Product Owners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
9.5 Wer sollte Product Owner sein? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
9.5.1 Interne Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
9.5.2 Gewerbliche Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
9.5.3 Ausgelagerte Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
9.5.4 Komponentenentwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
9.6 Product Owner kombiniert mit anderen Rollen . . . . . . . . . . . . . . . . . 220
9.7 Das Product-Owner-Team. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
9.7.1 Product-Owner-Stellvertreter. . . . . . . . . . . . . . . . . . . . . . . . . . 221
9.7.2 Chief Product Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
9.8 Abschließende Bemerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

10 ScrumMaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
10.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
10.2 Wichtigste Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
10.2.1 Coach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
10.2.2 »Dienende Führungskraft« . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

11
Inhaltsverzeichnis

10.2.3 Prozessautorität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227


10.2.4 Schutz vor störenden Einflüssen . . . . . . . . . . . . . . . . . . . . . . . 227
10.2.5 Beseitigung von Hindernissen . . . . . . . . . . . . . . . . . . . . . . . . 227
10.2.6 Berater in der Organisationsentwicklung . . . . . . . . . . . . . . . . 227
10.3 Eigenschaften/Fähigkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
10.3.1 Sachkundig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
10.3.2 Neugierig. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
10.3.3 Geduldig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
10.3.4 Teamfähig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
10.3.5 Schützend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
10.3.6 Transparent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
10.4 Alltag. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
10.5 Die Rolle ausfüllen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
10.5.1 Wer sollte ScrumMaster sein? . . . . . . . . . . . . . . . . . . . . . . . . . 231
10.5.2 Ist die Rolle des ScrumMasters eine Vollzeitbeschäftigung? 232
10.5.3 ScrumMaster in Kombination mit anderen Rollen . . . . . . . . 232
10.6 Abschließende Bemerkungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

11 Das Entwicklungsteam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235


11.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
11.2 Rollenspezifische Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
11.3 Wichtigste Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
11.3.1 Durchführung des Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
11.3.2 Tägliches Untersuchen und Anpassen
(»Inspect and Adapt«). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
11.3.3 Pflege des Product Backlogs . . . . . . . . . . . . . . . . . . . . . . . . . . 237
11.3.4 Den Sprint planen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
11.3.5 Produkt und Prozess untersuchen und anpassen . . . . . . . . . 237
11.4 Eigenschaften/Fertigkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
11.4.1 Selbstorganisierend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
11.4.2 Funktionsübergreifend vielseitig . . . . . . . . . . . . . . . . . . . . . . 240
11.4.3 T-förmige Fertigkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
11.4.4 Die Musketier-Einstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
11.4.5 Kommunikation mit hoher Bandbreite. . . . . . . . . . . . . . . . . . 245
11.4.6 Transparente Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . 246
11.4.7 Die richtige Größe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
11.4.8 Fokussiert und verpflichtet . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
11.4.9 In einer nachhaltigen Geschwindigkeit arbeiten . . . . . . . . . . 249

12
Inhaltsverzeichnis

11.4.10 Langlebig. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250


11.5 Abschließende Bemerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

12 Die Strukturen des Scrum-Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253


12.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
12.2 Funktionsteams versus Komponententeams . . . . . . . . . . . . . . . . . . . 253
12.3 Koordination mehrerer Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
12.3.1 Scrum of Scrums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
12.3.2 Der Release-Train . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
12.4 Abschließende Bemerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

13 Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
13.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
13.2 Teams koordinieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
13.2.1 Grenzen definieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
13.2.2 Ein klares Ziel vorgeben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
13.2.3 Teams bilden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
13.2.4 Die Teamzusammensetzung ändern . . . . . . . . . . . . . . . . . . . 269
13.2.5 Teams bevollmächtigen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
13.3 Teams fördern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
13.3.1 Die Mitarbeiter anspornen. . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
13.3.2 Kompetenz entwickeln. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
13.3.3 Fachliche Anleitung bieten . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
13.3.4 Die Integrität des Teams bewahren . . . . . . . . . . . . . . . . . . . . 273
13.4 Die Umgebung ausrichten und anpassen . . . . . . . . . . . . . . . . . . . . . . 273
13.4.1 Agile Werte fördern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
13.4.2 Organisatorische Hindernisse entfernen . . . . . . . . . . . . . . . . 274
13.4.3 Die internen Abteilungen ausrichten . . . . . . . . . . . . . . . . . . . 274
13.4.4 Die Partner ausrichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
13.5 Den Wertschöpfungsfluss organisieren . . . . . . . . . . . . . . . . . . . . . . . 275
13.5.1 Die Sichtweise des Systems annehmen . . . . . . . . . . . . . . . . . 275
13.5.2 Die wirtschaftlichen Aspekte organisieren. . . . . . . . . . . . . . . 276
13.5.3 Messungen und Berichte überwachen . . . . . . . . . . . . . . . . . . 276
13.6 Projektmanager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
13.6.1 Projektmanagementaufgaben in einem Scrum-Team . . . . . 277
13.6.2 Eine getrennte Projektmanager-Rolle bewahren . . . . . . . . . . 279
13.7 Abschließende Bemerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

13
Inhaltsverzeichnis

Teil III Planen 285

14 Scrum-Planungsprinzipien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
14.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
14.2 Gehen Sie nicht davon aus, dass im Voraus erstellte Pläne
korrekt sind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
14.3 Die Vorabplanung sollte hilfreich, aber nicht exzessiv sein . . . . . . . 288
14.4 Halten Sie sich die Planungsoptionen bis zum letzten
verantwortbaren Augenblick offen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
14.5 Konzentrieren Sie sich stärker auf das Anpassen und
Neuplanen als darauf, einem Plan zu genügen. . . . . . . . . . . . . . . . . . 289
14.6 Den Planungsbestand richtig organisieren . . . . . . . . . . . . . . . . . . . . . 292
14.7 Bevorzugen Sie kleinere und häufigere Releases . . . . . . . . . . . . . . . . 293
14.8 Lernen Sie schnell dazu und weichen Sie vom Plan ab,
wenn es nötig sein sollte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
14.9 Abschließende Bemerkungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

15 Planung auf mehreren Ebenen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297


15.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
15.2 Portfolio-Planung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
15.3 Produktplanung (Visionsbildung) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
15.3.1 Die Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
15.3.2 Allgemeines Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . 300
15.3.3 Produkt-Roadmap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
15.4 Release-Planung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
15.5 Sprint-Planung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
15.6 Tägliche Planung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
15.7 Abschließende Bemerkungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

16 Portfolio-Planung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
16.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
16.1.1 Das Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
16.1.2 Teilnehmer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
16.1.3 Der Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
16.2 Zeitplanungsstrategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
16.2.1 Optimierung der Rendite über die Lebensdauer . . . . . . . . . . 311
16.2.2 Kalkulation der Verzögerungskosten . . . . . . . . . . . . . . . . . . . 312
16.2.3 Schätzungen mit Genauigkeit statt Präzision . . . . . . . . . . . . 315
16.3 Zuflussstrategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
16.3.1 Den wirtschaftlichen Filter anwenden . . . . . . . . . . . . . . . . . . 316

14
Inhaltsverzeichnis

16.3.2 Zufluss- und Abflussrate ausbalancieren . . . . . . . . . . . . . . . . 317


16.3.3 Sich bietende Gelegenheiten schnell ergreifen . . . . . . . . . . . 319
16.3.4 Planen Sie kleinere, häufigere Releases . . . . . . . . . . . . . . . . . 320
16.4 Abflussstrategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
16.4.1 Auf unerledigte Arbeit konzentrieren, nicht auf
untätige Mitarbeiter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
16.4.2 Einrichten eines WIP-Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 322
16.4.3 Auf ein komplettes Team warten . . . . . . . . . . . . . . . . . . . . . . 323
16.5 Strategien zur Überprüfung der in Bearbeitung befindlichen
Produkte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
16.5.1 Die Grenznutzenrechnung verwenden . . . . . . . . . . . . . . . . . 325
16.6 Abschließende Bemerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326

17 Visionsfindung (Produktplanung) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329


17.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
17.1.1 Das Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
17.1.2 Teilnehmer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
17.1.3 Der Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
17.2 SR4U-Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
17.3 Die Entwicklung der Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
17.4 Erstellen eines allgemeinen Product Backlogs . . . . . . . . . . . . . . . . . . 336
17.5 Die Definition der Produkt-Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . 337
17.6 Andere Aktivitäten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
17.7 Wirtschaftlich vernünftige Visionsfindung . . . . . . . . . . . . . . . . . . . . . 342
17.7.1 Eine realistische Vertrauensschwelle anstreben . . . . . . . . . . 343
17.7.2 Konzentrieren Sie sich auf einen kurzfristigen
Planungshorizont . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
17.7.3 Handeln Sie schnell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
17.7.4 Erwerben Sie validiertes Wissen . . . . . . . . . . . . . . . . . . . . . . . 345
17.7.5 Nutzen Sie eine inkrementelle Finanzierung . . . . . . . . . . . . 346
17.7.6 Lernen Sie schnell dazu und weichen Sie ggf. vom
Plan ab (aka Schnelles Scheitern) . . . . . . . . . . . . . . . . . . . . . . 348
17.8 Abschließende Bemerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348

18 Release-Planung (längerfristige Planung) . . . . . . . . . . . . . . . . . . . . . . 349


18.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
18.1.1 Das Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
18.1.2 Teilnehmer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
18.1.3 Der Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351

15
Inhaltsverzeichnis

18.2 Release-Einschränkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353


18.2.1 Alles fest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
18.2.2 Umfang und Termin fest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
18.2.3 Fester Umfang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
18.2.4 Fester Termin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
18.2.5 Variable Qualität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
18.2.6 Einschränkungen aktualisieren . . . . . . . . . . . . . . . . . . . . . . . . 356
18.3 Das Product Backlog pflegen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
18.4 Die minimal freigebbaren Funktionen
(Minimum Releasable Features, MRFs) verfeinern . . . . . . . . . . . . . . 358
18.5 Sprint Mapping (Einordnung der Product-Backlog-Elemente) . . . . . 359
18.6 Release-Planung mit festem Termin . . . . . . . . . . . . . . . . . . . . . . . . . . 361
18.7 Release-Planung mit festem Umfang . . . . . . . . . . . . . . . . . . . . . . . . . 366
18.8 Die Kosten berechnen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
18.9 Kommunizieren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
18.9.1 Den Fortschritt in einem Release mit festem
Umfang kommunizieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
18.9.2 Den Fortschritt in einem Release mit festem
Termin kommunizieren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
18.10 Abschließende Bemerkungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373

Teil IV Sprints 375

19 Die Sprint-Planung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377


19.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
19.1.1 Das Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
19.1.2 Teilnehmer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
19.1.3 Der Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
19.2 Ansätze für die Sprint-Planung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
19.2.1 Zweiteilige Sprint-Planung . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
19.2.2 Einteilige Sprint-Planung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
19.3 Die Kapazität ermitteln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
19.3.1 Was ist die Kapazität? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
19.3.2 Kapazität in Story-Punkten . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
19.3.3 Die Kapazität in Aufwandsstunden. . . . . . . . . . . . . . . . . . . . . 384
19.4 Product-Backlog-Elemente auswählen . . . . . . . . . . . . . . . . . . . . . . . . . 385
19.5 Zuversicht erwerben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386

16
Inhaltsverzeichnis

19.6 Das Sprint-Ziel verfeinern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388


19.7 Die Verpflichtung finalisieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
19.8 Abschließende Bemerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388

20 Die Sprint-Ausführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389


20.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
20.1.1 Das Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
20.1.2 Teilnehmer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
20.1.3 Der Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
20.2 Die Planung der Sprint-Ausführung . . . . . . . . . . . . . . . . . . . . . . . . . . 391
20.3 Flow-Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
20.3.1 Parallele Arbeit und Ausschwärmen. . . . . . . . . . . . . . . . . . . . 392
20.3.2 Welche Arbeit begonnen werden soll . . . . . . . . . . . . . . . . . . . 394
20.3.3 Wie man die Arbeit an den Aufgaben organisiert . . . . . . . . . 395
20.3.4 Welche Arbeit muss erledigt werden? . . . . . . . . . . . . . . . . . . 395
20.3.5 Wer erledigt die Arbeit? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
20.4 Daily Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
20.5 Die Durchführung der Aufgaben – Technische Praktiken . . . . . . . . 397
20.6 Kommunizieren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
20.6.1 Task Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
20.6.2 Das Sprint-Burndown-Chart . . . . . . . . . . . . . . . . . . . . . . . . . . 399
20.6.3 Das Sprint-Burnup-Chart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
20.7 Abschließende Bemerkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403

21 Sprint Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405


21.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
21.2 Teilnehmer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
21.3 Vorarbeiten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
21.3.1 Entscheiden, wen man einlädt . . . . . . . . . . . . . . . . . . . . . . . . 408
21.3.2 Die Aktivität zeitlich planen . . . . . . . . . . . . . . . . . . . . . . . . . . 408
21.3.3 Bestätigen, dass die Sprint-Arbeit erledigt ist . . . . . . . . . . . . 409
21.3.4 Auf die Demonstration vorbereiten . . . . . . . . . . . . . . . . . . . . 410
21.3.5 Festlegen, wer was macht . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
21.4 Das Vorgehen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
21.4.1 Zusammenfassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
21.4.2 Demonstrieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
21.4.3 Diskutieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
21.4.4 Ändern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
21.5 Sprint-Review-Probleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
21.5.1 Abnahmen der PBIs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414

17
Inhaltsverzeichnis

21.5.2 Sporadische Teilnahme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414


21.5.3 Umfangreiche Entwicklungsprojekte . . . . . . . . . . . . . . . . . . . 415
21.6 Abschließende Bemerkungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415

22 Die Sprint-Retrospektive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417


22.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
22.2 Teilnehmer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
22.3 Die Vorarbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
22.3.1 Den Fokus der Retrospektive definieren. . . . . . . . . . . . . . . . . 420
22.3.2 Die Übungen auswählen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
22.3.3 Objektive Daten sammeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
22.3.4 Die Retrospektive strukturieren. . . . . . . . . . . . . . . . . . . . . . . . 422
22.4 Das Vorgehen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
22.4.1 Die Atmosphäre gestalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
22.4.2 Gemeinsamer Kontext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
22.4.3 Einsichten identifizieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
22.4.4 Aktionen festlegen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
22.4.5 Die Retrospektive schließen. . . . . . . . . . . . . . . . . . . . . . . . . . . 433
22.5 Dranbleiben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
22.6 Probleme der Sprint-Retrospektive . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
22.7 Abschließende Bemerkungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436

23 Der Weg nach vorn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437


23.1 Es gibt keinen Endzustand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
23.2 Finden Sie Ihren eigenen Weg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
23.3 Best Practices mit anderen teilen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
23.4 Mit Scrum den Weg nach vorn finden. . . . . . . . . . . . . . . . . . . . . . . . . 439
23.5 Immer weiter! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441

A Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443

B Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447

Stichwortverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469

18
Vorwort von Mike Cohn

Ich habe heute Mittag bei Burger King gegessen. Auf einem Schild an der Wand war zu
lesen, das Restaurant sei »Home of the Whopper« und es gäbe mehr als eine Million Mög-
lichkeiten, einen Whopper zu bestellen. Wenn verschiedene Kombinationen aus zusätzli-
chen oder keinen Gurken, Tomaten, Salatblättern, Käsescheiben usw. zu mehr als einer
Million Möglichkeiten führen können, einen Hamburger herzustellen, dann muss es Milli-
arden mögliche Wege geben, Scrum umzusetzen. Und auch wenn es den einen richtigen
Weg nicht gibt, so gibt es doch bessere und schlechtere Methoden, um Scrum zu imple-
mentieren.
Mit Essential Scrum hilft Kenny Rubin den Lesern, bessere Wege zu finden. Er will mit sei-
nem Buch nichts vorschreiben – er sagt nicht »Sie müssen dies oder jenes tun«. Stattdes-
sen lehrt er die wichtigsten Prinzipien, die dem Erfolg mit Scrum zugrunde liegen, und
zeigt uns Wahlmöglichkeiten auf, die wir haben, um diesen Prinzipien zu genügen. So gibt
es z.B. keine Methode zur Planung von Sprints, die für alle Teams gilt. Was in einem
Unternehmen oder Projekt funktioniert, könnte in einem anderen zum Scheitern führen.
Und so lässt Kenny uns die Wahl. Er beschreibt eine Gesamtstruktur, die den Ausgangs-
punkt dafür bildet, warum Scrum-Teams ihre Sprints planen und welche Ergebnisse die
Sprint-Planung nach sich ziehen sollte, und zeigt alternative Ansätze, die ebenfalls funktio-
nieren. Am Ende aber liegt die Entscheidung bei den einzelnen Teams – und glücklicher-
weise steht diesen Teams nun dieses Buch zur Seite.
Ein unerwarteter Bonus von Essential Scrum ist die visuelle Sprache, die Kenny für die Kom-
munikation über Scrum einführt. Mir haben diese Bilder sehr dabei geholfen, dem Text zu
folgen, und ich vermute, dass sie in künftigen Diskussionen über Scrum zum Allgemein-
gut werden.
Die Welt hat schon lange auf dieses Buch gewartet. Scrum begann als kleines Konzept. Das
erste Buch, in dem es Erwähnung fand – Wicked Problems, Righteous Solutions von DeGrace
und Stahl aus dem Jahr 1990 –, erledigte das auf sechs Seiten. Doch in den mehr als 20
Jahren seit Erscheinen dieses Buches hat sich Scrum ausgeweitet. Es wurden neue Rollen,
Meetings und Artefakte eingeführt und verfeinert. Mit jeder neuen Ergänzung bestand
allerdings auch die Gefahr, dass wir das »Herz« von Scrum verlieren – also den Teil, bei
dem es darum geht, dass das Team plant, wie es etwas machen möchte, einen kleinen Teil
davon erledigt und dann reflektiert, was die Teammitglieder bewerkstelligt und wie gut sie
zusammengearbeitet haben.
Mit Essential Scrum holt Kenny uns zurück in das Herz von Scrum. Und von dort aus kön-
nen die Teams beginnen, die Entscheidungen zu treffen, die notwendig sind, wenn sie
Scrum anwenden und sich zu eigen machen wollen. Dieses Buch erweist sich als unent-

19
Vorwort von Mike Cohn

behrlicher Führer, der den Teams hilft, aus den Milliarden möglichen Wegen zur Umset-
zung von Scrum denjenigen auszuwählen, der zum Erfolg führt.
– Mike Cohn
Autor von Succeeding with Agile, Agile Estimating and Planning und User Stories Applied
www.mountaingoatsoftware.com

20
Vorwort von Ron Jeffries

Als Kenny mich bat, ein Vorwort für Essential Scrum zu schreiben, dachte ich: »Das geht
schnell und leicht, schließlich wird es nur ein kurzes Buch sein, eine direkte und einfache
Beschreibung von Scrum.« Ich kannte Kennys Arbeit und wusste daher, dass es sich gut
lesen lassen und nicht zu lang sein würde. Es gibt nichts Besseres!
Stellen Sie sich meine Überraschung und mein Entzücken vor, als ich feststellte, dass das
Buch praktisch alles behandelt, was man über Scrum wissen muss – sowohl als Anfänger
als auch als alter Hase. Doch damit nicht genug: Kenny beginnt mit den zentralen Konzep-
ten, darunter die agilen Prinzipien, die allen agilen Methoden zugrunde liegen, und einem
schnellen Überblick über das Scrum-Framework. Und dann dringt er tiefer und tiefer und
tiefer vor. Das Buch liest sich trotzdem immer noch gut und ist außerdem unglaublich
umfangreich.
Kenny behandelt zunächst ausführlich die Planung, betrachtet Anforderungen, Stories, das
Backlog, Schätzungen sowie die Velocity. Dann führt er uns tiefer in die Scrum-Prinzipien
ein und hilft uns beim Umgang mit allen Ebenen des Planens und all den Zeithorizonten.
Er beschreibt, wie Sprints geplant, ausgeführt, nachgeprüft und verbessert werden. Und
dabei liefert er mehr als nur die Grundlagen und weist zudem auf wichtige Probleme hin,
die Ihnen auf Ihrem Weg begegnen können.
Mein eigener Fokus in Scrum und den agilen Arbeitsweisen liegt auf den notwendigen Ent-
wicklerfähigkeiten, die sicherstellen sollen, dass Teams in jedem Sprint echte, funktionie-
rende, unternehmensfokussierte Software abliefern. Kenny hilft uns dabei zu verstehen,
wie man Konzepte wie die Velocity und technische Schulden sicher und gut einsetzen
kann. Beides sind wichtige Themen, mit denen Sie sich unbedingt vertraut machen sollten.
Die Velocity verrät uns, wie viel das Team im Laufe der Zeit abliefert. Wir können sie nut-
zen, um ein Gefühl dafür zu entwickeln, wie viel wir schaffen und ob wir uns verbessern.
Kenny warnt uns jedoch, dass wir unsere Geschäftsergebnisse schädigen, wenn wir die
Velocity als Maß für die Leistung verwenden – und er verrät uns auch, woran das liegt.
Technische Schulden sind zu einem sehr weit gefassten Begriff geworden, der sich auf fast
alles bezieht, was im Code schiefgehen kann. Deshalb klärt Kenny für uns die verschiede-
nen Bedeutungen auf und hilft uns dabei zu verstehen, warum wir uns um diese scheinbar
technischen Details kümmern sollten. Mir gefällt vor allem seine Erklärung, dass Druck,
der auf das Team ausgeübt wird, ganz unweigerlich dazu führt, dass die Qualität und die
Pünktlichkeit leiden.
Scrum nutzt wie alle agilen Methoden einen untersuchenden Ansatz mit schnellem Feed-
back. Kenny erzählt uns in diesem Zusammenhang auch davon, wie er einmal Lochkarten
benutzt hat – und das erinnerte mich an meine früheste Erfahrung mit Rechentechnik,
viele Jahre, bevor Kenny seine erste Lochkarte gesehen hat.

21
Vorwort von Ron Jeffries

Als College-Student hatte ich das Glück, eine Art Praktikum im Hauptquartier der Strategic
Air Command in Omaha machen zu dürfen. Damals wurden noch Lochkarten benutzt.
Meine Karten wurden im SAC-Hauptquartier mehrere Etagen unter die Erde geschickt und
auf dem Computer ausgeführt, der auch in einem Krieg eingesetzt werden würde. Ich hatte
das Glück, ein oder zwei Durchläufe pro Tag zu bekommen.
Sobald meine Sicherheitsfreigabe kam, ging ich mitten in der Nacht hinunter in den Com-
puterraum. Ich beschwatzte Sergeant Whittaker, mich meine eigenen Programme ausfüh-
ren zu lassen. Dazu setzte ich mich an die Konsole der Maschine – ja genau, an die
Maschine, deren Hauptaufgabe es sein würde, einen Atomwaffenangriff durchzuführen.
Aber nur keine Panik, der rote Knopf war nicht in diesem Raum.
Durch das direkte Arbeiten an der Maschine schaffte ich zehnmal mehr Arbeit, als wenn
ich darauf hätte warten müssen, dass meine Karten nach unten und die gedruckten Ergeb-
nislisten wieder nach oben gebracht worden wären. Die Feedbacks kamen schneller, ich
lernte schneller und meine Programme funktionierten eher.
Und genau darum geht es auch bei Scrum. Anstatt Monate oder gar Jahre darauf zu warten,
zu erfahren, was die Programmierer eigentlich machen, finden wir das mit Scrum alle paar
Wochen heraus. Ein Scrum-Product-Owner mit einem wirklich guten Team sieht schon
nach wenigen Tagen, wie die Funktionen Form annehmen!
Das ist es auch, worum es in Kennys Buch geht. Wenn Scrum für Sie neu ist, dann lesen
Sie es von vorn bis hinten durch und legen Sie es anschließend nicht allzu weit weg. Wenn
Sie Scrum schon eine Weile benutzen, dann überfliegen Sie es und halten Sie es anschlie-
ßend weiterhin in griffbereiter Nähe.
Wenn Sie über irgendetwas nachgrübeln, was gerade in Ihrem Team passiert oder sich fra-
gen, welche Dinge Sie einmal ausprobieren könnten, dann nehmen Sie das Buch zur Hand
und schauen Sie sich um. Sie werden aller Wahrscheinlichkeit nach fündig werden.
– Ron Jeffries

22
Einleitung

Dieses Buch beschreibt das Wesen von Scrum – die Dinge, die Sie wissen müssen, wenn
Sie Scrum erfolgreich einsetzen wollen, um innovative Produkte und Dienstleistungen
bereitzustellen.

Was ist das Wesen von Scrum?


Scrum beruht auf einer kleinen Menge an Kernwerten, -prinzipien und -praktiken (zusam-
menfassend als Scrum-Framework bezeichnet). Organisationen, die Scrum einsetzen,
müssen das Scrum-Framework in seiner Gänze annehmen. Das muss sicher nicht in der
ganzen Organisation auf einmal geschehen, aber zumindest in den ersten Teams, die
Scrum benutzen werden. Scrum komplett anzunehmen, bedeutet jedoch nicht, dass die
Organisationen dieses Entwicklungsverfahren entsprechend einer vorgefertigten Ein-
heitsformel umsetzen müssen. Es bedeutet vielmehr, dass sie sich immer an das Scrum-
Framework halten müssen, während sie ihre eigene passende Mischung aus den Vorge-
hensweisen für ihre individuelle Scrum-Umsetzung entwickeln.
Essential Scrum kombiniert die Werte, Prinzipien und Praktiken von Scrum mit einer Reihe
bewährter Ansätze, die mit dem Scrum-Framework konsistent sind, aber nicht von ihm
vorgegeben werden. Einige dieser Ansätze werden sich für Ihre Situation eignen, andere
wiederum nicht. Jeder Ansatz muss untersucht und an Ihre jeweiligen Umstände ange-
passt werden.

Die Ursprünge dieses Buches


Als Agile/Scrum-Berater und -Trainer werde ich oft nach einem Referenzbuch für Scrum
gefragt – einem, das einen umfassenden Überblick über das Scrum-Framework bietet und
darüber hinaus die beliebtesten Ansätze für die Anwendung von Scrum präsentiert. Da es
mir nicht gelungen ist, ein einziges Buch zu finden, das diese Themen auf einem Niveau
behandelt, das für heutige Anwender sinnvoll wäre, habe ich immer gleich eine ganze
Sammlung an Büchern empfohlen: einige, die das Scrum-Framework diskutieren, aber
nicht mehr aktuell oder in gewisser Weise unvollständig sind, einige hoch angesehene
Agile-Bücher, die sich nicht ausschließlich auf Scrum beschränken, und eine Handvoll
Bücher, die sich auf einen speziellen Aspekt von Scrum oder einen bestimmten Ansatz
konzentrieren, aber nicht das komplette Scrum-Framework in aller Tiefe behandeln. Das
sind viele Bücher für jemanden, der nur eine einzige Ressource sucht, die das Wesen von
Scrum abdeckt!

23
Einleitung

Die Begründer von Scrum (Jeff Sutherland und Ken Schwaber) bieten eine Scrum-spezifi-
sche Publikation namens The Scrum Guide. Dieses kurze Dokument (ca. 15 Seiten) wird von
seinen Autoren als das »definitive Regelbuch zu Scrum und die Dokumentation von Scrum
selbst« beschrieben (Schwaber und Sutherland 2011). Sie vergleichen ihr Werk mit den
Regeln des Schachspiels, die »beschreiben, wie die Figuren gesetzt werden, wie gewechselt
wird, was ein Gewinn ist usw.«. Obwohl The Scrum Guide als Überblick oder Regelwerk zu
Scrum ganz nützlich ist, ist es von seiner Anlage her nicht als umfassende Quelle für alle
wesentlichen Scrum-Kenntnisse gedacht. Stellen Sie sich zur Verdeutlichung einfach vor,
Sie würden einem Schachanfänger eine 15-seitige Beschreibung der Regeln des Schach-
spiels geben und dann von ihm erwarten, dass er anschließend ein anständiger Spieler ist.
Das funktioniert nicht. Genauso wenig können Sie erwarten, dass jemand The Scrum Guide
liest und sofort gute Ergebnisse abliefert.
Dieses Buch, Essential Scrum, ist der Versuch, die eine entscheidende, bisher fehlende
Quelle für alles wesentliche Wissen über Scrum bereitzustellen. Es enthält eine tiefgrei-
fende Diskussion der Scrum-Prinzipien, -werte und -praktiken – eine, die in den meisten
Fällen mit führenden Köpfen aus der Agile-Szene sowie dem The Scrum Guide konform
geht. (Ich weise darauf hin und erkläre, wo von den allgemein bekanntesten Ansichten
abgewichen wird.) Dieses Buch beschreibt außerdem Ansätze, die mit dem Scrum-Frame-
work konsistent sind und erfolgreich von mir und den von mir trainierten Teams eingesetzt
wurden. Es soll keine anderen Bücher ersetzen, die eine tiefgreifende vertikale Behandlung
einer vorhandenen Scrum-Praxis oder -Vorgehensweise liefern. Solche Bücher ergänzen
vielmehr dieses Buch und gehen teilweise sogar darüber hinaus. Stellen Sie sich Essential
Scrum lieber als einen Ausgangspunkt Ihrer Reise vor, auf der Sie Scrum einsetzen, um
Ihre Kunden zu erfreuen.

Zielgruppe
Für die vielen Tausend Leute, die meine Kurse »Working on a Scrum Team«, »Certified
ScrumMaster« und »Certified Scrum Product Owner« besucht haben, und die vielen
Teams, die ich trainiert habe, wird dieses Buch Themen, die wir bereits diskutiert haben,
wieder auffrischen und vielleicht auch näher erläutern. Und für die noch viel größere
Anzahl an Leuten, mit denen ich noch nicht das Vergnügen hatte zusammenzuarbeiten,
wird es entweder eine erste Einführung in Scrum und agile Praktiken sein oder eine
Chance, Scrum in einem anderen Licht zu sehen und die eigene Anwendung von Scrum zu
verbessern.
Ich habe dieses Buch nicht für eine bestimmte Rolle geschrieben – es ist nicht speziell für
Product Owner oder ScrumMaster oder Mitglieder des Entwicklungsteams gedacht. Statt-
dessen soll es allen, die direkt oder indirekt mit Scrum zu tun haben, ein gemeinsames Ver-
ständnis von Scrum und den Prinzipien, auf denen es beruht, vermitteln. Ich hoffe, dass
Ihre Organisation mit dieser gemeinsamen Grundlage in eine bessere Lage versetzt wird,
Scrum erfolgreich einzusetzen.
Ich stelle mir vor, dass jedes Mitglied des Scrum-Teams dieses Buch auf seinem Schreib-
tisch hat, aufgeschlagen in einem Kapitel, das für die gerade ausgeführte Arbeit relevant ist.
Ich stelle mir außerdem Manager auf allen Ebenen der Organisation vor, die das Buch
lesen, weil sie verstehen wollen, wie sich Scrum effektiv zum Organisieren der Arbeit ein-

24
Der Aufbau dieses Buches

setzen lässt und welche organisatorischen Änderungen erforderlich sind, um Scrum erfolg-
reich umzusetzen. Organisationen, die einen anderen agilen Ansatz als Scrum benutzen
oder benutzen wollen, werden die hier enthaltenen Informationen nichtsdestotrotz für ihre
spezielle Version des agilen Denkens hilfreich finden.

Der Aufbau dieses Buches


Dieses Buch beginnt mit einer kurzen Einführung in Scrum (Kapitel 2) und schließt mit
einer Diskussion des vorwärtsweisenden Weges (Kapitel 23). Die restlichen Kapitel sind in
vier Teile gegliedert:
쐽 Teil I – Kernkonzepte (Kapitel 2–8): Scrum-Framework, agile Prinzipien, Sprints, An-
forderungen und User Stories, Product Backlog, Schätzungen und Velocity sowie tech-
nische Schulden
쐽 Teil II – Rollen (Kapitel 9–13): Product Owner, ScrumMaster, Entwicklungsteam,
Scrum-Team-Strukturen und -Manager
쐽 Teil III – Planung (Kapitel 14–18): Scrum-Planungsprinzipien, mehrstufige Planung,
Portfolio-Planung, Visionsbildung/Produktplanung und Release-Planung
쐽 Teil IV – Sprints (Kapitel 19–22): Sprint-Planung, Sprint-Ausführung, Sprint Review
und Sprint-Retrospektive

Wie Sie dieses Buch benutzen


Wie man es erwarten würde, schrieb ich dieses Buch in der Annahme, dass die meisten
Leute es strikt von vorn nach hinten lesen würden. Wenn Sie mit Scrum noch nicht so ver-
traut sind, dann sollten Sie auch tatsächlich so vorgehen, weil die Kapitel normalerweise
aufeinander aufbauen. Sollten Sie sich zunächst einmal einen Komplettüberblick über das
Scrum-Framework verschaffen wollen, dann lesen Sie Kapitel 2.
Für diejenigen, die bereits mit Scrum vertraut sind, eignet sich dieses Buch als Scrum-Refe-
renz. Falls Sie sich für Sprint-Retrospektiven interessieren, dann gehen Sie direkt zu Kapi-
tel 22. Wollen Sie die Feinheiten des Product Backlogs untersuchen, lesen Sie Kapitel 6. Ich
empfehle jedoch allen – auch denen, die Scrum schon kennen – dringend, Kapitel 3 kom-
plett zu lesen. Die Prinzipien, die dort dargestellt werden, bilden die Grundlage für das
Scrum-Framework und den Rest des Buches – und dabei handelt es sich nicht einfach um
eine Wiederholung der Werte und Prinzipien des Agile Manifesto (Beck et al. 2001), die Sie
in vielen anderen Beschreibungen von Scrum finden.

Visual AGILExicon
Ich bin stolz, in diesem Buch eine neue visuelle Sprache zur Beschreibung von Scrum
präsentieren zu dürfen – Visual AGILExicon. Mithilfe dieser Sprache wurden die mehr
als 200 Grafiken in diesem Buch erstellt. Visual AGILExicon besteht aus einem Voka-
bular aus Icons, die speziell zur Darstellung der wesentlichen Scrum-Rollen, -Artefakte
und -Aktivitäten entworfen wurde, und stellt somit eine effektive Methode dar, um Kon-

25
Einleitung

zepte zu vermitteln und das allgemeine Verständnis von Scrum zu verbessern. Wenn
Sie Visual AGILExicon in ihrer ganzen Farbenpracht genießen wollen, finden Sie unter
www.innolution.com weiterführende Informationen. Diese Website enthält auch eine
Vielzahl an Ressourcen und Diskussionen im Zusammenhang mit diesem Buch.

Legen wir los


Wie auch immer Ihre Rolle oder Situation aussieht: Es gibt sicher einen Grund, weshalb Sie
dieses Buch gewählt haben. Nehmen Sie sich Zeit, um Scrum kennenzulernen. Auf den
folgenden Seiten wird ein mächtiges Framework vorgestellt, das Sie sich zu eigen machen
können und das es Ihnen ermöglicht, die Art und Weise zu verbessern, in der Sie Produkte
und Dienstleistungen entwickeln und ausliefern, um Ihre Kunden zufriedenzustellen.

26
Danksagungen

Dieses Buch wäre ohne die Hilfe vieler Leute, einschließlich der Tausenden von Teilneh-
mern an meinen Agile-Kursen und Trainingssessions, nicht möglich gewesen. All diese
Menschen namentlich aufzuführen, wäre schier unmöglich, daher werde ich mich hier auf
einzelne Personen beschränken. Aber auch diejenigen, die ich an dieser Stelle nicht
namentlich erwähne, sollen wissen, dass all unsere Diskussionen und E-Mail-Korrespon-
denzen von unschätzbarem Wert für mich gewesen sind und dieses Buch definitiv beein-
flusst haben!
Mein besonderer Dank gilt Mike Cohn, Rebecca Traeger und Jeff Schaich. Ohne die unver-
zichtbaren Beiträge dieser drei Menschen wäre dieses Buch nur ein Schatten seiner selbst.
Mike Cohn ist mein Freund und Kollege, seit wir im Jahr 2000 bei Genomica das erste Mal
zusammengearbeitet haben. Er war so großzügig, mein Buch in die Mike Cohn Signature
Series aufzunehmen. Durch die Verbindung zu Mike und den anderen angesehenen Auto-
ren dieser Buchreihe fällt ein Teil des Glanzes auch auf mich, wie meine Eltern sagen wür-
den. Mike war mein Ansprechpartner, wann immer ich Ideen wälzen oder Buchstrategien
diskutieren wollte. Er hat trotz seines irren Terminkalenders immer Zeit gefunden, die ein-
zelnen Kapitel zu lesen und mir seine Meinung dazu zu sagen. Die Zusammenarbeit mit
Mike im Laufe der letzten Jahre war ausgesprochen lohnend – und ich hoffe, wir können
sie auch in der Zukunft fortsetzen.
Rebecca Traeger war bei diesem Buch meine persönliche Lektorin. Wir arbeiten bereits seit
meiner Zeit als Managing Director der Scrum Alliance im Jahr 2007 zusammen. Damals
war Rebecca Redakteurin der Website von Scrum Alliance. Durch diese Arbeit wurde sie
zur führenden Fachredakteurin zum Thema Agile. Gleich als ich anfing, dieses Buch zu
schreiben, habe ich Rebecca gefragt, ob sie wieder mit mir zusammenarbeiten würde. Und
zu meinem großen Glück hat sie zugesagt. Sie war stets die Erste, die die fertiggestellten
Kapitel zu sehen bekam. Manchmal brachte mich ihr Feedback sogar etwas in Verlegenheit,
weil sie meine Ausführungen häufig so umformulierte, dass sie verständlicher und auch
nachvollziehbarer waren. Sollten Sie also irgendeinen Abschnitt dieses Buches als ganz
besonders gut beschrieben empfinden, dann können Sie sicher sein, dass das an Rebecca
liegt – im anderen Fall habe ich vermutlich idiotischerweise ihre Vorschläge ignoriert.
Jeff Schaich ist ein außergewöhnlicher Künstler und Designer. Wir haben an so vielen ver-
schiedenen Kunstprojekten zusammengearbeitet, dass ich mich gar nicht mehr an alle
erinnern kann. Bereits in der Frühphase dieses Buches hatte ich den Wunsch, ein Agile/
Scrum-Vokabular aus Icons zu schaffen, das als Grundlage für meine Trainingspräsentati-
onen und viele der mehr als 200 Abbildungen in diesem Buch dienen könnte. Ich wusste,
dass ich dafür einen großartigen Designer brauchen würde. Und Jeff nahm die Herausfor-
derung an. Manchmal erschien mir die Arbeit an diesem Buch wie zwei separate Projekte –

27
Danksagungen

einerseits das Schreiben und andererseits die Ausarbeitung der künstlerischen Konzepte.
Ich weiß wirklich nicht, was länger gedauert hat – allerdings steht zweifelsfrei außer Frage,
dass dieses Buch ohne Jeffs künstlerischen Beitrag beträchtlich schlechter geworden wäre.
Ich fühle mich äußerst geehrt, dass sowohl Mike Cohn als auch Ron Jeffries, zwei Kory-
phäen der agilen Gemeinde, Vorwörter zu diesem Buch geschrieben haben! Sie haben es
auf ihre jeweils ganz eigene Weise geschafft, es in einen Kontext zu setzen und die Tür für
eine Diskussion zu öffnen. Außerdem: Mike, hör auf, bei Burger King zu essen, und danke,
Ron, dass du den roten Knopf nicht gedrückt hast!
Außerdem möchte ich den vielen Menschen danken, die sich die Zeit genommen haben,
die Kapitel fachlich zu begutachten und mir ihre Meinungen mitzuteilen. Für ihr umfang-
reiches Feedback möchte ich mich vor allem bedanken bei: Joe Balistrieri, Johannes Brod-
wall, Leyna Cotran, Martine Devos, Scott Duncan, Ilan Goldstein, John Hebley, Geir
Hedemark, James Kovacs, Lauri Mackinnon, Robert Maksimchuk und Kevin Tureski.
Für ihr ausgezeichnetes Feedback zu ausgewählten Kapiteln danke ich außerdem: Lyssa
Adkins, John Bauer, Sameer Bendre, Susan Briscoe, Pawel Brodzinski, Rowan Bunning,
Josh Chappell, Lisa Crispin, Ward Cunningham, Cornelius Engelbrecht, Julia Frazier, Brin-
dusa Gabur, Caroline Gordon, Drew Jemilo, Mike Klimkosky, Tom Langerhorst, Bjarne Lar-
sen, Dean Leffingwell, Maurice le Rutte, David Luzquiños, Lv Yi, Shay McAulay, Armond
Mehrabian, Sheriff Mohamed, Cuan Mulligan, Greg Pease, Roman Pichler, Jacopo Romei,
Jens Schauder, Bill Schroeder, Yves Stalgies, Branko Stojaković, Howard Sublett, Julie Syl-
vain, Kevin Tambascio, Stephen Wolfram und Michael Wollin.
Darüber hinaus gilt mein Dank auch den Mitarbeitern bei Pearson, die sich bei diesem Pro-
jekt als großartige Partner erwiesen haben. Sie tolerierten meine Verspätungen mit viel
Geduld und haben mich stets ermutigt. Besonderer Dank geht an Chris Guzikowski, der
dieses Buchprojekt von Anfang an begleitet hat. Er war von meinem ersten Pearson-Treffen
in einer Kneipe in Lexington, MA, bis zum Ende der Produktion mit dabei. Auch möchte
ich Olivia Basegio danken, die sich gekonnt um die Logistik gekümmert hat, sowie Julie
Nahil, die das Projekt ganz fantastisch überwacht hat. Danke auch an Barbara Wood für
ihre großartige Hilfe beim Aufpolieren des Manuskripts und an Gail Cocker für das
Zusammensetzen der Grafiken zu einem wunderbaren Ganzen.
Meiner Assistentin Lindsey Kalicki bin unglaublich dankbar dafür, dass ich viele wichtige
Aufgaben auf sie abladen und mich dadurch weiter auf die Entwicklung des Buches kon-
zentrieren konnte. Ich habe Glück, mit einem solchen Profi zusammenarbeiten zu dürfen.
Die größte Anerkennung gebührt jedoch meiner Familie – Jenine, Jonah und Asher – und
der entscheidenden Rolle, die sie gespielt hat. Ich habe ihnen während der langen Entste-
hungsphase dieses Buches sehr viel abverlangt. Keine noch so große Dankbarkeit kann den
Druck auf meine Familie und unsere verlorene gemeinsame Zeit wiedergutmachen.
Jenine ist meine wahre Seelenverwandte und hat mir durch die Höhen und Tiefen beim
Schreiben dieses Buches stets zur Seite gestanden. Wenn ich auch nur versuchen wollte, all
die Opfer aufzuzählen, die sie gebracht hat, damit ich schreiben konnte, würde dieses Buch
auf den doppelten Umfang anwachsen. Ohne sie hätte ich es nicht geschafft!
Das Witzige ist: In dem Jahr nach unserer Heirat 1993 brachte ich mein erstes Buch,
Succeeding with Objects, heraus. Damals musste ich Jenine versprechen, dass ich nie wieder
ein Buch schreiben würde. Zu meinem Glück verblassen die Erinnerungen nach 15 Jahren

28
Danksagungen

und die Belastung schien rückblickend nicht so schlimm gewesen zu sein. Deswegen war
ich mehr als überrascht, als sie mich drängte, dieses Buch zu schreiben! Sie hat mir bisher
noch nicht gesagt, dass ich Buch Nummer Drei nicht schreiben dürfe, aber ich vermute,
dass es weitere 15 Jahre dauern dürfte, bis die Erinnerung an dieses Buch so weit in Verges-
senheit geraten ist, dass wir beide ein weiteres schreiben wollen!
Natürlich weiß ich auch die liebende Unterstützung meiner beiden Söhne Jonah und Asher
außerordentlich zu schätzen. Sie haben auf Zeit mit ihrem Dad verzichtet, damit ich schrei-
ben konnte. Sie waren immer da, um Ideen zu wälzen und etwas zu diesem Buch beizutra-
gen. Nicht wenige ihrer inhaltlichen und künstlerischen Vorschläge haben es in das Buch
geschafft – dank ihnen ist es besser geworden! Ich hoffe, sie haben den Wert der Beharr-
lichkeit erkannt und gelernt, dass selbst die abschreckendste Arbeit zu schaffen ist, wenn
man immer einen Schritt nach dem anderen macht und nicht aufgibt.
Schließlich möchte ich meinen Eltern, Joyce und Manny Rubin, für all ihre Liebe und
Unterstützung danken. Ohne ihren Einfluss wäre dieses Buch niemals möglich gewesen.
Leider hat keiner von beiden mehr seine Veröffentlichung erlebt. Mom verstarb im Januar
2012 und Dad im Juli 2012. Sie hinterließen in meinem Leben und dem meiner Familie
eine Leere, die niemals wieder gefüllt werden kann. Sie waren für viele, die sie gekannt
haben, ganz besondere Menschen. Mom und Dad, ich vermisse euch mehr, als sich mit
Worten ausdrücken lässt.

29
Über den Autor

Kenny Rubin bietet Scrum- und Agile-Training und -Beratung an, um Unternehmen zu
helfen, Produkte auf effektive und wirtschaftlich vernünftige Weise zu entwickeln. Als Cer-
tified Scrum Trainer hat Kenny mehr als 19.000 Menschen in agilen Techniken und
Scrum, Smalltalk-Entwicklung, der Organisation objektorientierter Projeke und im Über-
gangsmanagement unterwiesen. Dabei hat er mehr als 200 Unternehmen beraten, von
Start-ups bis zu Fortune-10-Unternehmen.
Kenny war der erste Managing Director der weltweit agierenden Scrum Alliance, einer
nicht-kommerziellen Organisation, die sich auf die erfolgreiche Übernahme von Scrum
konzentriert. Er ist außerdem Co-Autor des 1995 erschienenen Buches Succeeding with
Objects: Decision Frameworks for Project Management. Seinen Bachelor of Science in Informa-
tion and Computer Science hat Kenny am Georgia Institute of Technology erworben, sei-
nen Master of Science in Computer Science hat er an der Stanford University gemacht.
Ursprünglich war Kenny hauptsächlich mit der Objektorientierung befasst. Er begann 1985
als Smalltalk-Entwickler an einem NASA-finanzierten Projekt und entwickelte das erste
Blackboard-Expertensystem außerhalb von LISP. 1988 wechselte er zu ParcPlace Systems,
einem Start-up-Unternehmen, das aus Xerox PARC hervorgegangen war und dessen Ziel
darin bestand, die objektorientierte Technik aus den Forschungslaboren zu befreien und
auf die Welt loszulassen. Als Berater für Smalltalk-Entwicklung bei vielen unterschiedli-
chen Organisationen in den späten 1980ern und den 1990ern gehörte Kenny zu den frü-
hen Verfechtern agiler Praktiken. Das erste Mal setzte er Scrum im Jahr 2000 bei der
Entwicklung von Bioinformatik-Software ein.
Im Laufe seiner Karriere hat Kenny viele Positionen eingenommen. So war er unter ande-
rem als Scrum-Product-Owner, ScrumMaster und Mitglied von Entwicklungsteams, aber
auch im Management erfolgreich tätig, als CEO, COO, VP of Engineering, VP of Product
Management und VP of Professional Services. Er überwachte die Entwicklung von fünf
kommerziellen Software-Suites und generierte damit Einnahmen von insgesamt mehr als
200 Millionen Dollar. Darüber hinaus war er unmittelbar an der Beschaffung von mehr als
150 Millionen Dollar an Venture Capital beteiligt und hat dabei geholfen, zwei Unterneh-
men an die NASDAQ zu bringen.
Dank seiner vielfältigen Erfahrungen besitzt Kenny die außergewöhnliche Fähigkeit,
Scrum und seine Implikationen aus verschiedenen Perspektiven gleichermaßen gut zu ver-
stehen (und zu erklären): vom Entwicklungsteam bis hin zum Vorstand.

31
Kapitel 1

Einführung

Am 21. Juni 2000 war ich als stellvertretender Vorstandsvorsitzender bei Genomica tätig,
einer Bioinformatik-Firma in Boulder, Colorado. Dieses Datum ist mir deshalb in besonde-
rer Erinnerung, weil mein Sohn Asher an diesem Tag um 1 Uhr nachts geboren wurde.
Und seine Geburt war zweifellos ein guter Auftakt für diesen Tag. Asher wurde tatsächlich
am berechneten Geburtstermin geboren (das passiert in den USA nur bei etwa 5% der
Geburten) – wir (oder besser gesagt meine Frau Jenine) hatten unser Neun-Monats-»Pro-
jekt« also absolut pünktlich abgeschlossen. Und zur Krönung des Ganzen war ihm auch
noch ein sehr hoher Apgar-Wert attestiert worden, was eindeutig belegte, dass wir ein
gesundes, hochwertiges »Erzeugnis« produziert hatten! Unser wichtigster »Anteilseigner«
(Stakeholder), unser älterer Sohn Jonah, war begeistert, einen jüngeren Bruder zu haben.
Ein pünktlich geliefertes, hochwertiges Produkt und noch dazu hocherfreute Anteilseigner
– es war wirklich ein guter Tag!
Nach einem kurzen Nickerchen rief ich meine E-Mails ab und sah, dass der Vorstandschef
von Genomica eine dringende Nachricht geschickt hatte, in der er mich bat, um 8 Uhr zu
einem Treffen des Vorstands zu erscheinen. Widerstrebend verließ ich das Krankenhaus
und ging zu der Sitzung.
Als ich ankam, erfuhr ich, dass der Leiter der technischen Entwicklungsabteilung am
Abend zuvor gefeuert worden war und ich das 90 Leute starke Technikteam geerbt hatte.
Das überraschte mich allerdings nicht: Bereits seit mehreren Monaten hatten die Füh-
rungsmannschaft und der Vorstand Genomicas Unfähigkeit diskutiert, wertige Produkte
von guter Qualität pünktlich auszuliefern – und der Leiter der technischen Entwicklung
hatte im Mittelpunkt dieser Diskussion gestanden.
Jetzt war ich verantwortlich dafür, die Ergebnisse unserer Produktentwicklung deutlich zu
verbessern. Ich erinnere mich noch, wie paradox es mir vorkam, dass zwei so bedeutsame
Ereignisse wie die glückliche Geburt meines Sohnes und die Übernahme meines neuen
Verantwortungsbereichs auf ein und denselben Tag fielen.
Da ich mit dem Verkauf und dem Marketing ohnehin schon ziemlich ausgelastet war,
gestand man mir zu, dass ich nach meinem Ermessen einen Technikchef einstellen
konnte, der mir direkt unterstellt war. Also besetzte ich diesen Posten mit Mike Cohn
(Cohn 2004; Cohn 2006; Cohn 2010) und wir beschlossen, es mit Scrum zu versuchen.

1.1 Was ist Scrum?


Scrum ist ein agiler Ansatz zur Entwicklung innovativer Produkte und Dienstleistungen.
Abbildung 1.1 zeigt ein solches agiles Entwicklungskonzept in einer einfachen, generischen
Variante.

33
Kapitel 1
Einführung

Bei einem agilen Ansatz beginnen Sie zunächst mit einem Product Backlog – einer priori-
sierten Liste der Funktionen und Fähigkeiten, die erforderlich sind, um ein erfolgreiches
Produkt zu entwickeln. Wenn Sie sich an das Product Backlog halten, arbeiten Sie immer
zuallererst die wichtigsten Aufgaben ab, also diejenigen mit der höchsten Priorität. Sollten
Ihnen dann irgendwann die Ressourcen ausgehen (wie z.B. die Zeit), haben somit alle
noch verbleibenden Aufgaben eine niedrigere Priorität als die bereits abgeschlossenen
Arbeiten.

Product Backlog
Funktion A

Iterations-Review
Funktion B
Iterationsplanung

Funktion C

Funktion A

Funktion B

Funktion C

Iteration (1 Woche bis 1 Kalendermonat)

Abb. 1.1: Übersicht über die agile Entwicklung

Die Arbeiten selbst werden in kurzen, zeitlich fest begrenzten (time-boxed) Iterationen
durchgeführt, wobei sich der hierfür vorgesehene Zeitrahmen normalerweise zwischen
einer Woche und einem Kalendermonat bewegt. Während der einzelnen Iterationen erle-
digt ein Team die Arbeiten, die nötig sind, um abgeschlossene, funktionierende Elemente
herzustellen, die dann in die Produktion überführt werden können. Das Team organisiert
sich selbst und kann sich mehrerer Funktionen annehmen – wie etwa dem Entwerfen,
Bauen und Testen.
Üblicherweise ist in der Planung eines Product Backlogs deutlich mehr Arbeit vorgesehen,
als ein Team innerhalb einer kurzen Iteration bewältigen kann. Deshalb legt das Team zu
Beginn jeder Iteration zunächst einmal fest, welche hoch priorisierte Teilmenge des Pro-
duct Backlogs in der kommenden Iteration erledigt werden soll. In dem Beispiel aus Abbil-
dung 1.1 ist es z.B. übereingekommen, sich den Funktionen A, B und C zu widmen.
Am Ende der Iteration prüft das Team die abgeschlossenen Funktionen noch einmal
gemeinsam mit den Stakeholdern, um deren Feedback zu erhalten. Und je nachdem, wel-
che Kritikpunkte dabei zutage treten, können der Product Owner und das Team ihre Pläne
für die nächsten Arbeitsschritte ändern. Falls die Stakeholder bei genauerer Betrachtung
einer bereits abgeschlossenen Funktion also etwa feststellen, dass noch eine andere Funk-

34
1.2
Die Ursprünge von Scrum

tion in das Produkt eingebracht werden muss, die zuvor unberücksichtigt geblieben war,
kann der Product Owner hierfür einfach ein entsprechendes neues Element anlegen, das
dann an der passenden Stelle im Product Backlog eingefügt und in einer künftigen Itera-
tion bearbeitet wird.
Am Ende der einzelnen Iterationen sollte das Team ein potenziell auslieferungsfähiges Pro-
dukt haben (oder ein Inkrement des Produkts, also eine Produktfunktionalität), das prinzi-
piell freigegeben werden könnte. Sollten individuelle Freigaben nach jeder Iteration
hingegen nicht sinnvoll sein, könnten alternativ auch Funktionssätze aus mehreren Itera-
tionen zusammen freigegeben werden.
Nach Beendigung einer Iteration fängt der ganze Prozess mit der Planung der nächsten Ite-
ration wieder von vorn an.

1.2 Die Ursprünge von Scrum


Die reiche Geschichte von Scrum lässt sich bis zu einem Artikel im Harvard Business Review
aus dem Jahre 1986 zurückverfolgen: »The New New Product Development Game«
(Takeuchi und Nonaka 1986). Dieser Artikel beschreibt, wie Unternehmen wie Honda,
Canon und Fuji-Xerox mit einem skalierbaren, teambasierten Ansatz für die ganzheitliche
Produktentwicklung erstklassige Ergebnisse erzielten. Er betont außerdem die Bedeutung
selbstorganisierter Teams mit Entscheidungsvollmacht und umreißt die Rolle des Manage-
ments im Entwicklungsprozess.
Die besondere Relevanz dieses Artikels von 1986 bestand darin, dass er viele der Konzepte
miteinander verband, die am Ende das ausmachten, was wir heute als Scrum bezeichnen.
Scrum ist kein Akronym, sondern ein Begriff aus dem Rugby, wo er sich auf eine Methode
bezieht, das Spiel nach einem Verstoß oder einem Aus des Balls wieder aufzunehmen. Im
Prinzip bezeichnet es das Gedränge, wenn zwei zum Angriff ansetzende Spielerhorden mit
gesenkten Köpfen und verschränkten Armen aufeinander losstürmen, um in den Besitz
des Balls zu gelangen.
Takeuchi und Nonaka benutzten diese Rugby-Metapher zur Beschreibung der Produktent-
wicklung:
Der ... »Stafettenlauf«-Ansatz für die Produktentwicklung ... widerspricht vermutlich
dem Streben nach maximaler Geschwindigkeit und Flexibilität. Allerdings ist ein
holistisches oder »Rugby«-Vorgehen – bei dem das Team als Einheit agiert und sich auf
dem Weg zum Tor den Ball zuspielt – für die heutigen Konkurrenzbedingungen mög-
licherweise besser geeignet.
1993 schufen Jeff Sutherland und sein Team bei der Easel Corporation den Scrum-Pro-
zess, um ihn bei der Software-Entwicklung einzusetzen. Dabei kombinierten sie Kon-
zepte aus dem Artikel von 1986 mit Konzepten aus der objektorientierten Entwicklung,
der empirischen Prozesssteuerung, der iterativen und inkrementellen Entwicklung, der
Software-Prozess- und -Produktivitätsforschung und aus komplexen adaptiven Systemen.
1995 veröffentlichte Ken Schwaber bei der OOPSLA 1995 einen ersten Artikel zum
Thema Scrum (Schwaber 1995). Seither haben Schwaber und Sutherland sowohl zusam-
men als auch einzeln mehrere Scrum-spezifische Veröffentlichungen herausgebracht,
darunter »Agile Software Development with Scrum« (Schwaber und Beedle 2001), »Agile

35
Kapitel 1
Einführung

Project Management with Scrum« (Schwaber 2004) und »The Scrum Guide« (Schwaber
und Sutherland 2011).
Obwohl Scrum vorwiegend für die Entwicklung von Software-Produkten eingesetzt wird,
lassen sich seine Grundwerte und Prinzipien auch für die Entwicklung anderer Produkte
oder zum Organisieren der Arbeitsabläufe (Workflow) unterschiedlicher Betätigungsfelder
nutzen. So habe ich beispielsweise mit Organisationen zusammengearbeitet, in denen
Scrum ebenso erfolgreich für die Abwicklung und Verwaltung von Hardware-Entwicklun-
gen, Marketingprogrammen und Verkaufsinitiativen eingesetzt wurde.

1.3 Wieso Scrum?


Aber aus welchem Grund war denn nun ein agiler Ansatz wie Scrum eine gute Wahl für
Genomica? Zunächst einmal war unübersehbar, dass die frühere Vorgehensweise in Bezug
auf die Entwicklungsarbeit bei Genomica einfach nicht funktionierte. Das war die schlechte
Nachricht. Die gute Nachricht lautete, dass sich in diesem Punkt fast alle Beteiligten einig
waren.
Genomica agierte in einem komplexen Betätigungsfeld, in dem es mehr unbekannte als
bekannte Faktoren gab. Wir stellten Produkte her, die noch niemals zuvor gebaut worden
waren. Unser Fokus lag auf technologisch absolut neuartigen, sich ständig weiterentwi-
ckelnden Informatikplattformen, die von Wissenschaftlern in der Forschung benutzt wer-
den würden, um neue bahnbrechende Moleküle zu entdecken. Dementsprechend
benötigten wir eine Entwicklungsmethode, die es uns erlaubte, neue Ideen und Ansätze
schnellstmöglich auf den Prüfstand zu stellen und herauszufinden, welche Lösungen
machbar waren und welche nicht. Wir hatten ein Partnerunternehmen, dem wir alle paar
Wochen funktionierende Ergebnisse präsentieren mussten, um ein Feedback zu erhalten,
weil unser Produkt in deren Linie von DNA-Sequenzern passen musste. Aber die daraus
resultierende Notwendigkeit für schnelle Machbarkeitsstudien und Feedback passte nicht
zu der bei uns üblichen ausführlichen Vorausplanung.
Darüber hinaus wollten wir es vermeiden, schon im Vorfeld einen riesigen Architekturent-
wurf ausarbeiten zu müssen. Ein früherer Versuch, eine neue Generation von Genomicas
Kernprodukt zu schaffen, hatte dazu geführt, dass die Organisation fast ein ganzes Jahr
ausschließlich mit der Arbeit an der Architektur zugebracht hatte, um eine umfassende,
einheitliche Bioinformatik-Plattform herzustellen. Doch als die erste rein forschungsorien-
tierte Anwendung auf diese Architektur aufgesetzt wurde und wir schließlich Designent-
scheidungen validieren konnten, die wir Monate zuvor getroffen hatten, dauerte es ganze
42 Sekunden, um auf dem Bildschirm von einem Feld zum nächsten zu springen. Und
wenn Sie glauben, dass der typische Benutzer ungeduldig ist, dann stellen Sie sich nur mal
einen promovierten Molekularbiologen vor, der 42 Sekunden warten muss! Es war katastro-
phal. Wir brauchten einen anderen, ausgeglicheneren Designansatz, der einen gewissen
Anteil des Vorabdesigns mit einer gesunden Dosis an neuem, situationsbezogenen »Just-
in-time«-Design kombinierte.
Außerdem sollten unsere Teams vielseitiger werden. Bislang hatte Genomica wie die meis-
ten Organisationen gearbeitet: Die Entwicklungsabteilung übergab die Arbeiten erst dann
an die Testteams, wenn sie vollständig abgeschlossen waren. Jetzt wollten wir hingegen
dazu übergehen, dass sich die Teammitglieder wesentlich häufiger miteinander synchroni-

36
1.4
Ergebnisse bei Genomica

sierten – vorzugsweise täglich. Denn in der Vergangenheit hatte die mangelhafte Kommu-
nikation hinsichtlich gravierender Probleme, die bereits während der Entwicklungsphase
aufgetreten waren, zu einer Verschärfung der zugrunde liegenden Fehler geführt. Die
Leute in den unterschiedlichen Bereichen redeten einfach nicht oft genug miteinander.
Aus diesen und anderen Gründen entschieden wir, dass Scrum sich gut für Genomica eig-
nen würde.

1.4 Ergebnisse bei Genomica


Als wir beschlossen, es mit Scrum zu versuchen, war diese Methode noch relativ unbe-
kannt – das erste Scrum-Buch erschien erst im darauffolgenden Jahr (Schwaber und Beedle
2001). Also sammelten wir so viele verfügbare Informationen wie möglich und bemühten
uns sehr, das Erlernte umzusetzen – was in jedem Fall deutlich besser funktionierte als die
Art und Weise, wie wir vorher vorgegangen waren (siehe Tabelle 1.1).
Der Aufwand für die Entwicklung eines vergleichbaren Volumens an Produktfunktionalität
reduzierte sich mit der Scrum-Entwicklung im Vergleich zu unserem früheren planorien-
tierten Vorgehen nach dem Wasserfall-Modell auf ein Zehntel (berechnet in Mann-Mona-
ten). Mindestens genauso wichtig war, dass die Scrum-Entwicklung siebenmal schneller
voranging als die Wasserfall-Entwicklung – und damit produzierte sie auch etwa siebenmal
mehr wertvolle Funktionen als das Wasserfall-Entwicklungsverfahren. Noch überzeugen-
der war allerdings die Tatsache, dass wir die Software in einem zeitlichen Rahmen an unse-
ren Partner liefern konnten, der die Anforderungen für die Einführung seiner neuen
Hardware-Plattform erfüllte. Und dadurch waren wir nun in der Lage, eine bereits lange
bestehende Partnerschaft zu stärken, was sich wiederum positiv auf den wirtschaftlichen
Wert von Genomica auswirkte.

Maß Wasserfall Scrum


Aufwand 10x 1x
Schnelligkeit 1x 7x
Kundenzufriedenheit Schlecht Ausgezeichnet
Tabelle 1.1: Scrum-Ergebnisse bei Genomica

1.5 Kann Scrum Ihnen helfen?


Die Erfahrungen, die Genomica vor der Einführung der Scrum-Technik gemacht hatten,
nämlich dass Funktionen entwickelt wurden, die niemand wollte und diese zudem in
schlechter Qualität und verspätet ausgeliefert wurden, sind nicht ungewöhnlich. Wie viele
andere Organisationen hat auch Genomica überlebt, weil es nicht schlechter als die Kon-
kurrenz war. Das gleiche Problem konnte ich bereits beobachten, als ich Mitte der 1980er
Jahre begonnen hatte, in der kommerziellen Software-Entwicklung zu arbeiten. Und für
viele hat sich die Situation auch mehr als 30 Jahre später noch nicht verbessert.
Welche Antwort würden Sie bekommen, wenn Sie Ihre Manager und Entwickler heute
zusammenrufen und fragen würden: »Seid ihr mit den Ergebnissen eurer Software-Ent-

37
Kapitel 1
Einführung

wicklungsbemühungen zufrieden?« oder »Glaubt ihr, dass wir unseren Kunden zu einem
spürbaren zeitlichen, wirtschaftlichen und qualitativen Nutzen verhelfen?«
In sehr vielen Fällen haben die Leute, die ich im Rahmen meiner weltweiten Trainings- und
Beratungstätigkeit dazu befragt habe, mit einem klaren »Nein« geantwortet. Vielmehr
tönte es von allen Seiten: »Die Projektausfallrate ist inakzeptabel hoch«, »Die Auslieferung
erfolgt immer verspätet«, »Die Rentabilität liegt unter den Erwartungen«, »Die Software-
Qualität ist mies«, »Die Produktivität ist beschämend«, »Niemand übernimmt die Verant-
wortung für die Ergebnisse«, »Die Arbeitsmoral ist schlecht«, »Wir haben eine hohe Mitar-
beiterfluktuation«. Und dann wird mit einem desillusionierten Lächeln und ironischem
Unterton noch angefügt: »Es müsste doch auch besser gehen.«
Bei aller Verdrossenheit scheinen sich die meisten Leute damit abgefunden zu haben, dass
Unzufriedenheit zur Software-Entwicklung einfach dazugehört. Dabei muss das nicht so
sein.
Organisationen, die Scrum gewissenhaft einsetzen, haben da ganz andere Erfahrungen
gemacht (siehe Abbildung 1.2).

Erfreute Kunden

Verbesserte Rendite

Reduzierte Kosten

Scrum-Vorteile

Schnelle Ergebnisse

Vertrauen, in einer komplexen Welt zu bestehen

Mehr Freude

Abb. 1.2: Die Vorteile von Scrum

Diese Organisationen begeistern ihre Kunden in schöner Regelmäßigkeit, indem sie ihnen
wirklich das liefern, was sie sich wünschen, und nicht bloß die Funktionen, die am ersten
Tag festgelegt wurden, als noch niemand den wahren Bedarf kannte. Außerdem erwirt-
schaften sie eine bessere Rendite, weil sie häufiger kleinere Releases herausbringen. Und
durch das schonungslose Aufdecken mangelhafter organisatorischer Abläufe und Ver-
schwendungen sind diese Organisationen zudem in der Lage, die Kosten zu senken.

38
1.5
Kann Scrum Ihnen helfen?

Da sich Scrum darauf konzentriert, funktionierende, integrierte, getestete und geschäfts-


fördernde Funktionen zu liefern, führt jede Iteration zu Ergebnissen, die zügig ausgeliefert
werden können. Darüber hinaus erleichtert es dieses Entwicklungsverfahren den Organisa-
tionen, in einer komplexen Welt, in der man sich schnellstmöglich anpassen muss, weil
inzwischen alles miteinander vernetzt ist – Konkurrenten, Kunden, Anwender, Aufsichts-
behörden und andere Akteure – erfolgreich zu sein. Und schließlich bereitet Scrum wirk-
lich allen Beteiligten mehr Spaß an der Sache – nicht nur den Kunden, sondern auch den
Leuten, die die eigentliche Arbeit verrichten –, denn sie arbeiten öfter und enger zusam-
men, was zu verbesserten zwischenmenschlichen Beziehungen und größerem gegenseiti-
gen Vertrauen unter den Teammitgliedern führt.

Komplex Kompliziert
Prüfen, Erspüren, Reagieren Erspüren, Analysieren, Reagieren
• Problem durch Erkundung kennenlernen, • Situation einschätzen, mehrere Optionen
dann untersuchen und anpassen untersuchen, Reaktion basiert auf guter Praxis
• Erfordert kreative/innovative Ansätze • Experten gewähren Einblick
• Gesicherte Umgebung zum Experimentieren • Metriken helfen, Kontrolle zu gewinnen
und Erkennen von Mustern schaffen • Domäne der guten Praktiken
• Maß an Interaktion/Kommunikation erhöhen • Mehrere richtige Antworten
• Domäne der Emergenz • Ursache und Wirkung lassen sich entdecken, sind
• Hinterher weiß man alles besser aber nicht unmittelbar offensichtlich
• Eher unvorhersehbar als vorhersehbar • Eher vorhersehbar als unvorhersehbar

Disorder
Chaotisch Einfach
Handeln, Erspüren, Reagieren Erspüren, Kategorisieren, Reagieren
• Sofort handeln, dann untersuchen, ob die • Fakten erfassen und kategorisieren,
Situation stabil ist, dann versuchen, Kontext Antwort basiert auf etabliertem Vorgehen
in komplexe Domäne zu migrieren • Domäne der besten Praktiken
• Viele Entscheidungen, wenig Zeit • Stabile Domäne (Änderung unwahrscheinlich)
• Sofortige Aktion, um Ordnung • Klare Ursache-Wirkungs-Beziehungen
wiederherzustellen sind offensichtlich für jeden
• Schauen, was geht, anstatt richtige • Es existiert eine korrekte Antwort
Antworten zu suchen • Faktenbasiertes Management
• Domäne des Ungewöhnlichen
• Niemand weiß etwas
• Keine klare Ursache und Wirkung

Abb. 1.3: Cynefin-Framework

Verstehen Sie mich nicht falsch: Scrum ist zwar in vielen Situationen eine ausgezeichnete
Lösung, aber trotzdem nicht in allen Fällen das geeignete Mittel zum Zweck. Das Cynefin-
Framework (Snowden und Boone 2007) ist ein sinnvolles Hilfsmittel, um die vorliegende

39
Kapitel 1
Einführung

Situation beurteilen und feststellen zu können, ob Handlungsbedarf besteht und welcher


Verfahrensansatz der richtige ist. Dieses Framework definiert und vergleicht die Eigen-
schaften fünf unterschiedlicher Domänen: Simple (einfach), Complicated (kompliziert),
Chaotic (chaotisch), Complex (komplex) und Disorder (Nicht-Wissen, Regellosigkeit),
wobei Letztere dann zutrifft, wenn sich Ihre Situation keiner der anderen Domänen ein-
deutig zuordnen lässt (siehe Abbildung 1.3). Im Folgenden werde ich anhand des Cynefin-
Frameworks Situationen aufzeigen, in denen Scrum eine sinnvolle Lösungsmöglichkeit
darstellt und in denen das nicht der Fall ist.
Zunächst einmal muss an dieser Stelle jedoch festgehalten werden, dass sich die vielen
Facetten der Software-Entwicklung und des Software-Supports nicht fein säuberlich in nur
eine Cynefin-Domäne pressen lassen. Vielmehr handelt es sich um ein weit gefasstes Betä-
tigungsfeld, das einige sich überschneidende Aspekte, aber auch individuelle Aktivitäten
umfasst, die in unterschiedliche Domänen fallen (Pelrine 2011). Die Software-Entwick-
lungsarbeit lässt sich also zwar meist den Domänen Complicated oder Complex zuordnen,
es wäre aber naiv zu behaupten, dass die Software-Entwicklung eine komplexe Domäne
wäre. Das gilt vor allem, wenn wir definieren, dass sie ein Arbeitsspektrum aufweist, das
von der Entwicklung innovativer neuer Produkte über die Wartung und Weiterentwicklung
vorhandener Software-Produkte bis zum Betrieb und Support von Software reicht.

1.5.1 Die Complex-Domäne


Beim Umgang mit komplexen Problemen hat man es mit mehr unvorhersehbaren als vor-
hersehbaren Faktoren zu tun. Wenn es eine richtige Lösung gibt, erkennt man diese oft erst
im Nachhinein. Es ist die Domäne der Emergenz, des »In-Erscheinung-Tretens«. Wir müs-
sen Sachverhalte erkunden, um das Problem zu ergründen, dann müssen wir sie
überprüfen und anhand unserer Erkenntnisse eine Anpassung vornehmen (»Inspect and
Adapt«). Das Arbeiten in komplexen Domänen erfordert ein kreatives und innovatives Vor-
gehen. Vorgestanzte Routinelösungen lassen sich einfach nicht anwenden. Wir müssen
eine gesicherte Umgebung für Experimente schaffen, damit wir wichtige Informationen
entdecken können. In dieser Umgebung ist ein hohes Maß an Interaktion und Kommuni-
kation unerlässlich. Die Entwicklung innovativer neuer Produkte fällt ebenso in diese Kate-
gorie wie das Verbessern vorhandener Produkte mit innovativen neuen Funktionen und
Eigenschaften.
Scrum ist für das Arbeiten in einer komplexen Domäne besonders gut geeignet. In solchen
Situationen ist unsere Fähigkeit zum Erkunden, Untersuchen und Reagieren entschei-
dend.

1.5.2 Die Complicated-Domäne


Komplizierte Probleme sind die Domäne der bewährten Praktiken und werden von Exper-
ten dominiert. Es mag mehrere richtige Lösungen geben, allerdings ist eine Expertendiag-
nose nötig, um diese zu ermitteln. Scrum kann sicher auch mit solchen Problemen
zurechtkommen, jedoch ist es möglicherweise nicht das ideale Mittel zum Zweck. So wäre
ein Versuch der Leistungsoptimierung durch Anpassung diverser Parameter, um die beste
Gesamtsystemleistung zu finden, erfolgversprechender, wenn man Experten versammelte,
die die Situation einschätzen, mehrere Optionen untersuchen und ihre Lösungsvorschläge

40
1.5
Kann Scrum Ihnen helfen?

auf einer bewährten Praxis aufbauen. Ein Großteil der alltäglichen Software-Wartung (das
Durchführen von Produkt-Support oder das Beheben von Defekten) fällt in diese Kategorie.
Hier sind viele der taktischen, quantitativen Ansätze wie Six Sigma besonders gut geeignet,
wenngleich diese auch bei einfachen Domänen eingesetzt werden können.

1.5.3 Die Simple-Domäne


Bei einfachen Problemen sind Ursache und Wirkung klar erkennbar. Oft ist die richtige
Lösung offensichtlich und unbestritten. Dies ist die Domäne der anerkannt besten Prakti-
ken. Es gibt also bekannte Lösungen. Sobald wir die Fakten unserer Situation erfasst haben,
können wir die passende vordefinierte Lösung ermitteln. Scrum kann auch für einfache
Probleme eingesetzt werden, ist aber für diese Art von Problemstellung möglicherweise
nicht das effizienteste Werkzeug. Besser wäre es, einen Prozess mit einer Menge wohldefi-
nierter wiederholbarer Schritte anzuwenden, von denen man weiß, dass sie das Problem
beheben. Wollten wir z.B. immer wieder das gleiche Produkt herstellen, wäre ein wohldefi-
nierter Fließbandprozess besser geeignet als Scrum. Auch das Ausliefern des gleichen
Commercial-off-the-shelf-Produkts (COTS; quasi ein seriengefertigtes Produkt aus dem
Elektronik- bzw. Software-Bereich) an die hundertste Kundenumgebung lässt sich vermut-
lich besser erledigen, indem man eine wohldefinierte und bewährte Anzahl von Schritten
für die Installation und Konfiguration des Produkts durchführt.

1.5.4 Die Chaotic-Domäne


Chaotische Probleme erfordern eine schnelle Reaktion. Wir haben eine Krise und müssen
sofort handeln, um weiteren Schaden zu vermeiden und wenigstens eine gewisse Ordnung
wiederherzustellen. Nehmen Sie z.B. an, dass eine Universität einen Artikel veröffentlicht
hätte, der besagt, dass unser Produkt einen mangelhaften Algorithmus enthält, der fehler-
hafte Ergebnisse erzeugt. Unsere Kunden haben auf der Grundlage der Ergebnisse unseres
Produkts beträchtliche Investitionen getätigt und verklagen uns nun auf Schadenersatz.
Unser führender Algorithmendesigner wandert gerade auf Borneo durch den Dschungel
und ist in den nächsten zwei Wochen nicht erreichbar. In diesem Fall ist Scrum nicht die
beste Lösung. Uns interessiert hier nicht, welche Priorität ein Backlog hat und wie wir die
nächste Iteration erreichen können – wir müssen stattdessen in der Lage sein, schnell zu
handeln und den Schaden zu begrenzen. Bei chaotischen Problemen muss jemand das
Heft in die Hand nehmen und Entscheidungen treffen.

1.5.5 Disorder (Nicht-Wissen, Regellosigkeit)


Mit der Disorder-Domäne haben Sie es dann zu tun, wenn sich Ihre Situation nicht eindeu-
tig einer der anderen Domänen zuordnen lässt. Das ist insofern gefährlich, weil Sie nicht
wirklich wissen, wie Sie Ihre Situation einschätzen sollen. In solchen Fällen neigen die
Menschen dazu, die Lage entsprechend ihrer persönlichen Vorlieben zu interpretieren und
auch danach zu handeln. In der Software-Entwicklung sind viele Menschen mit phasenba-
sierten, sequenziellen Ansätzen vertraut, die gut in einfachen Domänen funktionieren,
und haben deshalb auch eine Vorliebe dafür. Leider sind diese für viele Vorgänge in der
Software-Entwicklung nicht besonders gut geeignet. Ich werde das in Kapitel 3 näher erläu-
tern. Sie können sich aus der Disorder-Domäne befreien, indem Sie die Situation in ein-

41
Kapitel 1
Einführung

zelne Teile zerlegen und diese jeweils einer der vier anderen Domänen zuordnen. In der
Disorder-Domäne probieren Sie gar nicht erst Scrum anzuwenden, sondern versuchen
vielmehr, diese Domäne zu verlassen.

1.5.6 Unterbrechungsgesteuerte Arbeit


Für stark unterbrechungsgesteuerte Arbeitsabläufe ist Scrum nicht besonders gut geeignet.
Nehmen Sie einmal an, Sie betreiben eine Organisation für Kunden-Support und wollen
Scrum einsetzen, um Ihre Support-Aktivitäten zu organisieren und zu verwalten. Ihr Pro-
duct Backlog wird kontinuierlich befüllt, wenn Sie telefonisch oder per E-Mail Support-
Anfragen bekommen. Zu keinem Zeitpunkt haben Sie ein Product Backlog, das sehr weit
in die Zukunft reicht. Inhalt und Reihenfolge Ihres Backlogs könnten sich häufig ändern
(stündlich oder minütlich).
In dieser Situation werden Sie nicht in der Lage sein, zuverlässig Iterationen von einer
Woche oder mehr zu planen, weil Sie nicht im Voraus wissen, welche Arbeiten in absehba-
rer Zukunft anfallen werden. Und selbst wenn Sie glauben, die auf Sie zukommenden Auf-
gaben zu kennen, besteht eine relativ hohe Wahrscheinlichkeit, dass eine dringende
Support-Anfrage (also eine Aufgabe mit hoher Priorität) eintrifft, die allen weitreichenden
Plänen zuvorkommt.
In unterbrechungsgesteuerten Umgebungen sollten Sie sich eher einen alternativen agilen
Ansatz namens Kanban zunutze machen. Kanban ist keine eigenständige Prozesslösung,
sondern eher eine Methode, die auf einen vorhandenen Prozess aufgesetzt wird. Im Spe-
ziellen verlangt Kanban, dass Sie
쐽 den Workflow visualisieren (wie etwa die Schritte, die eine Support-Organisation unter-
nimmt, um eine Support-Anfrage zu beantworten),
쐽 die laufenden Arbeiten (Work in Process; WIP) in jedem Schritt begrenzen, damit Sie
sicher sein können, dass Sie nicht mehr Arbeiten erledigen müssen, als Sie aufgrund
Ihrer Kapazität bewältigen können,
쐽 den Workflow durch das System messen und optimieren, um stetig Verbesserungen zu
erreichen.
Die optimalen Einsatzgebiete für Kanban sind die Bereiche Software-Wartung und -Sup-
port. Manche Anwender halten Kanban aufgrund seiner Fokussierung auf die Eliminie-
rung einer Überlast (indem die laufende Arbeit an die Kapazität angepasst wird) und die
Verringerung der Variabilität im Workflow bei gleichzeitiger Unterstützung eines evolutio-
nären Vorgehens außerdem auch für den Einsatz in komplexen Domänen geeignet.
Sowohl Scrum als auch Kanban sind agile Ansätze für die Entwicklung. Beide haben Stär-
ken und Schwächen, die man beachten muss, sobald man sich der Domäne bewusst gewor-
den ist, in der man agiert. In manchen Organisationen können beide Vorgehensweisen
eingesetzt werden, um die unterschiedlichen Systemanforderungen zu meistern, die
nebeneinander existieren. So könnte man z.B. Scrum für die Entwicklung neuer Produkte
verwenden und Kanban für den unterbrechungsgesteuerten Support und die Wartung.

42
1.6
Abschließende Bemerkungen

1.6 Abschließende Bemerkungen


Scrum ist keine Wunderwaffe und auch kein Allheilmittel. Es kann Sie jedoch in die Lage
versetzen, die Änderungen anzunehmen, die mit allen komplexen Produktentwicklungen
einhergehen. Für Genomica und viele andere Unternehmen, die sich entschieden haben,
einen Ansatz für die Software-Entwicklung zu übernehmen, der besser für ihre speziellen
Anforderungen und Gegebenheiten geeignet ist, hat es jedenfalls funktioniert.
Das Scrum-Framework ist zwar einfach, dennoch wäre es ein Fehler anzunehmen, dass es
leicht und schmerzlos einzusetzen sei. Scrum gibt Ihnen keine Antworten auf Ihre Pro-
zessfragen vor, sondern bringt Ihr Team dazu, selbst die entscheidenden Fragen zu stellen
und auch zu beantworten. Scrum liefert keine fertigen Rezepte für alle organisatorischen
Krankheiten, sondern deckt Fehlfunktionen und Verschwendungen auf, die Organisatio-
nen daran hindern, ihr wahres Potenzial auszuschöpfen.
Diese Erkenntnisse sind für viele Organisationen erst einmal schmerzhaft. Sofern sie
jedoch das anfängliche Unbehagen überwinden und sich bemühen, die Probleme zu behe-
ben, die Scrum zutage gefördert hat, können diese Organisationen sowohl bei ihrer Ent-
wicklungsarbeit als auch bei der Angestellten- und Kundenzufriedenheit Großes erreichen.
Der Rest dieses Buches widmet sich der Diskussion der wesentlichen Aspekte von Scrum.
Ich beginne mit einer Beschreibung des gesamten Scrum-Frameworks, einschließlich sei-
ner Rollen, Aktivitäten, Artefakte und Regeln. Wer weiß, wenn Sie Scrum richtig und unter
den passenden Bedingungen einsetzen, werden Sie möglicherweise schon bald ebenso
erfolgreich hochwertige Ergebnisse liefern wie meine Frau an diesem schicksalhaften Tag
im Jahr 2000.

43
Teil I
Kernkonzepte

In diesem Teil:
쐽 Kapitel 2
Das Scrum-Framework . . . . . . . . . . . . . . . . . . . . . . 47

쐽 Kapitel 3
Agile Prinzipien . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

쐽 Kapitel 4
Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

쐽 Kapitel 5
Anforderungen und User Stories . . . . . . . . . . . . . . 115

쐽 Kapitel 6
Das Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . 137

쐽 Kapitel 7
Schätzung und Velocity . . . . . . . . . . . . . . . . . . . . . . 157

쐽 Kapitel 8
Technische Schulden . . . . . . . . . . . . . . . . . . . . . . . . 177

45
Kapitel 2

Das Scrum-Framework

In diesem Kapitel präsentiere ich Ihnen einen Überblick über das Scrum-Framework.
Dabei konzentriere ich mich besonders auf seine Praktiken, einschließlich seiner Rollen,
Aktivitäten und Artefakte. In den nachfolgenden Kapiteln werde ich dann noch ausführli-
cher auf diese einzelnen Praktiken eingehen und einen genaueren Blick auf die Prinzipien
werfen, die diesen Praktiken zugrunde liegen.

2.1 Überblick
Scrum ist kein standardisierter Prozess, bei dem Sie sich methodisch an eine Schrittabfolge
halten, die garantiert, pünktlich und preiswert ein hochwertiges Produkt ergibt, das Ihre
Kunden in Entzückung versetzt. Stattdessen bietet Scrum einen Rahmen zum Organisie-
ren und Verwalten von Arbeit. Das Scrum-Framework basiert auf einer Reihe von Werten,
Prinzipien und Praktiken, die die Grundlage bieten, auf der Ihre Organisation ihre eigene
Umsetzung relevanter technischer Praktiken sowie Ihre speziellen Ansätze zum Umsetzen
der Scrum-Praktiken aufsetzt. Das Ergebnis ist eine Version von Scrum, die einzigartig für
Ihre Organisation ist.
Um das Konzept des Scrum-Frameworks besser zu verstehen, stellen Sie sich vor, dass es
das Fundament und die Wände eines Gebäudes bildet. Die Werte, Prinzipien und Praktiken
von Scrum würden den wichtigen strukturellen Komponenten entsprechen. Sie können
einen Wert, ein Prinzip oder eine Praxis nicht ignorieren oder grundlegend ändern, ohne
zu riskieren, dass das Ganze zusammenbricht. Was Sie jedoch können, ist, die innere
Struktur von Scrum anzupassen sowie Inventar und Elemente hinzuzufügen, bis Sie einen
Prozess haben, der zu Ihnen passt.
Scrum ist ein angenehm einfaches, auf die Menschen ausgerichtetes Framework, das auf
den Werten Ehrlichkeit, Offenheit, Mut, Respekt, Fokus, Vertrauen, Stärkung und Zusam-
menarbeit beruht. In Kapitel 3 werden die Scrum-Prinzipien genauer beschrieben und in
den darauffolgenden Kapiteln wird aufgezeigt, inwiefern bestimmte Praktiken und
Ansätze aus diesen Prinzipien und Werten erwachsen. Die Scrum-Praktiken selbst sind in
bestimmten Rollen, Aktivitäten, Artefakten und den ihnen zugewiesenen Regeln verkör-
pert (siehe Abbildung 2.1).
Der Rest dieses Kapitels konzentriert sich auf die Scrum-Praktiken.

47
Kapitel 2
Das Scrum-Framework

Product Owner

Rollen ScrumMaster

Entwicklungsteam

Sprint

Sprint-Planung

Daily Scrum

Aktivitäten Sprint-Ausführung

Scrum-Praktiken Sprint Review

Sprint-Retrospektive

Product-Backlog-Pflege

Product Backlog

Artefakte Sprint Backlog

Potenziell auslieferungsfähiges Produktinkrement

Regeln Im Buch beschrieben

Abb. 2.1: Scrum-Praktiken

2.2 Scrum-Rollen
Scrum-Entwicklungsmaßnahmen bestehen aus einem oder mehreren Scrum-Teams, die
jeweils aus drei Scrum-Rollen gebildet werden: Product Owner, ScrumMaster und
Entwicklungsteam (siehe Abbildung 2.2). Es kann bei der Anwendung von Scrum noch
weitere Rollen geben, das Scrum-Framework benötigt jedoch nur die drei hier aufgeführten
Rollen.
Der Product Owner ist verantwortlich dafür, was entwickelt wird und in welcher Reihen-
folge dies geschieht. Der ScrumMaster ist dafür verantwortlich, das Team beim Erschaffen
und Befolgen seines eigenen Prozesses – basierend auf dem allgemeineren Scrum-Frame-
work – anzuleiten. Und das Entwicklungsteam ist dafür verantwortlich, festzulegen, wie es
das liefern kann, was der Product Owner haben möchte.

48
2.2
Scrum-Rollen

Scrum-Team
Product Owner ScrumMaster

Entwicklungsteam

Abb. 2.2: Scrum-Rollen

Machen Sie sich als Manager keine Sorgen, dass »Manager« nicht als Rolle in Abbildung
2.2 auftaucht. Manager spielen in Organisationen, die Scrum nutzen, natürlich weiterhin
eine wichtige Rolle (siehe Kapitel 13). Das Scrum-Framework definiert nur die Scrum-spezi-
fischen Rollen, nicht alle Rollen, die in einer Organisation, die Scrum einsetzt, existieren
können und sollten.

2.2.1 Product Owner


Der Product Owner ist die bevollmächtigte Zentralstelle der Produktführung. Er ist die
Autorität, die entscheidet, welche Eigenschaften und Funktionalitäten geschaffen werden
sollen und in welcher Reihenfolge dies zu geschehen hat. Der Product Owner bewahrt eine
klare Vision dessen, was das Scrum-Team erreichen möchte und vermittelt diese Vision
den anderen Teilnehmern. Daher ist der Product Owner für den Gesamterfolg der Lösung
verantwortlich, die entwickelt oder gepflegt werden soll.
Es spielt keine Rolle, ob der Fokus auf einem externen Produkt oder einer internen Anwen-
dung liegt. Der Product Owner ist in jedem Fall verpflichtet, dafür zu sorgen, dass immer
die bestmögliche Arbeit ausgeführt wird. Das kann auch technisch orientierte Tätigkeiten
beinhalten. Um sicherzustellen, dass das Team schnell das baut, was der Product Owner
haben möchte, arbeitet dieser aktiv mit dem ScrumMaster und dem Entwicklungsteam
zusammen und muss immer zur Verfügung stehen, um Fragen so schnell wie möglich
nach ihrem Aufkommen zu beantworten. In Kapitel 9 finden Sie eine ausführliche
Beschreibung der Rolle des Product Owners.

2.2.2 ScrumMaster
Der ScrumMaster hilft allen Beteiligten, die Scrum-Werte, -Prinzipien und -Praktiken zu
verstehen und zu übernehmen. Er agiert als Trainer, bietet Führerschaft für den Prozess
und hilft dem Scrum-Team und dem Rest der Organisation, ihren eigenen leistungsstarken
und organisationsspezifischen Scrum-Ansatz zu entwickeln. Gleichzeitig unterstützt der

49
Kapitel 2
Das Scrum-Framework

ScrumMaster die Organisation bei den Änderungen im Managementprozess, die während


des Umstiegs auf Scrum auftreten können.
Als Moderator hilft der ScrumMaster dem Team, Probleme zu lösen und Verbesserungen
bei der Benutzung von Scrum umzusetzen. Er ist auch dafür verantwortlich, das Team vor
Eingriffen von außen zu schützen, und übernimmt eine führende Rolle bei der Beseitigung
von Hindernissen, die die Produktivität des Teams stören (wenn die einzelnen Personen
dies nicht vernünftig lösen können). Der ScrumMaster besitzt nicht die Autorität, Kontrolle
über das Team auszuüben, diese Rolle ist daher nicht mit der traditionellen Rolle des Pro-
jektmanagers oder Entwicklungsmanagers vergleichbar. Der ScrumMaster fungiert als Lei-
ter, nicht als Manager. Ich diskutiere die Rollen des fachlichen Managers und des
Projektmanagers in Kapitel 13. In Kapitel 10 erfahren Sie mehr über die Rolle des Scrum-
Masters.

2.2.3 Das Entwicklungsteam


Traditionelle Ansätze zur Software-Entwicklung diskutieren verschiedene Jobarten, wie
etwa Architekt, Programmierer, Tester, Datenbankadministrator, Oberflächendesigner usw.
Scrum definiert die Rolle eines Entwicklungsteams, das einfach eine vielfältige, funktions-
übergreifende Sammlung dieser Arten von Menschen darstellt, die dafür verantwortlich
sind, das gewünschte Produkt zu entwerfen, zu bauen und zu testen.
Das Entwicklungsteam organisiert sich selbst, um den besten Weg zu ermitteln, auf dem
sich das Ziel erreichen lässt, das der Product Owner gesteckt hat. Typischerweise besteht
das Entwicklungsteam aus fünf bis neun Leuten. Seine Mitglieder müssen alle über die
Fähigkeiten verfügen, die nötig sind, um hochwertige, funktionierende Software herzustel-
len. Natürlich kann Scrum auch bei Entwicklungsarbeiten eingesetzt werden, die viel grö-
ßere Teams erfordern. Anstatt jedoch ein Scrum-Team mit, sagen wir, 35 Menschen zu
bilden, würde es vermutlich vier oder mehr Scrum-Teams geben, jeweils mit einem Ent-
wicklungsteam aus neun oder weniger Leuten. Lesen Sie Kapitel 11, wenn Sie mehr über
die Rolle des Entwicklungsteams erfahren möchten. In Kapitel 12 wird beschrieben, wie
man mehrere Teams miteinander koordiniert.

2.3 Scrum-Aktivitäten und Artefakte


Abbildung 2.3 stellt die meisten Scrum-Aktivitäten und -Artefakte dar und beschreibt, wie
sie zusammenpassen.
Lassen Sie uns das Diagramm zusammenfassen. Beginnen wir dabei auf der linken Seite
der Abbildung und arbeiten wir uns im Uhrzeigersinn an dem großen geschwungenen
Pfeil (dem Sprint) entlang.
Der Product Owner hat eine Vision dessen, was er schaffen möchte (den großen Würfel).
Da der Würfel groß sein kann, wird er durch eine Aktivität namens Pflege (»Grooming«) in
eine Reihe von Funktionen aufgeteilt, die in einer priorisierten Liste gesammelt werden,
dem sogenannten Product Backlog.
Ein Sprint startet mit der Sprint-Planung, umfasst die Entwicklungsarbeit während des
Sprints (Sprint-Ausführung oder Sprint Execution) und endet mit dem Review und der
Retrospektive. Der Sprint wird durch den großen geschwungenen Pfeil dargestellt, der die

50
2.3
Scrum-Aktivitäten und Artefakte

Mitte der Abbildung dominiert. Die Anzahl der Elemente im Product Backlog übersteigt
wahrscheinlich das Pensum, was das Entwicklungsteam in einem kurzen Sprint bewälti-
gen kann. Aus diesem Grund muss das Entwicklungsteam zu Beginn jedes Sprints eine
Teilmenge der Elemente aus dem Product Backlog festlegen, die es glaubt, schaffen zu kön-
nen – eine Aktivität, die als Sprint-Planung bezeichnet wird und rechts neben dem großen
Product-Backlog-Würfel zu sehen ist.

Daily Scrum
Sprint-Planung
Sprint Backlog
Product Backlog
Sprint-Ausführung

Pflege

Potenziell
auslieferungsfähiges
Produktinkrement

Sprint Review
Sprint-Retrospektive

Abb. 2.3: Das Scrum-Framework

Übrigens rief eine 2011 vorgenommene Änderung in »The Scrum Guide« (Schwaber und
Sutherland 2011) eine Debatte hervor, ob sich das Ergebnis einer Sprint-Planung als
Vorhersage oder doch eher als Verpflichtung beschreiben lässt. Befürworter des Wortes
Vorhersage mögen es, weil sie glauben, dass das Entwicklungsteam zwar die bestmögliche
Schätzung vornimmt, diese Schätzung sich aber ändern kann, wenn im Laufe des Sprints
mehr Informationen bekannt werden. Manche glauben auch, dass eine Verpflichtung aufsei-
ten des Teams das Team dazu bewegen könnte, Qualitätseinbußen hinzunehmen oder sich
einfach zu weniger zu verpflichten, um die Verpflichtung garantiert zu erfüllen.
Ich stimme zu, dass alle Entwicklungsteams eine Vorhersage (Schätzung) darüber abgeben
sollten, was sie bei jedem Sprint liefern können. Viele Entwicklungsteams würden jedoch
davon profitieren, wenn sie die Vorhersage benutzen würden, um eine Verpflichtung abzu-
leiten. Verpflichtungen fördern das gegenseitige Vertrauen zwischen dem Product Owner
und dem Entwicklungsteam sowie innerhalb des Entwicklungsteams. Darüber hinaus
unterstützen Verpflichtungen die vernünftige Kurzzeitplanung und Entscheidungsfindung
innerhalb einer Organisation. Und wenn die Produktentwicklung in mehreren Teams statt-
findet, fördern Verpflichtungen eine synchronisierte Planung – ein Team kann auf der
Grundlage dessen, wozu sich ein anderes Team verpflichtet hat, seine Entscheidungen tref-
fen. Ich bevorzuge in diesem Buch den Begriff Verpflichtung, benutze aber gelegentlich das
Wort Vorhersage, wenn der Kontext es zulässt.
Um die Zuversicht zu gewinnen, dass das Entwicklungsteam eine vernünftige Verpflich-
tung gefasst hat, legen die Teammitglieder während der Sprint-Planung ein zweites Back-

51
Kapitel 2
Das Scrum-Framework

log an, das als Sprint Backlog bezeichnet wird. Das Sprint Backlog beschreibt anhand einer
Reihe detaillierter Aufgaben, wie das Team in diesem speziellen Sprint Entwurf, Aufbau,
Integration und Test der ausgewählten Funktionen aus dem Product Backlog durchführen
will.
Nun kommt die Sprint-Ausführung, während der das Entwicklungsteam die Aufgaben erle-
digt, die nötig sind, um die ausgewählten Funktionen umzusetzen. Während der Sprint-
Ausführung helfen die Teammitglieder täglich bei der Verwaltung des Workflows, indem
sie eine Aktivität durchführen, die als Daily Scrum bezeichnet wird und der Synchronisie-
rung, Inspektion und Vorausplanung dient. Am Ende der Sprint-Ausführung hat das Team
ein potenziell auslieferungsfähiges Produktinkrement hergestellt, das einen Teil, jedoch
nicht die gesamte Vision des Product Owners repräsentiert.
Das Scrum-Team schließt den Sprint mit zwei Aktivitäten zur Untersuchung und Anpas-
sung ab. In der ersten, dem Sprint Review, untersuchen die Stakeholder und das Scrum-
Team das hergestellte Produkt. In der zweiten, der Sprint-Retrospektive, untersucht das
Scrum-Team den Scrum-Prozess, der eingesetzt wurde, um das Produkt zu erschaffen. Das
Ergebnis dieser Aktivitäten könnten Änderungen sein, die ihren Weg in das Product Back-
log finden oder als Teil des Entwicklungsprozesses des Teams betrachtet werden.
Nun wiederholt sich der Scrum-Sprint-Kreislauf. Er beginnt erneut damit, dass das Ent-
wicklungsteam die nächstwichtige Menge der Elemente aus dem Product Backlog
bestimmt, die es abschließen kann. Nachdem eine entsprechende Anzahl von Sprints erle-
digt wurde, ist die Vision des Product Owners verwirklicht und die Lösung kann freigege-
ben werden.
Im Rest dieses Kapitels gehe ich näher auf diese Aktivitäten und Artefakte ein.

2.3.1 Product Backlog


Mit Scrum erledigen wir die nützlichste bzw. wichtigste Arbeit immer zuerst. Der Product
Owner, der vom Rest des Scrum-Teams und den Stakeholdern mit Informationen versorgt
wird, ist am Ende verantwortlich dafür, die Arbeitsreihenfolge festzulegen und zu organi-
sieren. Dies kommuniziert er in Form einer priorisierten (oder geordneten) Liste, die als
Product Backlog bezeichnet wird (siehe Abbildung 2.4). Bei der Entwicklung neuer Pro-
dukte sind die Elemente im Product Backlog zu Anfang die Funktionen und Eigenschaften,
die erforderlich sind, um die Vision des Product Owners zu erfüllen. Bei der Weiterent-
wicklung von Produkten könnte das Product Backlog auch neue Funktionen, Änderungen
an vorhandenen Funktionen, zu reparierende Schäden, technische Verbesserungen usw.
enthalten.
Der Product Owner arbeitet mit den internen und externen Stakeholdern zusammen, um
die Elemente des Product Backlogs zu sammeln und zu definieren. Er sorgt dann dafür,
dass diese Elemente in die richtige Reihenfolge gebracht werden (mithilfe von Faktoren wie
Wert, Kosten, Wissen und Risiko), damit wertvolle Elemente an die Spitze des Product
Backlogs und weniger wertvolle Elemente an das Ende gelangen. Das Product Backlog ist
ein Artefakt, das sich ständig weiterentwickelt. Elemente können vom Product Owner hin-
zugefügt, gelöscht und überarbeitet werden, wenn sich die geschäftlichen Bedingungen
ändern oder das Verständnis des Scrum-Teams für das Produkt wächst (durch Feedback zu
der im Rahmen jedes Sprints erstellten Software).

52
2.3
Scrum-Aktivitäten und Artefakte

Insgesamt ist die Aktivität des Anlegens und Verfeinerns der Elemente des Product Back-
logs, ihr Abschätzen und Priorisieren als Pflege oder Grooming bekannt (siehe Abbil-
dung 2.5).

Funktion A
Funktion B
Hochpriorisierte Elemente
Funktion C
Defekt 23
Restrukt. X

Funktion D
Funktion E

Funktion F
Niedrigpriorisierte Elemente

Abb. 2.4: Product Backlog

Product Backlog
Funktion A
Funktion B
Funktion C

Priorisieren

Anlegen Schätzen
und Verfeinern

Abb. 2.5: Pflege (Grooming) des Product Backlogs

Noch eine zweite kurze Anmerkung: 2011 gab es eine weitere Debatte darüber, ob der kor-
rekte Begriff für das Beschreiben der Abfolge der Elemente im Product Backlog priorisiert
(der Originalbegriff) oder geordnet lauten soll, wie es in »The Scrum Guide« (Schwaber und
Sutherland 2011) heißt. Es wurde argumentiert, dass Priorisieren einfach nur eine Form
des Ordnens sei (und, wie manche behaupteten, nicht einmal die geeignetste). Die Frage,
wie man die Elemente im Product Backlog aufreiht, wird jedoch von vielen Faktoren beein-
flusst. Ein einziges Wort kann vermutlich niemals die volle Breite und Tiefe des Konzepts
erfassen. Theoretisch mag der Streit über die Begriffe »geordnet« und »priorisiert« irgend-

53
Kapitel 2
Das Scrum-Framework

einen Nutzen haben, die meisten Leute (auch ich) verwenden sie bei der Diskussion um die
Elemente im Product Backlog jedoch je nach Kontext.
Bevor wir das Priorisieren, Ordnen oder anderweitige Arrangieren des Product Backlogs
abschließen, müssen wir wissen, wie groß die einzelnen Elemente sein werden (siehe
Abbildung 2.6).

Funktion A | 5
Funktion B | 3 Relative Größenschätzungen
Funktion C | 2 (typischerweise Story-Punkte oder Idealtage)

Funktion D | 5
Funktion E | 8

Abb. 2.6: Größe der Elemente des Product Backlogs

Die Größe entspricht den Kosten. Product Owner müssen die Kosten eines Elements ken-
nen, um dessen Priorität bestimmen zu können. Scrum gibt nicht vor, welches Größenmaß
man gegebenenfalls für Elemente des Product Backlogs benutzen sollte. In der Praxis ver-
wenden viele Teams ein relatives Größenmaß wie Story-Punkte oder Idealtage. Ein relatives
Größenmaß drückt die Gesamtgröße eines Elements auf eine Weise aus, dass nicht der
absolute Wert in Betracht gezogen wird, sondern die relative Größe eines Elements im Ver-
gleich zu anderen Elementen. So hat z.B. Funktion C in Abbildung 2.6 die Größe 2, wäh-
rend Funktion E die Größe 8 besitzt. Wir können daraus schließen, dass Funktion E
ungefähr achtmal größer ist als Funktion C. Ich gehe in Kapitel 7 näher auf diese Maße ein.

2.3.2 Sprints
In Scrum wird die Arbeit in Iterationen oder Zyklen durchgeführt, die bis zu einem Kalen-
dermonat dauern können und Sprints genannt werden (siehe Abbildung 2.7). Die Arbeit,
die in einem Sprint abgeschlossen wird, sollte etwas schaffen, das für den Kunden oder
User einen irgendwie greifbaren Wert aufweist.

Starttermin Endtermin

Feste Länge

Sprint 1 Sprint 2 Sprint 3 Sprint 4

Timebox von bis zu


einem Kalendermonat

Abb. 2.7: Sprint-Merkmale

54
2.3
Scrum-Aktivitäten und Artefakte

Sprints sind in Time-Boxen eingeteilt, sie haben also immer ein festes Anfangs- und End-
datum und sollten im Allgemeinen alle gleich lang sein. Ein neuer Sprint folgt unmittelbar
auf den Abschluss des vorhergehenden Sprints. Normalerweise gilt die Regel, dass wäh-
rend eines Sprints keine Änderungen in Umfang oder Personal zulässig sind, die das Ziel
gefährden. Manchmal machen es jedoch die geschäftlichen Umstände unmöglich, diese
Regel zu befolgen. Ich werde Sprints in Kapitel 4 näher beschreiben.

2.3.3 Sprint-Planung
Ein Product Backlog könnte viele Wochen oder Monate an Arbeit repräsentieren, was natür-
lich mehr ist, als sich in einem einzigen kurzen Sprint bewältigen lässt. Um die wichtigste
Teilmenge der Elemente eines Product Backlogs zu ermitteln, die in den nächsten Sprint
aufgenommen werden sollen, führen der Product Owner, das Entwicklungsteam und der
ScrumMaster ein Planungstreffen durch, die Sprint-Planung (siehe Abbildung 2.8).

Sprint-Planung
Sprint Backlog
Product Backlog
Funktion A
Funktion B Aufgaben = wie es zu tun ist
Funktion C
Was zu tun ist

Pflege

Die Sprint-Planung
ist der erste Teil
jedes Sprints

Abb. 2.8: Sprint-Planung

Während der Sprint-Planung einigen sich der Product Owner und das Entwicklungsteam
auf ein Sprint-Ziel, das definiert, was im kommenden Sprint erreicht werden soll. Anhand
dieses Ziels prüft das Entwicklungsteam das Product Backlog und ermittelt die Elemente
mit hoher Priorität, die das Team realistischerweise im kommenden Sprint erledigen kann,
wenn es in einer nachhaltigen Geschwindigkeit arbeitet, d.h. einer Geschwindigkeit, die
das Team über einen längeren Zeitraum durchhalten kann.
Um Vertrauen in das zu gewinnen, was es schaffen kann, teilen viele Entwicklungsteams
die jeweils angestrebten Funktionen in eine Reihe von Aufgaben auf. Diese Aufgaben-
sammlung bildet dann zusammen mit ihren jeweiligen Product-Backlog-Elementen ein
zweites Backlog, das Sprint Backlog (siehe Abbildung 2.9).
Das Entwicklungsteam gibt außerdem eine Schätzung über den Aufwand ab (typischer-
weise in Stunden), der zum Abschließen der einzelnen Aufgaben nötig sein wird. Das Auf-
teilen der Elemente des Product Backlogs in Aufgaben ist eine Form des Designs und der
Just-in-time-Planung für die Fertigstellung dieser Funktionen.
Die meisten Scrum-Teams, die Sprints von zwei Wochen bis einem Monat durchführen,
versuchen, die Sprint-Planung in vier bis acht Stunden zu schaffen. Die Planung eines

55
Kapitel 2
Das Scrum-Framework

Sprints von einer Woche Dauer sollte nicht mehr als einige Stunden erfordern (eher sogar
weniger). In dieser Zeit kann man mehreren Ansätzen folgen. Ich nutze meist einen einfa-
chen Zyklus: Auswahl eines Elements aus dem Product Backlog (wenn möglich, das
nächstwichtige Element, wie es vom Product Owner definiert wurde), Zerlegen des Ele-
ments in Aufgaben und Feststellen, ob das ausgewählte Element bequem in den Sprint
passt (zusammen mit anderen Elementen, die ebenfalls für diesen Sprint vorgesehen sind).
Falls das Element passt und noch Kapazitäten für weitere Arbeiten frei sind, wird der Zyk-
lus wiederholt, bis die Kapazitäten des Teams erschöpft sind.

Jede Funktion … … wird in Aufgaben zerlegt

UI programmieren Tests automatisieren DB-Schema anlegen Jede Aufgabe bekommt eine


Stunden = 5 Stunden = 8 Stunden = 6 Schätzung in Aufwandstunden

Fehler-Logging Icons herstellen Puffertest


Stunden = 12 Stunden = 8 Stunden = 2

Grafik-Bibl. install. Tests automatisieren


Stunden = 8 Stunden = 6

Abb. 2.9: Sprint Backlog

Alternativ könnten der Product Owner und das Team alle Zielelemente des Product Back-
logs auf einmal auswählen. Das Entwicklungsteam nimmt dann allein die Aufteilung in
Aufgaben vor, um zu bestätigen, dass es tatsächlich alle ausgewählten Elemente ausliefern
kann. Die einzelnen Vorgehensweisen werden in Kapitel 19 genauer betrachtet.

2.3.4 Sprint-Ausführung
Sobald das Scrum-Team die Sprint-Planung abgeschlossen und sich auf den Inhalt des
nächsten Sprints geeinigt hat, führt das Entwicklungsteam unter Anleitung des ScrumMas-
ters alle aufgabenbezogenen Arbeiten durch, die erforderlich sind, um die Funktionen fer-
tigzustellen (siehe Abbildung 2.10). Done (Fertig) bedeutet, dass im Team eine große
Zuversicht darüber herrscht, dass alle Arbeiten zur Bereitstellung hochwertiger Funktionen
abgeschlossen sind.
Welche Aufgaben das Team nun genau durchführt, hängt natürlich von der Art der Arbeit
ab (produzieren wir z.B. Software, stellen wir Hardware her oder geht es um Marketingar-
beit?).
Niemand sagt dem Entwicklungsteam, in welcher Reihenfolge oder wie es die aufgabenbe-
zogenen Arbeiten im Sprint Backlog erledigen soll. Stattdessen definieren die Teammitglie-

56
2.3
Scrum-Aktivitäten und Artefakte

der ihre Arbeit und organisieren sich dann selbst so, wie es ihnen am besten erscheint, um
das Sprint-Ziel zu erreichen. In Kapitel 20 erfahren Sie mehr über die Sprint-Ausführung.

2.3.5 Daily Scrum


Während eines Sprints halten die Mitglieder des Entwicklungsteams täglich ein zeitlich
begrenztes (höchstens 15 Minuten) Treffen ab, das Daily Scrum (siehe Abbildung 2.11).
Diese Aktivität zum Überprüfen und Anpassen wird manchmal auch als tägliches Standup
bezeichnet, weil es sich eingebürgert hat, dass alle Teilnehmer während dieser Zusammen-
kunft stehen, damit das Treffen nicht zu lange dauert.

Die Sprint-Ausführung nimmt in jedem Sprint die meiste Zeit in Anspruch

Sprint Backlog
Sprint-Ausführung

Jede Funktion hat einige


Aufgaben, die das Team
ausführt, um die Funktion
abzuschließen

Abb. 2.10: Sprint-Ausführung

Alle 24 Stunden

Daily Scrum

Sprint-Ausführung

Abb. 2.11: Daily Scrum

57
Kapitel 2
Das Scrum-Framework

Ein verbreitetes Vorgehen beim Daily Scrum sieht so aus, dass der ScrumMaster moderiert
und die einzelnen Teammitglieder nacheinander drei Fragen für die anderen Teammitglie-
der beantworten:
쐽 Was habe ich seit dem letzten Daily Scrum erreicht?
쐽 Woran möchte ich bis zum nächsten Daily Scrum arbeiten?
쐽 Welche Hürden oder Hindernisse haben dafür gesorgt, dass ich keine Fortschritte ge-
macht habe?
Durch die Beantwortung dieser Fragen bekommt jeder mit, was im Großen und Ganzen
passiert, wie der Stand der Dinge in Bezug auf das Sprint-Ziel ist, ob und wie die Pläne für
die Arbeit des nächsten Tages geändert wurden und welche Probleme angesprochen wer-
den müssen. Das Daily Scrum ist ein ganz wesentlicher Faktor, damit das Entwicklungs-
team den schnellen, flexiblen Workflow in einem Sprint bewältigen kann.
Es dient allerdings nicht der Lösung von Problemen. Stattdessen bevorzugen es viele
Teams, vorliegende Problemstellungen erst nach dem Daily Scrum zu besprechen, und
zwar nicht in der ganzen Gruppe, sondern lediglich im kleineren Kreis Interessierter. Auch
ist das Daily Scrum kein traditionelles Statustreffen, wie es früher von Projektmanagern
einberufen wurde, um sich über den Status des Projekts zu informieren. Ein Daily Scrum
kann jedoch sinnvoll sein, um die Mitglieder des Entwicklungsteams über den Status der
Elemente des Sprint Backlogs zu informieren. Es ist in der Hauptsache eine Aktivität zur
Überprüfung, Synchronisierung und Anpassung der täglichen Planung, die dem selbstor-
ganisierten Team hilft, besser zu werden.
Auch wenn sie heute nicht mehr zum Scrum-Sprachgebrauch gehören, wurden früher die
Begriffe »Pigs« (Schweine) und »Chicken« (Hühner) benutzt, um zwischen denjenigen zu
unterscheiden, die an den Daily Scrums aktiv teilnehmen, und jenen, die einfach nur beob-
achten sollten. Damit bezog man sich auf einen alten Haustier-Witz: »Bei einem Frühstück
aus Schinken und Eiern sind die Hühner interessiert, die Schweine jedoch beteiligt«. Diese
Bezeichnungen sollten also lediglich zur Unterscheidung von am Erreichen des Sprint-
Ziels Interessierten (Chicken) auf der einen Seite und und unmittelbar daran Beteiligten
(Pigs) auf der anderen Seite dienen. In Bezug auf das Daily Scrum sollten also nur die Pigs
reden, während die Chicken höchstens als Beobachter anwesend sein sollten.
Ich habe festgestellt, dass es am besten ist, wenn man die Mitglieder des Scrum-Teams als
Pigs betrachtet, und alle, die nicht zum Team gehören, als Chicken. Das sehen aber nicht
alle so. So ist es z.B. für den Product Owner nicht erforderlich, am Daily Scrum teilzuneh-
men, so dass manche ihn als Chicken ansehen. (Die Logik dahinter lautet: Wie kann man
»beteiligt« sein, wenn man nicht teilnehmen muss?) Das scheint mir falsch zu sein, weil
ich mir nicht vorstellen kann, wie der Product Owner als Mitglied des Scrum-Teams weni-
ger am Ergebnis beteiligt sein kann als das Entwicklungsteam. Die Metapher der Pigs und
Chicken hält nicht stand, wenn Sie versuchen, sie innerhalb eines Scrum-Teams anzuwen-
den.

2.3.6 Fertig (Done)


In Scrum bezeichnen wir die Sprint-Ergebnisse als potenziell auslieferungsfähiges Pro-
duktinkrement (siehe Abbildung 2.12). Das bedeutet, dass das, was das Scrum-Team erledi-
gen wollte, nach einer zuvor festgelegten Definition als fertiggestellt gilt. Diese Definition

58
2.3
Scrum-Aktivitäten und Artefakte

legt den Grad der Überzeugung des Teams fest, dass die abgeschlossene Arbeit von guter
Qualität und potenziell für die Auslieferung bereit ist. Beim Entwickeln von Software z.B.
sollte eine minimale Definition von »Fertig« ein komplettes Stück Produktfunktionalität
umfassen, das entworfen, entwickelt, integriert, getestet und dokumentiert wurde.

Sprint-Ausführung

Potenziell
auslieferungsfähiges
Produktinkrement

Sprint Review

Abb. 2.12: Sprint-Ergebnisse (potenziell auslieferungsfähiges Produktinkrement)

Eine aggressive Definition von Fertig erlaubt es der Organisation, bei jedem Sprint zu ent-
scheiden, ob das, was hergestellt wurde, an interne oder externe Kunden ausgeliefert (oder
ausgebracht oder freigegeben) werden kann.
Noch einmal: »Potenziell auslieferungsfähig« bedeutet nicht, dass auch tatsächlich etwas
ausgeliefert werden muss. Die Auslieferung ist eine geschäftliche Entscheidung, die oft von
Dingen beeinflusst wird wie »Haben wir genügend Funktionen oder genügend Kunden-
Workflow, um eine Übergabe an den Kunden zu rechtfertigen?« oder »Können unsere Kun-
den eine weitere Änderung verkraften, zumal wir ihnen erst vor zwei Wochen eine Version
übergeben haben?«
Stellen Sie sich unter der Formulierung »potenziell auslieferungsfähig« lieber als einen
Zuversichtsstatus vor: Das, was in dem Sprint hergestellt wurde, ist tatsächlich fertig. Mit
anderen Worten: Es sind keine grundlegend wichtigen Arbeiten unerledigt geblieben (wie
etwa wichtige Tests oder die Integration), die abgeschlossen werden müssten, bevor wir die
Ergebnisse des Sprints ausliefern können, falls wir das wollten.
Aus praktischen Erwägungen ändern Teams manchmal im Laufe der Zeit die Definition
von Fertig. So ist es möglicherweise in den frühen Stadien der Spieleentwicklung wirt-
schaftlich nicht praktikabel oder wünschenswert, Funktionen zu implementieren, die
potenziell auslieferungsfähig sind (wenn man die erforschende Natur der frühen Spieleent-

59
Kapitel 2
Das Scrum-Framework

wicklung bedenkt). In diesen Situationen könnte eine angemessene Definition von Fertig
sein, dass man ein Stück der Produktfunktionalität hat, das ausreichend funktioniert und
so einsetzbar ist, dass das Team Feedback erhalten kann, um zu entscheiden, welche Arbei-
ten als Nächstes durchgeführt werden könnten. In Kapitel 4 erfahren Sie mehr über die
Definition von Fertig.

2.3.7 Sprint Review


Am Ende des Sprints stehen zwei weitere Aktivitäten zum Überprüfen und Anpassen
(»Inspect and Adapt«) an. Eine davon ist der Sprint Review (siehe Abbildung 2.13).

Der Sprint Review ist die vorletzte


Aktivität in einem Sprint

Potenziell
auslieferungsfähiges
Produktinkrement

Sprint Review
Sprint-Retrospektive

Abb. 2.13: Sprint Review

Das Ziel dieser Aktivität besteht darin, das Produkt, das gebaut wird, zu überprüfen und
anzupassen. Wichtig ist hierbei der Austausch, der zwischen den Teilnehmern stattfindet.
Dazu gehören das Scrum-Team, die Stakeholder, die Sponsoren, die Kunden sowie interes-
sierte Mitglieder anderer Teams. Die Gespräche konzentrieren sich auf das erneute
Überprüfen der gerade fertiggestellten Funktionen im Kontext der gesamten Entwicklungs-
arbeit. Alle Anwesenden erhalten einen klaren Überblick über das, was passiert, und haben
die Möglichkeit, die weitere Entwicklung zu beeinflussen, um dafür zu sorgen, dass die
beste Lösung gefunden werden kann.
Ein erfolgreicher Review ergibt einen Informationsfluss, der in zwei Richtungen verläuft.
Die Leute, die nicht im Scrum-Team sind, werden über die Entwicklungsarbeit auf den
neuesten Stand gebracht und helfen dabei, deren Richtung zu bestimmen. Gleichzeitig
erlangen die Mitglieder des Scrum-Teams durch die häufigen Feedbacks hinsichtlich der
»Annäherung« des Produkts an Kunden oder Benutzer ein tieferes Verständnis für die
Geschäfts- und Marketingseite ihres Produkts. Der Sprint Review stellt daher eine planmä-
ßige Gelegenheit dar, das Produkt zu überprüfen und anzupassen. Leute, die nicht im
Scrum-Team sind, können Kritik an den Funktionen in dem Sprint üben und ihre Meinung
äußern, um dem Scrum-Team zu helfen, sein Sprint-Ziel besser zu erreichen. Mehr zum
Sprint Review erfahren Sie in Kapitel 21.

60
2.4
Abschließende Bemerkungen

2.3.8 Sprint-Retrospektive
Die zweite Aktivität am Ende des Sprints zum Überprüfen und Anpassen ist die Sprint-
Retrospektive (siehe Abbildung 2.14). Sie erfolgt häufig erst nach dem Sprint Review und
vor der nächsten Sprint-Planung.

Die Sprint-Retrospektive ist die letzte


Aktivität in einem Sprint

Sprint Review
Sprint-Retrospektive
Abb. 2.14: Sprint-Retrospektive

Während der Sprint Review Gelegenheit zum Überprüfen und Anpassen des Produkts bie-
tet, ist die Sprint-Retrospektive eine Gelegenheit, um den Prozess zu untersuchen und zu
adaptieren. Das Entwicklungsteam, der ScrumMaster und der Product Owner setzen sich
zusammen und diskutieren, was mit Scrum und den damit verbundenen technischen
Praktiken funktioniert hat und was nicht. Der Fokus liegt dabei auf der stetigen Verbesse-
rung des Prozesses, die notwendig ist, damit aus einem guten ein wirklich großartiges
Scrum-Team wird. Am Ende einer Sprint-Retrospektive sollte das Scrum-Team eine kon-
krete Anzahl von Aktionen zur Prozessverbesserung identifiziert haben, die vom Scrum-
Team im nächsten Sprint durchgeführt werden. Mehr dazu erfahren Sie in Kapitel 22.
Nachdem die Sprint-Retrospektive abgeschlossen ist, fängt der gesamte Zyklus wieder von
vorn an – beginnend mit der nächsten Sitzung zur Sprint-Planung, in der die aktuell als am
wertvollsten eingeschätzten Arbeiten ermittelt werden, auf die sich das Team jetzt konzen-
trieren wird.

2.4 Abschließende Bemerkungen


In diesem Kapitel wurden die wesentlichen Scrum-Praktiken erläutert. Dabei ging es vor
allem um die Beschreibung der Rollen, Aktivitäten und Artefakte des Scrum-Frameworks.
Darüber hinaus gibt es aber auch noch andere Praktiken, wie etwa allgemeinere Planungen
und Prozessüberwachungen, die sich viele Scrum-Teams zunutze machen. Auf diese wird
in späteren Kapiteln eingegangen. Im nächsten Kapitel liefere ich zunächst eine Beschrei-
bung der Kernprinzipien, auf denen Scrum beruht. Dieses Grundlagenwissen erleichtert
die daran anschließende ausführlichere Erkundung des Scrum-Frameworks in den nach-
folgenden Kapiteln.

61
Kapitel 3

Agile Prinzipien

Bevor wir tiefer in die Mechanismen von Scrum eintauchen, sollten wir uns zunächst ein-
mal mit den zugrundeliegenden Prinzipien vertraut machen, die diese Mechanismen
antreiben und auszeichnen.
Auf den nachfolgenden Seiten werden daher die agilen Prinzipien erläutert, auf denen
Scrum basiert, und einem Vergleich mit den Grundlagen der traditionellen, plangesteuer-
ten, sequenziellen Produktentwicklung unterzogen. Dieses Kapitel zeigt auf, wie sich
Scrum von den traditionelleren Formen der Produktentwicklung unterscheidet und bietet
Ihnen somit eine solide Wissensbasis für die in den nachfolgenden Kapiteln beschriebene
ausführlichere Analyse der Scrum-Praktiken.

3.1 Überblick
Ich halte es für sehr aufschlussreich, die Scrum zugrundeliegenden Prinzipien anhand
eines Vergleichs mit den Grundsätzen der traditionellen, plangesteuerten, sequenziellen
Entwicklung vorzustellen – denn dadurch sollte Ihnen das Verständnis dessen, inwiefern
Scrum der Ihnen bereits bekannten Vorgehensweise ähnelt bzw. sich davon unterscheidet,
leichter fallen.
Diese Gegenüberstellung der agilen und der traditionellen Entwicklungsprinzipien soll
jedoch nicht etwa demonstrieren, dass die plangesteuerte, sequenzielle Entwicklung
schlecht und Scrum gut ist. Im Gegenteil: Beides sind wertvolle Werkzeuge im Repertoire
eines jeden professionellen Entwicklers. Es gibt keine schlechten Werkzeuge, sondern nur
unpassende Gelegenheiten, diese Werkzeuge einzusetzen. Und wie ich im Zusammen-
hang mit dem Cynefin-Framework in Kapitel 2 schon kurz erklärt habe, sind sowohl Scrum
als auch die traditionelle, plangesteuerte, sequenzielle Entwicklung jeweils für unterschied-
liche Klassen von Problemen hervorragend geeignet.
Zum Vergleichen dieser beiden Ansätze greife ich auf die reine, quasi lehrbuchmäßige
Beschreibung der plangesteuerten, sequenziellen Entwicklung zurück. Aus dieser Perspek-
tive betrachtet, lassen sich die Prinzipien, die der Scrum-basierten Entwicklung zugrunde
liegen sowie deren Unterschiede zu der traditionellen Entwicklung einfach besser und
deutlicher darstellen. Eine reine Form der traditionellen, plangesteuerten Entwicklung wird
häufig als Wasserfall-Modell bezeichnet (siehe Abbildung 3.1). Diese Entwicklungsvariante
stellt jedoch nur eins von vielen Beispielen einer breiteren Klasse von plangesteuerten Pro-
zessen dar (die auch als traditionelle, sequenzielle, vorausschauende, prädiktive oder vor-
schreibende Entwicklungsprozesse bekannt sind).
Plangesteuerte Prozesse verdanken ihre Bezeichnung der Tatsache, dass hier versucht
wird, alle Funktionen, die sich der Benutzer für das Endprodukt möglicherweise wünschen

63
Kapitel 3
Agile Prinzipien

könnte, vorauszuplanen und festzustellen, wie man diese Funktionen am besten realisiert.
Die Idee dahinter ist, dass eine bessere Planung das Verständnis und damit auch die
Durchführung der Entwicklung des betreffenden Produkts begünstigt. Derartige Prozesse
werden oft auch als sequenzielle Prozesse bezeichnet, weil die Anwender nacheinander
eine komplette Anforderungsanalyse durchführen, dann einen kompletten Designentwurf
erstellen, dem wiederum die Programmierung und schließlich die Tests folgen.

• Auslieferung/Meilenstein
• Review/Genehmigung
Analyse

Design

Programmierung

Tests

Betrieb

Abb. 3.1: Wasserfall-Modell

Die plangesteuerte Entwicklung funktioniert prima, wenn Sie sie auf wohldefinierte und
vorhersehbare Probleme anwenden, die sich mit hoher Wahrscheinlichkeit nicht mehr gra-
vierend ändern. Leider sind die meisten in der Produktentwicklung anfallenden Arbeiten
jedoch alles andere als vorhersehbar, speziell am Anfang. Während Ihnen ein plangesteuer-
ter Prozess also den Eindruck eines geregelten, erklärbaren und messbaren Vorgehens ver-
mittelt, kann dieser Eindruck durchaus zu einem falschen Gefühl der Sicherheit führen –
denn letzten Endes verläuft das Entwickeln eines Produkts nur selten wie geplant.
Grundsätzlich erscheint ein plangesteuerter, sequenzieller Prozess sinnvoll – Verstehen,
Entwerfen, Programmieren, Testen, Ausliefern, und das alles nach einem schön definier-
ten, vorher festgelegten Plan. Viele sind daher der Auffassung, dass das in jedem Fall funk-
tionieren müsste. Und wenn ein plangesteuertes Vorgehen dann doch nicht funktioniert,
wird häufig davon ausgegangen, dass irgendetwas schiefgelaufen sein muss: Selbst wenn
ein Prozess wiederholt enttäuschende Ergebnisse liefert, halten viele Organisationen den-
noch daran fest, weil sie sicher sind, dass die Ergebnisse sich schon irgendwann verbessern
werden. Das Problem liegt jedoch nicht in der Ausführung, sondern darin, dass plangesteu-
erte Ansätze auf Überzeugungen beruhen, die nicht mit der Unsicherheit konform gehen,
die den meisten Produktentwicklungsarbeiten innewohnen.
Scrum basiert dagegen auf anderen Überzeugungen – die sich gut auf Probleme abbilden
lassen, die so unsicher sind, dass sich nicht viel vorhersagen lässt. Die Prinzipien, die ich in

64
3.1
Überblick

diesem Kapitel beschreiben werde, entstammen einer ganzen Reihe von Quellen, darunter
dem »Agilen Manifest« (Beck et al. 2001), der »Schlanken Produktentwicklung« (Reinertsten
2009b; Poppendieck und Poppendieck 2003) sowie »The Scrum Guide« (Schwaber und
Sutherland 2011).
Diese Prinzipien sind in mehrere Kategorien aufgeteilt, die in Abbildung 3.2 dargestellt
sind.

Hilfreiche Veränderlichkeit bereitwillig annehmen

Iterative und inkrementelle Entwicklung nutzen


Veränderlichkeit
und Unsicherheit
Ausnutzung der Veränderlichkeit durch Inspektion, Anpassung und Transparenz

Gleichzeitiges Reduzieren aller Formen der Unsicherheit

Optionen offen halten

Akzeptieren, dass man es nicht gleich von Anfang an richtig machen kann

Vorhersage und
Einen adaptiven, untersuchenden Ansatz bevorzugen
Anpassung

Änderungen auf wirtschaftlich vernünftige Weise annehmen

Vorhersagende, im Voraus erfolgende Arbeit mit adaptiver, bedarfsgerechter Arbeit abwägen

Schnelles Validieren wichtiger Annahmen

Validiertes Wissen Abwägen mehrerer gleichzeitiger Lernschleifen

Prinzipien
Organisieren des Arbeitsablaufs für schnelle Rückmeldungen

Wirtschaftlich vernünftige Batch-Größen benutzen

Lagerbestände erkennen und sinnvoll verwalten


Work in Process
(WIP)
Auf unerledigte Arbeit konzentrieren, nicht auf untätige Arbeiter

Verzögerungskosten betrachten

An Echtzeitinformationen anpassen und umplanen

Fortschritt Fortschritt messen, indem man funktionierende Güter validiert

Auf eine wertzentrierte Auslieferung konzentrieren

Gehe schnell, aber hetze nicht

Leistung Baue Qualität ein

Mache alles ohne großes Zeremoniell

Abb. 3.2: Kategorisierung der Prinzipien

65
Kapitel 3
Agile Prinzipien

Ich beginne an dieser Stelle mit den Prinzipien, die sich die Veränderlichkeit und Unsi-
cherheit zunutze machen, die der Produktentwicklung zu eigen sind. Anschließend folgt
eine Diskussion der Prinzipien, bei denen es um die Balance zwischen einer im Vorfeld
getroffenen Vorhersage und einer situationsbezogenen Anpassung geht. Danach erläutere
ich dann die Prinzipien, die sich auf das Lernen konzentrieren, gefolgt von den Prinzipien
für die Organisation laufender Arbeitsprozesse. Und zum Schluss gehe ich schließlich
auch auf die Prinzipien ein, die sich auf Fortschritt und Leistung beziehen.

3.2 Veränderlichkeit und Unsicherheit


Scrum nutzt die Veränderlichkeit und die Unsicherheit in der Produktentwicklung aus, um
innovative Lösungen zu schaffen. Ich beschreibe in diesem Zusammenhang vier Prinzi-
pien:
쐽 Hilfreiche Veränderlichkeit bereitwillig annehmen.
쐽 Iterative und inkrementelle Entwicklung nutzen.
쐽 Ausnutzen der Veränderlichkeit durch Inspektion, Anpassung und Transparenz.
쐽 Gleichzeitiges Reduzieren aller Formen der Unsicherheit.

3.2.1 Hilfreiche Veränderlichkeit bereitwillig annehmen


Plangesteuerte Prozesse behandeln die Produktentwicklung wie die Produktfertigung: Sie
meiden Veränderlichkeit und ermutigen die Konformität zu einem definierten Prozess.
Das Problem dabei ist allerdings, dass die Entwicklung eines Produkts etwas ganz anderes
ist als dessen Herstellung. Bei der Fertigung ist es unser Ziel, eine feste Menge von Anfor-
derungen zu beachten und einer Abfolge von wohldurchdachten und -verstandenen Schrit-
ten zu folgen, um ein fertiges Produkt herzustellen, das immer gleich ist – im Rahmen
gewisser definierter Toleranzen (siehe Abbildung 3.3).

Ein definierter Prozess


Die gleiche Das gleiche
Eingabe Ergebnis

Abb. 3.3: Definierter Prozess

Bei der Entwicklung besteht das Ziel hingegen darin, eine einzige, einmalige Instanz des
Produkts herzustellen, und nicht, das Produkt an sich zu fertigen. Diese eine Instanz kann
man analog zu einer einzigartigen Rezeptur sehen: Es liegt uns fern, ein und dieselbe
Rezeptur ein weiteres Mal zusammenzustellen – denn das wäre reine Geldverschwendung.
Vielmehr wollen wir eine einzigartige Rezeptur für ein neues Produkt entwerfen. Und um
jedes Mal ein anderes Produkt zu erhalten, ist natürlich eine gewisse Veränderlichkeit
erforderlich. Um genau zu sein, unterscheidet sich jede Funktion, die wir in das Produkt
einbauen, von jeder anderen Funktion innerhalb dieses Produkts, so dass wir die Veränder-
lichkeit auf dieser Ebene sogar brauchen. Und erst wenn wir die Rezeptur haben, fertigen
wir das Produkt an – im Fall von Software-Produkten bedeutet das einfach, dass wir die Bits
kopieren.

66
3.2
Veränderlichkeit und Unsicherheit

Andererseits lassen sich einige Konzepte der Fertigung auch auf die Produktentwicklung
anwenden und sollten dementsprechend ausgenutzt werden. Wie ich z.B. in Kürze noch
ausführen werde, ist das Erfassen und Organisieren der Bestände (bzw. der laufenden
Arbeiten) – ein wichtiger Faktor für die Fertigung – auch in der Produktentwicklung uner-
lässlich. Rein vom Wesen der anfallenden Arbeiten her sind die Produktentwicklung und
die Produktherstellung jedoch ganz und gar nicht gleich und erfordern deshalb ganz unter-
schiedliche Prozesse.

3.2.2 Iterative und inkrementelle Entwicklung nutzen


Die plangesteuerte, sequenzielle Entwicklung setzt voraus, dass wir gleich zu Anfang schon
die richtigen Dinge tun und die meisten oder alle Teile des Produkts erst relativ spät in dem
Entwicklungsprozess hinzukommen.
Scrum dagegen basiert auf einer iterativen und inkrementellen Entwicklung. Diese beiden
Begriffe werden zwar häufig so benutzt, als würde es sich um ein einziges Konzept han-
deln, tatsächlich unterscheidet sich die iterative Entwicklung aber durchaus von der inkre-
mentellen Entwicklung.
Die iterative Entwicklung erkennt an, dass wir die Dinge vermutlich erst einmal falsch
angehen, bevor wir sie richtig hinbekommen, und dass wir sie schlecht erledigen, bevor wir
sie gut machen (Goldberg und Rubin 1995). Daher folgt sie einer Strategie der geplanten
Überarbeitung. Wir brauchen mehrere Durchläufe, um das, was wir bauen, zu verbessern
und uns auf diese Weise zu einer guten Lösung vorzuarbeiten. So könnten wir z.B. mit der
Errichtung eines Prototypen beginnen, um wichtiges Wissen über einen wenig bekannten
Bestandteil des Produkts zu sammeln. Dann könnten wir eine überarbeitete Version erstel-
len, die ein bisschen besser ist, auf die dann wiederum eine ziemlich gute Version folgt.
Nachdem ich dieses Buch geschrieben hatte, habe ich z.B. mit jedem neuen Feedback und
einem wachsenden Gespür dafür, wie ich ein Thema auf bessere Art und Weise kommuni-
zieren kann, sämtliche Kapitel mehrere Male überarbeitet.
Die iterative Entwicklung eignet sich ausgezeichnet, um das Produkt bereits während der
Entwicklungsphase zu verbessern. Der größte Nachteil dieser Methode ist hingegen die
Tatsache, dass es angesichts der Unsicherheit schwierig sein kann, bereits im Voraus
festzulegen (zu planen), wie viele Durchläufe für weitere Verbesserungen notwendig sein
werden.
Demgegenüber beruht die inkrementelle Entwicklung auf dem uralten Prinzip »Wer Gro-
ßes will, muss klein anfangen«. Wir vermeiden es, am Ende der Entwicklung ein ultimati-
ves »Knaller-Ereignis« zu haben, bei dem alle Teile zusammengebaut werden und das
gesamte Produkt ausgeliefert wird. Stattdessen teilen wir das Produkt in kleinere Einzel-
teile auf, so dass wir einige Teile bauen und dann herausfinden, wie sie in der Umgebung
»überleben« können, in der sie bestehen müssen. Anhand unserer Erkenntnisse modifizie-
ren wir sie und bauen dann mehr von ihnen. Als ich dieses Buch schrieb, schickte ich
immer ein Kapitel nach dem anderen zur Korrektur, anstatt zu warten, bis das gesamte
Buch fertig war und dann alles auf einmal in die Korrektur zu geben. Dadurch bekam ich
die Möglichkeit, die Kritiken und Korrekturen beim Schreiben künftiger Kapitel zu berück-
sichtigen und meinen Ton, Stil oder Inhalt entsprechend anzupassen. Außerdem konnte
ich so schrittweise dazulernen und das, was ich aus früheren Kapiteln gelernt hatte, in spä-
teren Kapiteln anwenden.

67
Kapitel 3
Agile Prinzipien

Die inkrementelle Entwicklung liefert uns wichtige Informationen, die es uns erlauben,
unsere Entwicklungsarbeit im weiteren Fortgang der Arbeit anzupassen und zu ändern.
Andererseits besteht ihr größter Nachteil darin, dass wir möglicherweise das Komplettbild
aus den Augen verlieren, während wir die kleineren Einzelteile bauen. (»Wir sehen den
Wald vor lauter Bäumen nicht mehr.«)
Scrum nutzt die Vorteile sowohl der iterativen als auch der inkrementellen Entwicklung
aus und negiert dabei die Nachteile, die sich ergäben, würde man diese Verfahren einzeln
benutzen. Dies wird dadurch erreicht, dass beide Ansätze in einer adaptiven Reihe zeit-
lich begrenzter Iterationen eingesetzt werden, die man als Sprints bezeichnet (siehe
Abbildung 3.4).

Sprint 1 Sprint 2 Sprint 3


Analysieren Design Analysieren Design Analysieren Design
Anpassen Anpassen
Testen Testen Testen

Integrieren Bauen Integrieren Bauen Integrieren Bauen


Feedback Feedback

Inkrement 1 Inkrement 2 Inkrement 3

Abb. 3.4: Scrum nutzt eine iterative und inkrementelle Entwicklung

Während jedes Sprints führen wir alle Aktivitäten durch, die notwendig sind, um ein funk-
tionierendes Produktinkrement herzustellen (also einen Teil des Produkts, nicht das
gesamte Produkt). Dies ist in Abbildung 3.4 dargestellt: In jedem Sprint wird ein Teil der
Analyse-, Design-, Aufbau-, Integrations- und Testarbeit abgeschlossen. Dieser Ansatz des
»alles-auf-einmal« hat den Vorteil, dass die Annahmen, die beim Entwickeln der Funktio-
nen des Produkts getroffen wurden, schnell validiert werden können. So treffen wir z.B.
einige Designentscheidungen, stellen ein wenig Code her, der auf diesen Entscheidungen
beruht, und testen dann das Design und den Code – alles im selben Sprint. Indem wir die
gesamte zusammenhängende Arbeit in einem Sprint erledigen, können wir Funktionen
schnell überarbeiten und ziehen so einen Vorteil aus der iterativen Entwicklung, ohne dass
wir extra weitere Iterationen einplanen müssen.
Ein Missbrauch des Sprint-Konzepts wäre es, wenn man jeden Sprint nur auf eine Art von
Arbeit konzentriert – z.B. Sprint 1 (Analyse), Sprint 2 (Design), Sprint 3 (Kodierung) und
Sprint 4 (Test). Ein solches Vorgehen versucht, Scrum eine wasserfallartige Teilstruktur
überzustülpen. Ich bezeichne diesen fehlgeleiteten Versuch als WaterScrum, habe aber
auch schon den Begriff Scrummerfall gehört.
In Scrum arbeiten wir nicht eine Phase nach der anderen ab, sondern eine Funktion nach
der anderen. Am Ende eines Sprints haben wir also ein wertvolles Produktinkrement her-
gestellt (sprich einige, aber nicht alle Funktionen des Produkts). Dieses Inkrement enthält
zuvor entwickelte Funktionen oder ist in diese integriert und wurde mit ihnen getestet. Ist
dies nicht geschehen, kann das betreffende Produktinkrement nicht als Fertig (Done)
betrachtet werden. So enthält z.B. Inkrement 2 in Abbildung 3.4 die Funktionen von Inkre-

68
3.2
Veränderlichkeit und Unsicherheit

ment 1. Am Ende des Sprints können wir ein Feedback zu den neu fertiggestellten Funk-
tionen im Kontext der bereits abgeschlossenen Funktionen erhalten. Das hilft uns dabei,
das Produkt aus einer umfassenderen Perspektive zu betrachten, als es ansonsten möglich
wäre.
Wir erhalten also Feedbacks zu den Sprint-Ergebnissen, was es uns erlaubt, uns anzupas-
sen. So können wir für die Arbeit im nächsten Sprint eine andere Gruppe von Funktionen
wählen oder den bislang eingesetzten Prozessablauf ändern, um die nächsten Funktionen
zu erstellen. Manchmal stellt sich auch heraus, dass das Inkrement nicht so gut ist, wie es
sein könnte, obwohl es technisch gesehen alle Anforderungen erfüllt. In diesem Fall kön-
nen wir für einen künftigen Sprint eine Überarbeitung einplanen – schließlich haben wir
uns einer iterativen Entwicklung und kontinuierlichen Verbesserung der Funktionen ver-
schrieben. Auf diese Weise lösen wir das Problem, dass wir nicht im Voraus wussten, wie
viele Verbesserungsläufe wir benötigen würden. Scrum verlangt nicht von uns, vorher eine
bestimmte Anzahl von Iterationen festzulegen, vielmehr führen uns die kontinuierlichen
Feedbacks zu einer angemessenen und ökonomisch sinnvollen Anzahl von Iterationen,
während wir das Produkt inkrementell entwickeln.

3.2.3 Ausnutzen der Veränderlichkeit durch Inspektion,


Anpassung und Transparenz
Plangesteuerte Prozesse und Scrum unterscheiden sich in mehreren Dimensionen ganz
grundlegend (siehe Tabelle 3.1, basierend auf den von Reinertsen 2009a vorgeschlagenen
Dimensionen).
Eine plangesteuerte, sequenzielle Entwicklung geht von einer geringen oder gar nicht vor-
handenen Veränderlichkeit des Ergebnisses aus. Sie folgt einer wohldefinierten Menge von
Schritten und nutzt erst spät im Prozess einige wenige Feedbacks. Im Gegensatz dazu
nimmt Scrum bereitwillig die Tatsache an, dass bei der Produktentwicklung ein gewisses
Maß an Veränderlichkeit erforderlich ist, um etwas Neues bauen zu können. Im Rahmen
dieses Entwicklungsverfahrens wird außerdem davon ausgegangen, dass der Prozess zur
Erschaffung des Produkts komplex ist und sich deshalb einer vollständigen, im Voraus
erfolgenden Definition entzieht. Darüber hinaus generiert Scrum frühe und häufige Feed-
backs, so dass sichergestellt ist, dass das richtige Produkt gebaut wird – und dass das Pro-
dukt richtig gebaut wird.
Im Herzen von Scrum befinden sich die Prinzipien Überprüfung, Anpassung und
Transparenz (die von Schwaber und Beedle 2001 zusammenfassend als empirische Pro-
zesskontrolle bezeichnet werden). In Scrum inspizieren und adaptieren wir nicht nur, was
wir bauen, sondern auch, wie wir es bauen (siehe Abbildung 3.5).
Um das gut zu machen, verlassen wir uns auf die Transparenz: Alle Informationen, die für
das Herstellen eines Produkts wichtig sind, müssen allen Personen zur Verfügung stehen,
die an der Fertigung des Produkts beteiligt sind. Transparenz ermöglicht erst eine Inspek-
tion, die für die Anpassung oder Adaption erforderlich ist. Transparenz erlaubt es außer-
dem allen Beteiligten, zu beobachten und zu verstehen, was passiert. Sie führt zu mehr
Kommunikation und schafft Vertrauen (sowohl in den Prozess als auch unter den Team-
mitgliedern).

69
Kapitel 3
Agile Prinzipien

Dimension Plangesteuert Scrum


Grad der Wohldefinierte Menge Komplexer Prozess, der sich einer voll-
Prozessdefinition sequenzieller Schritte ständigen Definition im Vorfeld ent-
zieht
Zufälligkeit des Kaum oder keine Varia- Erwarten Sie Variabilität, da wir nicht
Ergebnisses bilität des Ergebnisses versuchen, immer wieder dasselbe zu
bauen
Menge der verwendeten Wenig und spät Häufig und früh
Feedbacks
Tabelle 3.1: Vergleich von plangesteuerten und Scrum-Prozessen

Prozess-
Anpassung überprüfung Feedback

Anpassung

Erste Fertiges
Eingabe Scrum Ergebnis
Eingabe Ergebnis

Anpassung
Anpassung Feedback
Produkt-
überprüfung

Abb. 3.5: Scrum-Prozessmodell

3.2.4 Gleichzeitiges Reduzieren aller Formen der Unsicherheit


Das Entwickeln neuer Produkte ist ein komplexes Unterfangen, das mit einem hohen Grad
an Unsicherheit einhergeht. Diese Unsicherheit lässt sich in zwei große Kategorien unter-
teilen (Laufer 1996):
쐽 End-Unsicherheit (Was-Unsicherheit) – Unsicherheit, die die Funktionen des fertigen
Produkts umgibt
쐽 Methoden-Unsicherheit (Wie-Unsicherheit) – Unsicherheit, die den Prozess und die
Technologien umgibt, mit denen ein Produkt entwickelt wird
In bestimmten Umgebungen oder bei bestimmten Produkten könnte es auch eine
Kunden-Unsicherheit (Wer-Unsicherheit) geben. So können z.B. Start-up-Organisationen
(sowie große Unternehmen, die neue Produkte herausbringen wollen) nur spekulieren,
wer am Ende die tatsächlichen Kunden für ihre Produkte sein werden. Diese Unsicherheit
muss angesprochen werden, da sie ansonsten Gefahr laufen, geniale Produkte für den völ-
lig falschen Markt zu produzieren.
Traditionelle, sequenzielle Entwicklungsprozesse konzentrieren sich zuerst auf das Elimi-
nieren aller End-Unsicherheiten, indem bereits im Voraus vollständig definiert wird, was
gebaut werden soll. Erst danach wendet man sich der Methoden-Unsicherheit zu.

70
3.3
Vorhersage und Anpassung

Dieser vereinfachende, lineare Ansatz zum Abbau der Unsicherheit eignet sich nur bedingt
für die komplexe Domäne der Produktentwicklung, bei der sich unsere Aktionen und die
Umgebung, in der wir arbeiten, gegenseitig hemmen. Zum Beispiel:
쐽 Wir beschließen, eine Funktion zu bauen (unsere Aktion).
쐽 Wir zeigen diese Funktion anschließend einem Kunden, der daraufhin seine Meinung
hinsichtlich dessen, was er eigentlich haben möchte, ändert oder merkt, dass er die Ein-
zelheiten der Funktion nicht richtig vermittelt hat (unsere Aktion löst eine Reaktion sei-
tens der Umgebung aus).
쐽 Wir nehmen aufgrund der Feedbacks Designänderungen vor (die Reaktion seitens der
Umgebung veranlasst uns, eine weitere unvorhergesehene Aktion vorzunehmen).
In Scrum behindern wir uns nicht selbst, indem wir uns erst einmal ausgiebig um eine ein-
zige Unsicherheitskategorie kümmern, bevor es dann an die nächste geht. Stattdessen
verfolgen wir einen eher holistischen Ansatz und konzentrieren uns darauf, alle Unsicher-
heiten gleichzeitig zu verringern (Ende, Methoden, Kunden usw.). Natürlich können wir
uns dennoch jederzeit stärker auf eine Kategorie konzentrieren als auf eine andere. Das
gleichzeitige Behandeln mehrerer Unsicherheitskategorien wird durch die iterative und
inkrementelle Entwicklung unterstützt und durch die ständige Inspektion, Anpassung und
Transparenz angeleitet. Solch ein Vorgehen erlaubt es uns, unsere Umgebung ganz nach
unseren Wünschen und Vorstellungen zu testen und zu erkunden sowie mehr über die
unbekannten Unbekannten (Dinge, von denen wir noch gar nicht wissen, dass wir sie nicht
kennen) zu lernen, die dabei in Erscheinung treten.

3.3 Vorhersage und Anpassung


Beim Einsatz von Scrum wägen wir ständig den Wunsch nach Vorhersage gegen die Not-
wendigkeit der Anpassung ab. Im Folgenden beschreibe ich fünf agile Prinzipien, die mit
diesem Thema verwandt sind:
쐽 Optionen offen halten.
쐽 Akzeptieren, dass man es nicht gleich von Anfang an richtig machen kann.
쐽 Einen adaptiven, untersuchenden Ansatz bevorzugen.
쐽 Änderungen auf eine ökonomisch sinnvolle Weise annehmen.
쐽 Vorhersagende, im Voraus erfolgende Arbeit gegen adaptive, bedarfsgerechte Arbeit ab-
wägen.

3.3.1 Optionen offen halten


Die plangesteuerte, sequenzielle Entwicklung verlangt, dass wichtige Entscheidungen in
Bereichen wie Anforderungen oder Design innerhalb ihrer jeweiligen Phasen getroffen,
überprüft und bewilligt werden. Darüber hinaus müssen diese Entscheidungen fallen,
bevor wir zur nächsten Phase wechseln können, selbst wenn sie nur auf begrenztem Wis-
sen beruhen.
Bei Scrum dagegen geht es darum, dass wir nie eine verfrühte Entscheidung treffen, nur
weil ein generischer Prozess uns vorschreibt, dass jetzt die richtige Zeit dafür sei. Stattdes-
sen verfolgen wir mit Scrum eine Strategie, bei der unsere Optionen offen bleiben. Dieses

71
Kapitel 3
Agile Prinzipien

Prinzip wird oft als Last Responsible Moment (LRM; letzter verantwortbarer Augenblick)
bezeichnet (Poppendieck und Poppendieck 2003). Das bedeutet, dass wir die Festlegung
oder Verpflichtung verzögern und wichtige sowie irreversible Entscheidungen erst im letz-
ten Augenblick treffen, den wir verantworten können. Und wann ist das? Wenn die Kosten,
die Entscheidung nicht zu treffen, höher werden als die Kosten für die Entscheidung (siehe
Abbildung 3.6). In diesem Augenblick entscheiden wir uns.

ögerung
Verz
Letzter (wirtschaftlich)
verantwortbarer Augenblick
Kosten

der
n
ste
Ko

K o st
en für
Entscheidung

Zeit

Abb. 3.6: Entscheidungen im letzten verantwortbaren Augenblick treffen

Um sich dieses Prinzips bewusst zu werden, denken Sie einmal über Folgendes nach: Am
ersten Tag einer Produktentwicklung verfügen wir über die wenigsten Informationen hin-
sichtlich dessen, was wir tun. An jedem nachfolgenden Entwicklungstag lernen wir ein
bisschen mehr. Warum sollten wir uns also jemals dazu entschließen, die wichtigsten und
möglicherweise nicht wieder rückgängig zu machenden Entscheidungen schon am ersten
Tag oder zumindest sehr frühzeitig zu treffen? Die meisten von uns würden es vorziehen
zu warten, bis wir mehr Informationen haben, damit wir eine qualifiziertere Entscheidung
treffen können. Wenn wir uns bei wichtigen und unwiderruflichen Entscheidungen zu
früh festlegen und uns irren, landen wir schnell auf dem exponentiell ansteigenden Teil der
Kostenkurve aus Abbildung 3.6. Gewinnen wir hingegen ein besseres Verständnis hinsicht-
lich der Entscheidung, sinken die Kosten (und die Wahrscheinlichkeit, eine schlechte Ent-
scheidung zu treffen, sinkt dabei ebenfalls, weil unsere Sicherheit in Bezug auf den Markt
oder die Technik zunimmt). Deshalb sollten wir warten, bis wir bessere Informationen
haben, bevor wir uns zu einer Entscheidung durchringen.

3.3.2 Akzeptieren, dass man es nicht gleich von Anfang


an richtig machen kann
Plangesteuerte Prozesse setzen nicht nur die vollständigen Anforderungen und einen kom-
pletten Plan voraus, sondern auch, dass wir alles von Anfang an richtig machen. In der Rea-
lität ist das ziemlich unwahrscheinlich, sowohl im Hinblick auf die Anforderungen als
auch auf die Pläne. Was aber noch schlimmer ist: Wenn sich die Anforderungen ändern,

72
3.3
Vorhersage und Anpassung

müssen wir die Grundforderungen und Pläne so korrigieren, dass sie der aktuellen Realität
entsprechen (mehr dazu in Kapitel 5).
In Scrum erkennen wir an, dass wir nicht alle Anforderungen oder Pläne gleich von
Anfang an fehlerfrei berücksichtigen können. Wir sind sogar der Meinung, dass es gefähr-
lich sein könnte, dies zu versuchen, da uns mit Sicherheit wichtige Erkenntnisse fehlt, was
wiederum dazu führt, dass wir viele qualitativ schlechte Anforderungen stellen (siehe
Abbildung 3.7).
Die nachstehende Grafik zeigt, dass bei einem plangesteuerten, sequenziellen Prozess
bereits sehr früh eine große Anzahl von Anforderungen gestellt wird – also zu einem Zeit-
punkt, zu dem wir am wenigsten über das Produkt wissen. Solch ein Vorgehen ist riskant,
weil wir uns der Illusion hingeben, dass wir die End-Unsicherheit eliminiert haben. Und
das führt potenziell zu einer Verschwendung von Zeit und Geld, sobald wir weitere
Erkenntnisse gewinnen oder sich Dinge ändern (wie ich in Kürze beschreiben werde).

Gefahrenzone! Da sind
viele Anforderungen
schlechter Qualität,
obwohl wir noch
nicht genug wissen Menge der Anforderungen,
die zu jedem
Zeitpunkt produziert
werden
Gesammeltes
Wissen

Unser gesammeltes
Produktwissen
wächst mit der Zeit

Analyse Design Progr. Tests Betrieb

Phase

Abb. 3.7: Anhäufung plangesteuerter Anforderungen relativ zum Produktwissen

Dennoch stellen wir auch beim Einsatz von Scrum im Voraus Anforderungen und entwi-
ckeln Pläne – allerdings nur so viele wie nötig und unter der Voraussetzung, dass wir die
Details dieser Anforderungen und Pläne später ergänzen, wenn wir mehr über das Produkt
gelernt haben, das wir bauen wollen. Denn selbst wenn wir glauben, dass wir zu 100% wis-
sen, was wir erreichen wollen und wie wir das organisieren können, werden wir feststellen,
dass wir uns irren, sobald wir unsere frühen inkrementellen Lieferungen der Umgebung
aussetzen, in der sie später funktionieren sollen. Zu diesem Zeitpunkt werden alle unbe-
quemen Realitäten dessen, was wirklich gebraucht wird, uns dazu bringen, Änderungen
vorzunehmen.

73
Kapitel 3
Agile Prinzipien

3.3.3 Einen adaptiven, untersuchenden Ansatz bevorzugen


Plangesteuerte, sequenzielle Prozesse konzentrieren sich darauf, das zu benutzen, was
aktuell bekannt ist und versuchen vorherzusagen, was nicht bekannt ist. Scrum bevorzugt
hingegen ein eher adaptives, sich vorwärts tastendes Vorgehen, das auf Erkundung beruht
und sich nicht vor Fehlern scheut.
Die Erkundung bezieht sich darauf, dass wir manchmal versuchen, Wissen zu erlangen,
indem wir eine Aktivität durchführen, wie etwa einen Prototypen bauen, den Beweis für
das Funktionieren eines Konzepts liefern, eine Studie oder ein Experiment durchführen.
Das bedeutet, dass wir uns durch das Erkunden Informationen erkaufen, wenn wir uns
unsicher sind.
Die Kosten der Erkundung werden stark durch unsere Werkzeuge und Technologien beein-
flusst und waren früher bei der Entwicklung von Software-Produkten ausgesprochen hoch,
so dass man einen prädiktiven Ansatz bevorzugte, bei dem man versuchte, gleich von Vorn-
herein alles richtig zu machen (siehe Abbildung 3.8).

Bevorzugt einen adaptiven,


Kosten

untersuchenden Ansatz

Bevorzugt einen
prädiktiven Ansatz, bei
dem man versucht,
alles von Vornherein
richtig zu machen

1950 1970 2010

Abb. 3.8: Frühere Kosten der Erkundung

So habe ich z.B. in meinem ersten Studienjahr an der Georgia Tech (Anfang der 1980er
Jahre) kurzzeitig Lochkarten benutzt – ein Werkzeug, bei dem es, genau wie bei einer
Schreibmaschine, absolut schrecklich war, wenn man Fehler machte oder etwas ändern
musste. Es war schwierig, sich mit dem Konzept des »Lasst uns das schnell mal ausprobie-
ren und schauen, was passiert« anzufreunden, wenn man für jede potenzielle Lösung
gewissenhaft Lochkarten stanzen, sich in die Schlange am Großrechner einreihen und bis
zu 24 Stunden warten musste, bis die Lösung verarbeitet wurde. Selbst ein einfacher Tipp-
fehler kostete einen wenigstens einen ganzen Tag. Ein wasserfallartiger Prozess, der eine
sorgfältige Abwägung des aktuellen Wissens und angesichts der Unsicherheit eine Vorher-
sage zuließ, damit man eine gute Lösung entwickelte, war in diesem Fall ökonomisch sinn-
voll.
Zum Glück sind die Werkzeuge und Technologien inzwischen besser geworden und die
Kosten für Erkundungen sind stark gesunken. Es ist nicht länger eine wirtschaftliche Kata-

74
3.3
Vorhersage und Anpassung

strophe, wenn man Erkundungen anstellt. Heute ist es oft sogar billiger, wenn man die
benutzerseitigen Feedbacks zu etwas, das man schnell gebaut hat, berücksichtigt, als
bereits im Voraus alles richtig zu machen. Schließlich wird auch der Kontext (die umgeben-
den Technologien), in dem unsere Lösungen überleben müssen, immer komplexer.
Falls wir in Scrum genügend Wissen angehäuft haben, um mit unserer Lösung einen qua-
lifizierten, vernünftigen Schritt nach vorn wagen zu können, kommen wir voran. Sehen wir
uns jedoch einer Unsicherheit gegenüber, dann versuchen wir nicht, sie mittels Vorhersa-
gen verschwinden zu lassen, sondern beschaffen uns die relevanten Informationen durch
Erkundungen, deren Ergebnisse uns dann auf dem Weg zu unserer Lösung voranbringen.
Die Feedbacks zu unserer Aktion helfen uns dabei festzulegen, ob und wann wir weiter
erkunden müssen.

3.3.4 Änderung auf eine ökonomisch sinnvolle Weise annehmen


Bei einer sequenziellen Entwicklung sind späte Änderungen deutlich teurer als frühe
(siehe Abbildung 3.9, nach Boehm 1981).
Kosten der Änderung

Analyse Design Progr. Tests Betrieb

Abb. 3.9: Bei der sequenziellen Entwicklung sind die Kosten für späte Änderungen ganz
beträchtlich.

So könnte z.B. eine Änderung während der Analyse 1 Dollar kosten – und die gleiche Ände-
rung während der (späten) Testphase könnte 1.000 Dollar kosten. Aber warum ist das so?
Wenn wir während der Analyse einen Fehler machen und ihn auch während der Analyse
finden, dann ist es nicht teuer, ihn zu beheben. Wird dieser Fehler dagegen erst beim
Design gefunden, dann müssen wir nicht nur die fehlerhafte Anforderung korrigieren,
sondern möglicherweise auch Teile unseres Designs, die auf dieser fehlerhaften Anforde-
rung beruhen. Denn dieser Fehler setzt sich durch jede nachfolgende Phase fort und so
wird aus einem vielleicht kleinen Mangel während der korrekten Analyse zu einem riesigen
Problem, das dann beim Test oder im Betrieb korrigiert werden muss.
Um späte Änderungen zu vermeiden, versuchen sequenzielle Prozesse, sich ändernde
Anforderungen oder Designs entweder sorgfältig zu kontrollieren oder auf ein Minimum

75
Kapitel 3
Agile Prinzipien

zu reduzieren, indem sie die Genauigkeit der Vorhersagen über das System oder den Pro-
zess verbessern.
Leider hat es oft den entgegengesetzten Effekt, wenn man in den Phasen der frühen Aktivi-
tät übermäßig prophetisch ist: Zum einen schafft man es nicht, Änderungen zu eliminie-
ren, zum anderen kann es passieren, dass zu spät ausgeliefert wird oder die Kosten
explodieren. Doch wie kommt es zu dieser paradoxen Wahrheit? Erstens zwingt uns der
Wunsch, teure Änderungen zu eliminieren, dazu, es in jeder Phase zu übertreiben – wir
verrichten mehr Arbeit, als notwendig und praktisch wäre. Und zweitens sind wir gezwun-
gen, frühzeitig im Prozess Entscheidungen zu treffen, die auf wichtigen Annahmen beru-
hen – bevor wir diese Annahmen durch Feedbacks von unseren Stakeholdern bestätigt
haben. In der Folge fertigen wir eine große Menge von Produkten an, die auf diesen
Annahmen beruhen. Und später müssen wir diese Ansammlung an Produkten dann mit
hoher Wahrscheinlichkeit korrigieren oder verwerfen, wenn wir unsere Annahmen bestäti-
gen (oder sie sich als ungültig herausstellen) oder eine Änderung auftritt (weil z.B. Anfor-
derungen auftauchen oder sich weiterentwickeln). Dies entspricht dem klassischen Muster
einer sich selbst erfüllenden Prophezeiung (siehe Abbildung 3.10).

1
Wir glauben, späte
Änderungen sind
sehr teuer

Änderungskosten bei
sequenzieller Entwicklung
Kosten der Änderung

4 2
Bei Änderungen müssen
Wir fürchten Kosten für
viele Produkte ent-
späte Änderungen, weshalb
sprechend angepasst oder
wir vorher länger und
verworfen werden, was
schwerer arbeiten, um
hohe Kosten verursacht
Änderungen zu vermeiden

Analyse Design Progr. Tests Betrieb

3
Was dafür sorgt, dass
wir vorzeitig viele
Produkte herstellen,
wie Spezifikationen
und Designs

Abb. 3.10: Sich selbst erfüllende Prophezeiung

In Scrum setzen wir einfach voraus, dass Änderungen normal sind. Wir glauben, dass wir
die der Produktentwicklung innewohnende Unsicherheit nicht einfach durch Vorhersagen
ausräumen können, indem wir im Vorfeld länger und schwerer arbeiten. Deshalb müssen

76
3.3
Vorhersage und Anpassung

wir uns darauf einstellen, dass Änderungen eintreten. Und wenn diese Änderung auftritt,
wollen wir, dass dies wirtschaftlich gesehen günstiger ist als bei der traditionellen Entwick-
lung, selbst wenn die Änderung später erfolgt.
Unser Ziel besteht deshalb darin, die Kostenkurve so lange wie möglich flach zu halten
– damit es ökonomisch sinnvoll ist, auch spät noch Änderungen vorzunehmen. Abbil-
dung 3.11 verdeutlicht diese Idee.
Wir können dieses Ziel erreichen, indem wir die Menge der Arbeit in diesem Prozess
und den Fluss dieser Arbeit so organisieren, dass die Kosten für eine Änderung beim
Einsatz von Scrum weniger durch den Zeitfaktor beeinflusst werden als bei sequenziel-
len Projekten.
Kosten der Änderung

Scrum
Traditionell

Zeit

Abb. 3.11: Abflachen der Kostenkurve

Unabhängig davon, welchen Ansatz zur Produktentwicklung wir verfolgen, soll folgende
Beziehung gelten: Eine kleine Änderung der Anforderungen soll eine ebenso kleine Ände-
rung bei der Implementierung und damit bei den Kosten ergeben (eine größere Änderung
würde natürlich entsprechend mehr kosten). Eine weitere wünschenswerte Eigenschaft
dieser Beziehung ist, dass sie unabhängig vom Zeitpunkt des Änderungswunsches gelten
soll.
Mit Scrum fertigen wir viele Arbeitsprodukte (wie etwa ausführliche Anforderungen,
Designs und Testfälle) zum Zeitpunkt des Bedarfs (just in time) an, womit wir die Herstel-
lung potenziell unnötiger Artefakte vermeiden. Wenn dann eine Änderung auftritt, müs-
sen üblicherweise weniger Artefakte oder Entscheidungen verworfen oder überarbeitet
werden, was die Kosten proportional zur angeforderten Änderung hält.
Bei einer sequenziellen Entwicklung führt die frühe Herstellung von Artefakten und der
Zwang, vorzeitig zu endgültigen Entscheidungen zu kommen, dazu, dass die Kosten für
Änderungen mit zunehmender Produktmenge rapide ansteigen. Der Wendepunkt auf der
traditionellen Kurve in Abbildung 3.11, also die Stelle, an der die Linie stark nach oben
ansteigt, tritt hier sehr früh auf. Bei der Entwicklung mit Scrum kommt ebenfalls unwei-
gerlich der Moment, ab dem die Kosten für eine Änderung nicht mehr proportional zur

77
Kapitel 3
Agile Prinzipien

Größe der Änderungsanfrage sind, allerdings tritt dieser Zeitpunkt (wie der Wendepunkt
auf der Scrum-Kurve in Abbildung 3.11 verdeutlicht) später ein.

3.3.5 Vorhersagende, im Voraus erfolgende Arbeit mit adaptiver,


bedarfsgerechter Arbeit abwägen
Ein fundamentaler Grundsatz der plangesteuerten Entwicklung besteht darin, dass aus-
führliche, im Voraus erfolgende Anforderungen und Planungen außerordentlich wichtig
sind und vor dem Erreichen späterer Stadien abgeschlossen werden sollten. In Scrum glau-
ben wir, dass die Vorabarbeit hilfreich sein, aber nicht übertrieben werden sollte.

• Art des Produkts


• Grad der End-Unsicherheit
• Grad der Methoden-Unsicherheit
• Entwicklungsbeschränkungen
• Konformität / regulatorische Anforderungen

Prädik
tiv
(vorab
)
Ad
(bedar aptiv
fsgere
cht)

Raten Chaos

Abb. 3.12: Abwägen der prädiktiven und der adaptiven Arbeit

Mit Scrum erkennen wir an, dass es nicht möglich ist, bereits im Voraus exakt alle Anforde-
rungen und Pläne zu kennen. Aber bedeutet das, dass wir im Vorhinein überhaupt keine
Anforderungen aufstellen oder Pläne schmieden sollten? Natürlich nicht! Bei Scrum geht
es darum, eine Balance zu finden – wägen Sie die prädiktive, im Voraus erfolgende Arbeit
gegen die adaptive, bedarfsgerechte Arbeit ab (siehe Abbildung 3.13, nach einem Bild von
Cohn 2009).
Wenn ein Produkt entwickelt wird, sollte der Ausgleichspunkt auf wirtschaftlich sinnvolle
Weise gesetzt werden, um die Anzahl der laufenden Anpassungen, die auf den schnellen
Feedbacks beruht, zu maximieren und die Anzahl der im Vorfeld stattfindenden Vorhersa-
gen zu minimieren, während vereinbarte, regulatorische und/oder unternehmerische
Randbedingungen erfüllt werden.
Wie genau dieser Ausgleich geschaffen wird, hängt teils vom Produkt ab, teils vom Grad
der Unsicherheit sowohl in dem, was wir bauen wollen (End-Unsicherheit), als auch in
dem, wie wir es bauen wollen (Methoden-Unsicherheit), und teils von den Beschränkun-
gen, denen die Entwicklung unterliegt. Wären wir übermäßig prophetisch veranlagt, müss-
ten wir angesichts einer großen Unsicherheit viele Annahmen treffen. Wären wir dagegen

78
3.4
Validiertes Wissen

übermäßig adaptiv, würden wir in einem Zustand ständiger Änderungen leben, wodurch
sich unsere Arbeit ineffektiv und chaotisch anfühlen würde. Um schnell innovative Pro-
dukte zu entwickeln, müssen wir in einem Raum agieren, in dem Anpassungsfähigkeit
durch gerade genügend Vorhersage ausgeglichen wird, um das Abgleiten ins Chaos zu ver-
hindern. Das Scrum-Framework arbeitet an diesem Ausgleichspunkt zwischen Ordnung
und Chaos ausgesprochen gut.

3.4 Validiertes Wissen


Wenn wir Scrum benutzen, dann organisieren wir die Arbeit so, dass wir schnell ein vali-
diertes Wissen schaffen (Validated Learning; vorgeschlagen wurde der Begriff von Ries
2011). Validiertes Lernen bedeutet, dass wir Wissen erwerben, das eine von uns getroffene
Annahme bestätigt oder widerlegt. Nachfolgend beschreibe ich in diesem Zusammenhang
drei agile Prinzipien:
쐽 Schnelles Validieren wichtiger Annahmen.
쐽 Abwägen mehrerer gleichzeitiger Lernschleifen.
쐽 Organisieren des Arbeitsablaufs für schnelle Feedbacks.

3.4.1 Schnelles Validieren wichtiger Annahmen


Eine Annahme ist eine Vermutung oder eine Vorstellung, von der man denkt, dass sie
wahr, real oder sicher ist, obwohl ihre Gültigkeit für uns noch nicht bestätigt (validiert)
wurde. Die plangesteuerte Entwicklung ist im Hinblick auf langlebige Annahmen deutlich
toleranter als Scrum. Bei einer plangesteuerten Entwicklung stellen wir bereits im Voraus
umfangreiche Anforderungen und schmieden Pläne, die sehr wahrscheinlich viele wich-
tige Annahmen umfassen, die allerdings erst in einer viel späteren Entwicklungsphase
bestätigt (oder verworfen) werden.
Annahmen stellen ein nicht zu unterschätzendes Risiko für die Entwicklung dar. In Scrum
versuchen wir, die Anzahl der wichtigen Annahmen, die zu einem Zeitpunkt existieren, zu
minimieren. Darüber hinaus wollen wir wichtige Annahmen nicht allzu lange ohne Vali-
dierung bestehen lassen. Um Annahmen schnell zu validieren, eignet sich die Kombina-
tion aus iterativer und inkrementeller Entwicklung, deren Fokus außerdem darauf liegt, die
Kosten der Erkundung gering zu halten. Falls wir mit Scrum eine grundlegend schlechte
Annahme treffen, werden wir unseren Fehler daher vermutlich schnell entdecken und
haben die Möglichkeit, seine Folgen umgehend zu beheben. Bei der plangesteuerten,
sequenziellen Entwicklung könnte die gleiche schlechte Annahme, wenn sie erst spät vali-
diert wird, ein teilweises oder vollständiges Scheitern der Entwicklung bedeuten.

3.4.2 Abwägen mehrerer gleichzeitiger Lernschleifen


Auch bei der sequenziellen Entwicklung gibt es einen Lernprozess. Allerdings tritt eine
wichtige Form des Lernens erst auf, nachdem Funktionen gebaut, integriert und getestet
wurden, also erst gegen Ende der Entwicklung. Spätes Lernen bringt nur wenige Vorteile
mit sich, weil die Zeit möglicherweise nicht ausreicht, um das Wissen wirksam einzuset-
zen, oder weil die Kosten für diesen Einsatz zu hoch sind.

79
Kapitel 3
Agile Prinzipien

In Scrum verstehen wir, dass ständiges Lernen der Schlüssel zum Erfolg ist. Wenn wir
Scrum einsetzen, erkennen und nutzen wir Feedback-Schleifen, um das Gelernte zu ver-
stärken. Ein wiederkehrendes Muster bei dieser Art von Produktentwicklung ist, eine
Annahme zu treffen (oder ein Ziel zu setzen), etwas zu bauen (einige Aktivitäten auszufüh-
ren), ein Feedback zu dem zu erhalten, was wir gebaut haben, und dieses dann zu nutzen,
um das, was wir gebaut haben, und unsere Annahme zu überprüfen. Anschließend neh-
men wir anhand dessen, was wir bei dieser Überprüfung gelernt haben, Anpassungen am
Produkt, Prozess und/oder unseren Vorstellungen vor (siehe Abbildung 3.13).
Scrum nutzt mehrere vordefinierte Lernschleifen aus. So ist z.B. der Daily Scrum eine täg-
liche Schleife und der Sprint-Review eine Schleife auf Iterationsebene. Diese und andere
Schleifen werde ich in späteren Kapiteln genauer beschreiben.

Annehmen

Anpassen Bauen

Überprüfen Feedback

Abb. 3.13: Muster der Lernschleife

Das Scrum-Framework ist flexibel genug für viele weitere Lernschleifen. So werden bei der
Scrum-Entwicklung, obwohl dies nicht spezifisch vorgegeben ist, oft z.B. auch Feedback-
Schleifen für technische Praktiken verwendet, wie etwa die Paarprogrammierung (sekun-
denschnelles Feedback) und die testgesteuerte Entwicklung (minutenschnelles Feedback).

3.4.3 Organisieren des Workflows für schnelle Feedbacks


Dass plangesteuerte Prozesse tolerant gegenüber langlebigen Annahmen sind, macht sie
auch tolerant gegenüber spätem Lernen. Schnelle Feedbacks sind also nicht unbedingt
gefragt und bedeutsam. Bei Scrum bemühen wir uns dagegen um schnelles Feedback, weil
es uns als wichtiges Hilfsmittel dient, um falsche Wege möglichst frühzeitig kappen und
sich bietende, zeitkritische Chancen möglichst schnell entdecken und ausnutzen zu kön-
nen.
In einer plangesteuerten Entwicklung wird jede Aktivität so geplant, dass sie zum passen-
den Zeitpunkt stattfindet. Dieser Zeitpunkt ist in der Abfolge der Phasen festgelegt. Bei die-
sem Ansatz wird davon ausgegangen, dass frühere Aktivitäten auch ohne das erst durch
spätere Aktivitäten generierte Feedbacks abgeschlossen werden können. Dadurch kann
eine lange Zeit zwischen einer Aktion und dem dazugehörigen Feedback verstreichen
(womit die Lernschleife geschlossen wird).

80
3.4
Validiertes Wissen

Nehmen wir als Beispiel einmal die Integration und das Testen von Komponenten. Stellen
Sie sich vor, wir würden drei Komponenten parallel entwickeln. Irgendwann müssen diese
Komponenten integriert und getestet werden, bevor wir ein Produkt haben, das ausgeliefert
werden kann. Solange wir die Integration nicht versucht haben, können wir wirklich nicht
mit Sicherheit sagen, ob wir die Komponenten korrekt entwickelt haben. Erst ein Versuch
der Integration liefert uns diesbezüglich wichtiges Feedback.
Bei einer sequenziellen Entwicklung würden Integration und Tests erst in der vorherbe-
stimmten Phase zum Ende der Entwicklung erfolgen. Dabei würden dann die meisten oder
alle Komponenten auf einmal integriert werden. Leider funktioniert es normalerweise
nicht, gleich einen ganzen Haufen Komponenten parallel zu entwickeln und sie dann spä-
ter in der Integrationsphase zu einem Ganzen zusammenzufügen – selbst wenn wir vor
der Entwicklung der Komponenten alle Schnittstellen sorgfältig definiert hätten, wäre es
sehr wahrscheinlich, dass bei der Integration etwas schiefgeht (siehe Abbildung 3.14).

Integrieren Wir unterschätzen fast


immer den wahren Aufwand
dieser Phase und wissen nie,
Komponente 1 wie lange sie dauern wird
Komponente 1

Komponente 2 Komponente 2 Testen


Test-
und-
Komponente 3
Reparaturphase Reparieren
Komponente 3

Früh Spät Später Wirklich spät

Abb. 3.14: Integration von Komponenten

Feedback-generierende Aktivitäten, die erst weit nach der Entwicklung auftreten, haben
bedauerliche Nebenwirkungen, beispielsweise verwandeln sie die Integration in eine große
Test-und-Reparaturphase, weil sich die Komponenten, die unabhängig voneinander entwi-
ckelt wurden, nicht reibungslos integrieren lassen. Wie lange es dauern und wie viel es kos-
ten wird, dieses Problem zu beheben, kann man zu diesem Zeitpunkt nur erahnen.
In Scrum organisieren wir den Workflow so, dass wir die Lernschleife in Abbildung 3.13
durchlaufen und so schnell wie möglich Feedback erhalten. Damit stellen wir eine zeitnahe
Durchführung Feedback-generierender Aktivitäten unmittelbar nach Beendigung der
ursprünglichen Entwicklungsarbeit sicher. Schnelles Feedback ist wirtschaftlich gesehen
enorm sinnvoll, da Fehler sich aufsummieren, wenn wir das Feedback verzögern, was das
Scheitern exponentiell vergrößern kann.
Schauen wir uns noch einmal das Beispiel der Komponentenintegration an. Beim Entwurf
der Komponenten haben wir wichtige Annahmen darüber getroffen, wie sie sich integrie-
ren lassen werden. Basierend auf diesen Annahmen haben wir den Designvorgang fortge-

81
Kapitel 3
Agile Prinzipien

setzt. Wir wissen an dieser Stelle noch nicht, ob der gewählte Designpfad richtig oder falsch
ist. Es ist einfach unsere beste Vermutung.
Sobald wir uns für einen Weg entschieden haben, treffen wir auf der Grundlage dieser
Wahl viele weitere Entscheidungen. Je länger wir warten, um die Gültigkeit der ursprüngli-
chen Designannahme zu überprüfen, umso größer ist die Anzahl der von ihr abhängigen
Entscheidungen. Stellen wir später (durch das Feedback während der Integrationsphase)
fest, dass die ursprüngliche Annahme falsch war, haben wir ein riesiges Schlamassel vor
uns: Wir müssen nicht nur viele schlechte Entscheidungen noch einmal überarbeiten, es
ist inzwischen auch eine Menge Zeit vergangen. Vermutlich können sich viele der Beteilig-
ten nicht mehr genau an alles erinnern, was sie gemacht haben, so dass sie Zeit brauchen,
um sich erneut einzuarbeiten.
Wenn wir die Gesamtkosten der Überarbeitung potenziell schlechter abhängiger Entschei-
dungen und die Kosten für die verzögerte Produktauslieferung bedenken, dann sind die
wirtschaftlichen Vorteile eines schnellen Feedbacks sehr verlockend. Durch schnelle Feed-
backs wird die Lernschleife sehr schnell wieder geschlossen, wodurch wir schlechte Ent-
wicklungswege kappen können, bevor sie ernsthaften wirtschaftlichen Schaden anrichten.

3.5 Work in Process (WIP)


Der Ausdruck Work in Process (oder WIP; laufende Arbeit, aber auch: Ware in Arbeit)
bezieht sich auf die Arbeit, die begonnen, aber noch nicht abgeschlossen wurde. Während
der Produktentwicklung muss WIP erkannt und richtig organisiert werden. Im Folgenden
beschreibe ich in diesem Zusammenhang vier agile Prinzipien:
쐽 Wirtschaftlich vernünftige Batch-Größen benutzen.
쐽 Lagerbestände erkennen und sinnvoll verwalten.
쐽 Auf unerledigte Arbeit konzentrieren, nicht auf untätige Arbeiter.
쐽 Verzögerungskosten betrachten.

3.5.1 Wirtschaftlich sinnvolle Batch-Größen benutzen


Eine weitere wesentliche Überzeugung bei der plangesteuerten, sequenziellen Entwick-
lung besteht darin, dass es wünschenswert ist, erst eine Art von Arbeit vollständig zusam-
menzufassen und dann in einer einzigen Phase zu erledigen. Ich bezeichne dies als den
All-before-any-Ansatz, bei dem wir eine Aktivität erst komplett (oder nahezu komplett)
abschließen, bevor wir zur nächsten Aktivität übergehen. Nehmen wir einmal an, wir
schaffen während der Analysephase all diese Anforderungen. Als Nächstes verschieben wir
den Stapel der Anforderungen in die Designphase. Da wir den kompletten Satz an Anforde-
rungen hergestellt haben, beträgt unsere Batch-Größe in diesem Beispiel 100%.
Der All-before-any-Ansatz ist zum Teil eine Konsequenz der Überzeugung, dass sich das
alte Produktionsprinzip der Wirtschaftlichkeit des Maßstabs auf die Produktentwicklung
anwenden lässt. Dieses Prinzip besagt, dass die Kosten für die Fertigung einer Einheit sin-
ken, wenn wir die Anzahl der Einheiten (die Batch- oder Stapelgröße), die produziert wer-
den, erhöhen. Bei der sequenziellen Entwicklung wird also angenommen, dass größere
Stapel in der Produktentwicklung ebenfalls das Prinzip der Wirtschaftlichkeit des Maßstabs
erfüllen.

82
3.5
Work in Process (WIP)

In Scrum akzeptieren wir, dass dieses Denken zwar eins der grundlegenden Prinzipien bei
der Fertigung darstellt, seine dogmatische Befolgung bei der Produktentwicklung jedoch
zu beträchtlichen wirtschaftlichen Schäden führen kann.
Auch wenn das aller Logik zu widersprechen scheint, kann es sich doch als vorteilhaft
erweisen, während der Produktentwicklung in kleineren Batches zu arbeiten. Reinertsen
diskutiert das Problem der Batch-Größe ausführlich, und Tabelle 3.2 zeigt einige der von
ihm beschriebenen Vorteile kleiner Batch-Größen (Reinertsen 2009b).
Wenn kleine Batches besser sind als große, sollten wir dann nicht möglicherweise zu einer
Batch-Größe von 1 übergehen, das heißt, immer nur an jeweils einer einzigen Anforderung
arbeiten und sie durch alle Aktivitäten führen, bis sie fertig ist und an den Kunden ausge-
liefert werden kann? Dies wird als Single-Piece-Flow (zu Deutsch auch als MAF, »Mitarbei-
tergebundener Arbeitsfluss«) bezeichnet. Wie ich später noch zeigen werde, kann eine
Batch-Größe von 1 zwar in manchen Fällen sinnvoll sein, doch anzunehmen, dass »1« das
Ziel ist, verhindert möglicherweise eine Optimierung des Flusses und unserer gesamten
wirtschaftlichen Entwicklung.

Vorteil Beschreibung
Reduzierte Zykluszeit Kleinere Batches ergeben weniger Arbeit, die erledigt werden
muss, was wiederum bedeutet, dass man weniger Zeit aufwendet,
um darauf zu warten, dass die Arbeit fertig wird. Wir erledigen
Dinge also schneller
Reduzierte Denken Sie an ein Restaurant, in dem kleine Gruppen von Leuten
Flussvariabilität kommen und gehen (sie »fließen« schön durch das Restaurant).
Stellen Sie sich nun einen Reisebus vor (großer Batch), aus dem
Leute aussteigen, und die Wirkung, die dies auf das Restaurant
hat.
Beschleunigte Kleine Batches beschleunigen die Feedbacks, wodurch sich Fehler
Feedbacks geringfügiger auswirken.
Reduziertes Risiko Kleine Batches bedeuten einen geringeren Bestand, der sich
ändern könnte. Kleinere Batches gehen auch seltener schief (es
besteht ein größeres Risiko, dass bei zehn Teilen etwas passiert als
bei fünf).
Reduzierter Overhead Die Verwaltung großer Batches bringt einen Overhead mit sich –
so ist das Pflegen einer Liste mit 30.000 Arbeitsobjekten aufwen-
diger als einer Liste mit 30 Objekten.
Erhöhte Motivation Kleine Batches erlauben einen Fokus und ein Gefühl für Verant-
und Dringlichkeit wortung. Es ist viel einfacher, die Auswirkungen von Verzögerun-
gen und Fehlern zu verstehen, wenn man es nur mit kleinen
Batches zu tun hat.
Reduzierte Zunahme Wenn wir uns bei großen Batches irren, dann erleben wir auch
von Kosten und Zeit einen großen Schaden in Bezug auf Kosten und Zeitplan. Arbei-
ten wir in einem kleineren Maßstab, bleiben die Schäden im Rah-
men.
Tabelle 3.2: Vorteile kleiner Batch-Größen nach Reinertsen

83
Kapitel 3
Agile Prinzipien

3.5.2 Lagerbestände erkennen und sinnvoll verwalten


Ich habe Sie im Laufe dieses Kapitels wiederholt daran erinnert, dass Fertigung und Pro-
duktentwicklung nicht das Gleiche sind und deshalb unterschiedlich angegangen werden
sollten. Es gibt jedoch eine Lehre aus der Fertigung, die wir auf die Produktentwicklung
anwenden sollten, auch wenn wir es oft nicht tun. Diese Lehre hat mit den hohen Kosten
des Bestands zu tun, also mit der Ware, die in Arbeit ist (Work in Process oder WIP). Beim
Lean Product Development (Schlanke Produktentwicklung) hat man schon vor langer Zeit
die Bedeutung der WIP erkannt (Poppendieck und Poppendieck 2003; Reinertsen 2009b),
und auch Scrum-Teams übernehmen dieses Konzept mittlerweile.
Hersteller sind sich ihrer Lagerbestände und der finanziellen Implikationen dieser
Bestände ganz akut bewusst. Wieso auch nicht? Lagerbestände fangen ganz schnell an, sich
zu stapeln, während sie auf ihre Weiterverarbeitung warten. So ein Lager ist nicht nur phy-
sisch sichtbar, sondern auch finanziell. Fragen Sie den Finanzvorstand eines produzieren-
den Unternehmens einmal, wie groß der Lagerbestand ist, den er in seiner Fabrik hat, oder
wie stark sich dieser im letzten Monat geändert hat. Er wird Ihnen eine definitive Antwort
geben können.
Kein kompetenter Hersteller sitzt lange auf einem großen Lagerbestand. Teile, die
irgendwo herumliegen oder -stehen und darauf warten, in fertige Waren umgewandelt zu
werden, verlieren in den Büchern an Wert. Noch schlimmer: Was passiert, wenn wir einen
ganzen Laster voller Teile erwerben und dann das Design des Produkts ändern? Was
machen wir dann mit all diesen Teilen? Vielleicht können wir sie umarbeiten, damit sie in
das neue Design passen. Oder schlimmer: Vielleicht müssen wir die Teile abschreiben und
wegwerfen, weil sie nicht mehr benutzt werden können. Damit die Teile nicht entsorgt wer-
den müssen und damit umsonst gekauft wurden, könnten wir darauf verzichten, das
Design zu ändern (auch wenn das die richtige Entscheidung wäre), damit wir die Teile doch
noch einbauen können – auch wenn das Produkt dann nicht zu unserer Zufriedenheit aus-
fiele.
Offensichtlich kommt es zu beträchtlicher Verschwendung, wenn wir unsere Lager mit Tei-
len vollstopfe und sich dann etwas ändert. Um die Risiken zu minimieren, organisieren
kompetente Hersteller ihre Lager auf ökonomisch vernünftige Weise: Sie halten eine
gewisse Anzahl an Teilen vor, greifen ansonsten aber auf ein gesundes Maß an Just-in-time-
Lagerhaltung zurück.
Unternehmen, die Produkte entwickeln, sind sich ihrer in Arbeit befindlichen Ware (WIP)
im Allgemeinen nicht annähernd so bewusst. Teilweise liegt das daran, dass wir es bei der
Produktentwicklung mit einem Bestand an Wissen zu tun haben, der physisch nicht in der
gleichen Weise sichtbar ist wie Teile, die in einer Halle herumstehen. Wissensbestände
sind viel weniger auffällig – denken Sie an Code auf einer Festplatte, ein Dokument in
einem Aktenschrank oder eine Tafel an der Wand.
Auch finanziell zeigt sich der Bestand in der Produktentwicklung nicht so deutlich. Fragen
Sie den Finanzvorstand eines entwickelnden Unternehmens, wie groß der Lagerbestand
ist, und er wird Sie vermutlich fragend anschauen und sagen: »Es gibt keinen«. Die Finanz-
abteilung verfolgt zwar sicher irgendwelche Maße bei der Produktentwicklung, aber zwei-
fellos nicht in dieser Form.

84
3.5
Work in Process (WIP)

Leider ist das Lager (WIP) eine kritische Variable, auf die man während der Produktent-
wicklung achten muss. Traditionelle Ansätze für die Produktentwicklung konzentrieren
sich nicht auf die Organisation dieses speziellen Bestands. Wie ich in der Diskussion der
Batch-Größen bereits erwähnte, bevorzugt die traditionelle Entwicklung die Schaffung sehr
großer Lager, indem es eine relativ große Batch-Größe wählt (oft 100%). Eine wichtige Kon-
sequenz aus diesem Vorgehen ist, dass die Änderungskosten stark davon beeinflusst wer-
den (siehe die Kurve in Abbildung 3.9).
Wir benötigen zwar einige Anforderungen, wenn wir mit der Entwicklung beginnen, es ist
aber nicht erforderlich, alle Anforderungen zu haben. Haben wir zu viele Anforderungen,
wird sicher eine gewisse Verschwendung der Bestände eintreten, wenn es zu Änderungen
kommt. Haben wir andererseits nicht genügend Anforderungen, unterbrechen wir den
schnellen Workflow, was ebenfalls eine Art von Verschwendung ist. In Scrum besteht unser
Ziel darin, die richtige Balance zwischen gerade genügend Lagerbestand und zu viel Lager-
bestand zu finden.
Es ist wichtig zu erkennen, dass Anforderungen nur eine Form des Lagerbestands sind, der
in der Produktentwicklung existiert. Während der Produktentwicklung können in Arbeit
befindliche Waren an unterschiedlichen Stellen und zu unterschiedlichen Zeiten auftreten.
Und diese müssen wir ebenfalls aktiv identifizieren und organisieren.

3.5.3 Auf unerledigte Arbeit konzentrieren, nicht auf untätige Arbeiter


In Scrum glauben wir, dass unerledigte Arbeit eine viel größere Verschwendung ist und
mehr wirtschaftlichen Schaden verursacht als untätige Arbeiter. Unerledigte Arbeit ist
Arbeit, die wir tun wollen (z.B. etwas bauen oder testen), aber nicht tun können, weil uns
etwas daran hindert. Vielleicht werden wir aufgehalten, weil wir darauf warten, dass das
andere Team etwas macht und selbst vorher nichts tun können. Oder vielleicht haben wir
so viel Arbeit, dass wir nicht alles auf einmal schaffen. In diesem Fall bleibt ein Teil der
Arbeit liegen, bis wir wieder frei sind, um daran zu arbeiten. Untätige Arbeiter dagegen
sind Menschen, die die Kapazität haben, mehr zu arbeiten, weil sie momentan nicht zu
100% ausgelastet sind.
Viele Organisationen, die Produkte entwickeln, konzentrieren sich mehr darauf, die Ver-
schwendung von untätigen Arbeitern zu eliminieren als die Verschwendung von unerledig-
ter Arbeit. Würde ich Sie nach der traditionellen Denkweise beispielsweise als Tester
engagieren, dann würde ich erwarten, dass Sie 100% Ihrer Zeit mit dem Testen verbringen.
Und würden Sie weniger als 100% Ihrer Zeit dafür aufwenden, käme mir der Verdacht
eines Falls von Verschwendung (da Sie untätig wären, obwohl Sie testen könnten). Um die-
ses Problem zu vermeiden, würde ich wiederum mehr Testarbeiten für Sie finden – mögli-
cherweise, indem ich Ihnen mehrere Projekte zuweisen würde –, so dass Ihre Auslastung
auf 100% stiege.
Leider verringert dieses Vorgehen zwar eine Form der Verschwendung (untätige Arbeiter),
gleichzeitig fördert sie aber auch eine andere Form der Verschwendung (unerledigte
Arbeit). Und meist sind die Kosten für die unerledigte Arbeit viel höher als die Kosten für
einen untätigen Arbeiter. Lassen Sie uns doch einmal untersuchen, wieso das so ist.
Um das Problem zu verdeutlichen, wollen wir die Strategie, unsere Arbeiter zu 100% aus-
zulasten, auf die 4-x-100-Meter-Staffel bei den Olympischen Spielen anwenden. Im Hin-

85
Kapitel 3
Agile Prinzipien

blick auf die »Beschäftige-sie-immer«-Strategie scheint dieses Rennen absolut ineffizient


zu sein: Ich bezahle Leute, damit sie laufen, allerdings scheinen sie das nur ein Viertel der
Zeit auch zu tun. In der restlichen Zeit stehen sie bloß herum. Das kann nicht richtig sein!
Ich bezahle ihnen ein 100%-iges Gehalt, also möchte ich auch, dass sie 100% der Zeit lau-
fen. Wie wäre es, wenn sie in der Zeit, in der sie den Staffelstab nicht haben, auf dem Platz
hin- und herlaufen oder auf dem Nachbarplatz ein anderes Rennen absolvieren? Auf diese
Weise würden sie 100% der Zeit mit Laufen verbringen.
Natürlich wissen wir, dass man Staffelgold nicht gewinnt, indem man die Läufer zu 100%
auslastet – man gewinnt, indem man zuerst den Staffelstab über die Ziellinie trägt. Die
wichtige Botschaft lautet also: »Behalte den Staffelstab im Auge, nicht die Läufer« (Larman
und Vodde 2009). Im Kontext der Produktentwicklung ist der Staffelstab auf dem Boden
mit der Arbeit gleichzusetzen, die zwar ausführbar ist, aber blockiert wird, weil auf die not-
wendigen Ressourcen gewartet werden muss: Sie gewinnen das Rennen nicht (liefern die
Produkte nicht aus), wenn der Staffelstab auf dem Boden liegt. (Mir gefällt die Analogie mit
der Staffelmannschaft wirklich gut, weil sie verdeutlicht, dass wir die Arbeit und nicht die
Arbeiter beobachten sollten. Wie jede Analogie hat aber auch diese ihre Grenzen. In diesem
Fall entspricht der Staffelansatz des Übergebens der Arbeit exakt einem Aspekt der traditi-
onellen, sequenziellen Produktentwicklung, den wir eigentlich vermeiden wollen!)
Außerdem kennt jeder die Konsequenzen, wenn man eine Ressource zu 100% auslastet.
Um einmal ein Diagramm aus der Warteschlangentheorie auszuborgen: Wir erkennen den
offensichtlichen Schaden, der entsteht, wenn wir eine Auslastung von 100% anstreben
(siehe Abbildung 3.15).

20
18
16
14
Warteschlangengröße

12
10
8
6

4
2

0
10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Auslastung

Abb. 3.15: Einfluss der Auslastung auf die Größe der Warteschlange (Verzögerung)

Jeder, der einen Computer besitzt, versteht dieses Diagramm. Was passiert, wenn Sie Ihren
Computer mit 100%-iger Auslastung betreiben (volle Prozessor- und Speicherlast)? Er

86
3.5
Work in Process (WIP)

beginnt zu überlasten und die auszuführenden Tasks werden immer langsamer. Mit ande-
ren Worten, der Computer arbeitet an immer mehr Dingen, schließt aber immer weniger
Arbeiten ab. Es ist nicht einfach, diesen Zustand wieder zu ändern (vermutlich müssen Sie
Tasks beenden oder den Rechner neu starten). Bei einer Auslastung von etwa 80% wäre Ihr
Computer viel effizienter. In Abbildung 3.15 entspricht die Länge der Warteschlange der
Verzögerung und die Verzögerung ist quasi der Staffelstab auf dem Boden.
Die unerledigte Arbeit (verzögerte Arbeit) nimmt bei sehr hoher Auslastung exponentiell
zu. Und das kann sehr teuer sein, viel teurer als die Kosten für die untätigen Arbeiter (im
nächsten Abschnitt finden Sie ein Beispiel dafür). In Scrum sind wir uns also sehr deutlich
bewusst, dass es ökonomisch gesehen erheblich sinnvoller ist, die Flaschenhälse in unse-
ren Arbeitsabläufen zu finden und zu eliminieren, als alle Mitarbeiter zu 100% zu beschäf-
tigen.

3.5.4 Verzögerungskosten betrachten


Verzögerungskosten sind die Kosten, die auftreten, wenn sich Arbeit oder das Erreichen
eines Zwischenziels (Meilenstein) verzögert. Abbildung 3.15 zeigt, dass Warteschlangen-
größe und Verzögerung ebenfalls zunehmen, wenn die Auslastung steigt. Indem wir also
die Verschwendung an untätigen Arbeitern reduzieren (sprich deren Auslastung erhöhen),
erhöhen wir gleichzeitig die Verschwendung, die mit unerledigter Arbeit einhergeht
(Arbeit, die in Warteschlangen darauf wartet, erledigt zu werden). Mithilfe der Verzöge-
rungskosten können wir berechnen, welche Verschwendungsform den größeren wirt-
schaftlichen Schaden anrichtet.
Leider stellen 85% der Organisationen die Kosten von Verzögerungen nicht fest (Reinert-
sen 2009b). Und betrachtet man dies in Kombination mit der Tatsache, dass die meisten
Entwicklungsorganisationen gar nicht merken dass sie Arbeit angehäuft haben, die auf
Erledigung wartet, kann man sich leicht vorstellen, wieso sie sich normalerweise darauf
konzentrieren, die sichtbare Verschwendung in Form untätiger Arbeiter zu eliminieren.
Hier ein einfaches Beispiel, das verdeutlichen soll, wieso die Kosten für unerledigte Arbeit
typischerweise so viel höher sind als die Kosten für untätige Arbeiter. Stellen Sie sich doch
einmal folgende Frage: Sollten wir dem Team am ersten oder am letzten Tag der Entwick-
lung jemanden zuweisen, der sich um die Dokumentation kümmert? Tabelle 3.3 zeigt
einen Vergleich dieser beiden Optionen (es gibt aber noch weitere).
Nehmen Sie an, dass wir den Dokumentationsverantwortlichen für 12 Monate Vollzeit ein-
stellen, um an diesem Produkt zu arbeiten, auch wenn er nicht 100% der Zeit benötigt
wird. Dies würde uns 75.000 Dollar mehr kosten, als wenn wir ihn erst in den letzten zwei
Monaten engagieren würden, wenn das Produkt den Zustand »fast fertig, es fehlt nur die
Dokumentation« erreicht hat.

Parameter Wert
Dauer mit Vollzeit-Dokumentar 12 Monate
Dauer mit einem Dokumentar, der am Ende zugewiesen wird (wenn 14 Monate
wir den Zustand »alles, bis auf die Dokumentation« erreicht haben)
Tabelle 3.3: Beispielrechnung: Kosten der Verzögerung

87
Kapitel 3
Agile Prinzipien

Parameter Wert
Zykluszeitkosten, wenn die Dokumentation am Ende gemacht wird 2 Monate
Kosten der Verzögerung pro Monat 250.000 Dollar
Gesamtkosten der Verzögerung 500.000 Dollar

Jährliche Komplettkosten für einen Dokumentar 90.000 Dollar


Monatliche Vollzeitkosten für einen Dokumentar 7.500 Dollar
Kosten für einen Vollzeit-Dokumentar 90.000 Dollar
Kosten für einen Dokumentar, der erst am Ende zugewiesen wird 15.000 Dollar
Inkrementelle Kosten für einen Vollzeit-Dokumentar 75.000 Dollar
Tabelle 3.3: Beispielrechnung: Kosten der Verzögerung (Forts.)

Weisen wir den Dokumentar erst am Ende zu, um die gesamte Dokumentation zu erstel-
len, brauchen wir ihn nur für zwei Monate Vollzeit, verzögern aber gleichzeitig die Auslie-
ferung des Produkts um diese zwei Monate. Und wenn wir die Auslieferung des Produkts
um zwei Monate verzögern, liegen die berechneten Kosten in Bezug auf den Lifecycle Profit
bei 500.000 Dollar. (Der Lifecycle Profit bezeichnet das gesamte Profitpotenzial eines Pro-
dukts über seine Lebensdauer gerechnet – in diesem Fall sinkt dieses Potenzial um
500.000 Dollar).
In diesem Beispiel betragen die Kosten für den untätigen Arbeiter 75.000 Dollar und die
Kosten für die unerledigte Arbeit 500.000 Dollar. Sollten wir uns darauf konzentrieren, die
Auslastung für den Dokumentar zu optimieren, verschlechtern wir damit die wirtschaftli-
chen Aussichten für das Gesamtprodukt. Während der Produktentwicklung sehen wir uns
ständig solchen Konflikten ausgesetzt – und die Verzögerungskosten gehören dabei zu den
wichtigsten Variablen, die es zu beachten gilt, wenn man wirtschaftlich sinnvolle Entschei-
dungen trifft.

3.6 Fortschritt
Wenn wir Scrum benutzen, dann messen wir den Fortschritt an dem, was wir ausgeliefert
und validiert haben, und nicht daran, wie wir entsprechend eines vordefinierten Plans vor-
angekommen sind oder wo wir in einer bestimmten Phase der Entwicklung stehen. Ich
beschreibe in diesem Zusammenhang nachfolgend drei agile Prinzipien:
쐽 An Echtzeitinformationen anpassen und umplanen.
쐽 Fortschritt messen, indem man funktionierende Güter validiert.
쐽 Auf eine wertzentrierte Auslieferung konzentrieren.

3.6.1 An Echtzeitinformationen anpassen und umplanen


In einem plangesteuerten, sequenziellen Prozess ist der Plan der maßgebliche Faktor, der
bestimmt, wie und wann Arbeit erledigt werden soll. Daher wird auch erwartet, dass er

88
3.6
Fortschritt

befolgt wird. Im Gegensatz dazu glauben wir in Scrum, dass uns bedingungsloses Ver-
trauen in den Plan oftmals übersehen lässt, dass er falsch sein könnte.
Bei einer Scrum-Entwicklung besteht unser Ziel nicht darin, blind irgendeinem Plan, d.h.
einer im Vorhinein umrissenen Einschätzung des zu erwartenden Entwicklungsablaufs zu
folgen. Vielmehr lautet die Zielsetzung, zügig neu planen und eine jederzeitige Anpassung
an die kontinuierlich eingehenden wirtschaftlich wichtigen Informationen vornehmen zu
können.

3.6.2 Fortschritt messen, indem man funktionierende Güter validiert


Im Rahmen einer sequenziellen, plangesteuerten Entwicklung lässt sich der erzielte Fort-
schritt daran erkennen, dass eine Phase abgeschlossen wird und damit in die nächste
Phase eingetreten werden kann. Mit anderen Worten: Sofern die einzelnen Phasen wie
erwartet starten und enden, scheint die Produktentwicklung ganz gut voranzugehen. Den-
noch könnte das Produkt, das wir entsprechend dem Plan hergestellt haben, am Ende
einen viel geringeren Wert für den Kunden ergeben, als wir gedacht haben. Können wir
wirklich einen Erfolg für uns verbuchen, wenn wir zwar pünktlich und innerhalb des Bud-
gets fertig geworden sind, die Erwartungen des Kunden jedoch nicht erfüllen konnten?
In Scrum messen wir den Erfolg dadurch, dass wir funktionierende, validierte Güter her-
stellen, die einen Wert besitzen und benutzt werden können, um die Gültigkeit wichtiger
Annahmen zu bestätigen. Das liefert uns das Feedback, das wir brauchen, um zu wissen,
wann der jeweils nächste Schritt erfolgen sollte. In Scrum geht es nicht darum, wie viel
Arbeit wir anfangen, sondern wie viel für den Kunden wertvolle Arbeit wir abschließen.

3.6.3 Auf eine wertzentrierte Auslieferung konzentrieren


Die plangesteuerte, sequenzielle Entwicklung konzentriert sich darauf, dem Prozess gewis-
senhaft zu folgen. Ihre Struktur gibt vor, dass die Integration und Auslieferung während
einer sequenziellen Entwicklung am Ende der Arbeit erfolgen (siehe Abbildung 3.16). Die-
ses Vorgehen birgt das Risiko, dass uns die Ressourcen (Zeit oder Geld) ausgehen, bevor
wir alle wichtigen Werte an unsere Kunden geliefert haben.
Eine damit verwandte Vorstellung der traditionellen Entwicklung ist, dass die Planungs-
und Dokumentartefakte, die auf dem Weg hergestellt werden, selbst auch wertvoll sind.
Falls diese Artefakte wirklich wertvoll sind, dann sind sie das nur für den laufenden Prozess
und nicht für die Kunden. Und falls sie für den Kunden einen Wert besitzen, dann äußert
sich dieser Wert nur, wenn irgendwann ein wünschenswertes Produkt an den Kunden aus-
geliefert wird. Bis dahin haben diese Artefakte keinen direkten Wert für den Kunden.
Scrum dagegen stellt eine kundenwertzentrierte Form der Entwicklung dar. Es basiert auf
einem priorisierten, inkrementellen Auslieferungsmodell, bei dem in der nächsten Itera-
tion stets die Funktionen mit dem höchsten Wert gebaut und ausgeliefert werden. Kunden
erhalten viel schneller Funktionen mit hohem Wert.
In Scrum wird Wert generiert, indem funktionierende Güter an Kunden ausgeliefert wer-
den, wichtige Annahmen validiert werden oder wertvolles Wissen gesammelt wird. Wir
sind der Meinung, dass die auf dem Weg entstehenden Artefakte keinen tatsächlichen Wert
für den Kunden darstellen, sondern lediglich Mittel zum Zweck sind, solange sie nicht dazu
dienen können, wichtiges Feedback zu generieren oder wichtiges Wissen zu erlangen.

89
Kapitel 3
Agile Prinzipien

Scrum
Gelieferter Wert
Traditionell

Zeit

Abb. 3.16: Frühere Auslieferung von Funktionen mit hohem Wert

3.7 Leistung
Es gibt spezielle leistungsbezogene Eigenschaften, die wir erwarten, wenn wir Scrum ein-
setzen. Im Folgenden beschreibe ich in diesem Zusammenhang drei agile Prinzipien:
쐽 Gehe schnell, aber hetze nicht.
쐽 Baue Qualität ein.
쐽 Mache alles ohne großes Zeremoniell.

3.7.1 Gehe schnell, aber hetze nicht


Die plangesteuerte Entwicklung geht davon aus, dass wir teure und zeitaufwendige Überar-
beitungen vermeiden, wenn wir dem Plan folgen und alles gleich beim ersten Mal richtig
machen. Natürlich ist es wünschenswert, schnell von einem Schritt zum nächsten zu
gelangen – es ist aber kein vorrangiges Ziel.
In Scrum besteht ein wesentliches Ziel darin, geschickt, anpassungsfähig und schnell zu
sein. Indem wir schnell vorgehen, liefern wir schnell, erhalten schnell Feedback und über-
geben unseren Kunden die Werte schneller. Schnell zu lernen und zu reagieren erlaubt es
uns, eher einen Gewinn zu erzielen und/oder die Kosten zu reduzieren.
Verwechseln Sie jedoch ein schnelles Vorgehen nicht mit einer Hetzjagd. In Scrum ist Zeit
entscheidend, allerdings rasen wir nicht durch unsere Arbeit. Das würde nämlich das
Scrum-Prinzip der nachhaltigen Geschwindigkeit verletzen – die Leute sollen in einer
Geschwindigkeit arbeiten, die sie auch über einen längeren Zeitraum durchhalten können.
Außerdem geht die Eile mit ziemlicher Sicherheit auf Kosten der Qualität.
Das folgende Beispiel soll den Unterschied zwischen schnell und gehetzt besser verdeutli-
chen. Ich lerne zurzeit Muay Thai (Thai-Kickboxen). Wie bei jeder Kampfsportart wird auch
beim Muay Thai die Leistung durch Geschwindigkeit verbessert. Wenn man in der Lage ist,
die Katas bzw. Schläge zügig und akkurat durchzuführen, macht der Sport mehr Spaß und
man erzielt bessere Ergebnisse. Hetzt man jedoch durch die Bewegungen, um schneller
fertig zu werden, reduziert man ihre Effektivität ganz beträchtlich und riskiert ernsthafte
Verletzungen. Beim Muay Thai bewegt man sich zügig, geschickt und mit Bedacht, wäh-
rend man sich schnell an die Situation anpasst. Mit anderen Worten: Sie müssen schnell
sein, dürfen aber nicht hetzen.

90
3.7
Leistung

3.7.2 Baue Qualität ein


In der plangesteuerten Entwicklung herrscht die Vorstellung vor, dass man durch die sorg-
fältige sequenzielle Durchführung der Arbeit ein hochwertiges Produkt erhält. Allerdings
können wir diese Qualität erst verifizieren, wenn wir das integrierte Produkt testen – was in
einer sehr späten Phase des Prozesses geschieht. Wenn die Tests ergeben, dass die Qualität
mangelhaft ist, müssen wir in die teure Test-und-Reparaturphase eintreten, um die Qualität
»hineinzutesten«. Und da häufig in jeder Phase ein anderes Team am Werk ist, entsteht
dabei der Eindruck, als würde das Testteam die Qualität des Ergebnisses bestimmen.
In Scrum ist Qualität nicht etwas, das vom Testteam am Ende »hineingetestet« wird. Viel-
mehr ist sie in diesem Fall etwas, das dem funktionsübergreifenden Scrum-Team »gehört«
und das stetig eingebaut und in jedem Sprint verifiziert wird. Jedes Werteinkrement, das
geschaffen wird, wird mit einem hohen Maß an Zuversicht abgeschlossen und kann poten-
ziell in die Produktion übergeben oder an Kunden ausgeliefert werden. (In Kapitel 4 gehen
wir ausführlich auf die Definition von »Fertig« ein.) Dadurch wird die Notwendigkeit für
die Durchführung von Tests zur Rettung der Qualität in einem späteren Stadium erheblich
reduziert.

3.7.3 Mache alles ohne großes Zeremoniell


Bei plangesteuerten Prozessen wird oftmals viel Wert auf Zeremonien, Dokumente und
Prozesse gelegt. Eine Nebenwirkung der Wertzentrierung von Scrum ist dagegen, dass pro-
zesszentriertem Zeremoniell nur wenig Bedeutung beigemessen wird. Ich möchte damit
gar nicht behaupten, dass Formalitäten und Zeremonien generell schlecht sind. Eine hilf-
reiche »Zeremonie« könnte z.B. sein, jeden Freitag nach der Arbeit in eine Kneipe zu
gehen und Zeit miteinander zu verbringen. In diesem Zusammenhang beziehe mich viel-
mehr auf unnötige Formalitäten. Man könnte auch sagen »Prozesse um des Prozesses wil-
len«. Ein derartiges Zeremoniell bringt Kosten mit sich, hat aber kaum oder keinen Wert
(ist also eine Art von Verschwendung).
Beispiele für solche unnötigen formellen Dinge könnten sein:
쐽 Das Erfordernis eines dreitägigen, umfangreichen Prozesses, um Code bestätigen und
aus der Entwicklung in die Qualitätssicherung übergeben zu können, bevor wir testen
dürfen.
쐽 Alle Anomalien müssen in einer Software vermerkt werden, damit sie nachvollzogen
und dokumentiert werden können, obwohl ich eigentlich nur meinem Nachbarn auf
die Schulter tippen und ihm sagen müsste: »Schau mal, das funktioniert nicht. Könn-
test du das reparieren?«, um meine Arbeit fortzusetzen.
쐽 Ich schreibe ein Dokument, einfach weil es für diesen Zeitpunkt so vorgesehen ist, ob-
wohl mir niemand sagen kann, wieso dieses Dokument notwendig oder wichtig ist.
In Scrum ist es unser Ziel, unnötige Formalitäten zu eliminieren. Daher setzen wir die
zeremoniellen Hürden auf ein sehr niedriges Niveau (manche würden es als »kaum ausrei-
chend« bezeichnen). Natürlich kann dieses Niveau von Organisation zu Organisation
unterschiedlich ausfallen. Wenn wir eine neue Social-Media-Website aufbauen, werden
Zeremoniell und Formalitäten vermutlich besonders marginal sein. Bauen wir dagegen
einen Herzschrittmacher und sehen uns zahllosen Regierungsregulatorien ausgesetzt, die
bestimmte Arten von Formalitäten erfordern, muss das Mindestmaß natürlich etwas höher
liegen (siehe Abbildung 3.17).

91
Kapitel 3
Agile Prinzipien

Der Scrum-Fokus auf ein Minimum an Zeremoniell wird oft fehlinterpretiert: »Scrum ist
gegen Dokumentation«. Doch das ist nicht wahr! Wenn wir Scrum einsetzen, nehmen wir
vielmehr eine ökonomische Sichtweise ein und überlegen sorgfältig, welche Dokumente
wir erstellen können. Falls wir ein Dokument abfassen, das nur für die Schublade gedacht
ist und keinen Wert besitzt, haben wir unsere Zeit und unser Geld auf ein paar tote Fetzen
Papier verschwendet. Aber nicht alle Dokumente sind bloß Makulatur. So verfassen wir
z.B. definitiv ein Dokument, wenn
쐽 es als Teil des Produkts ausgeliefert wird (als Installationsanweisung, Benutzerhand-
buch usw.),

Überschaubare Dokumentation Dokumentgesteuert


Wenig Formalitäten Volle Nachweisbarkeit
Leichtgewichtiger Prozess Ausgeprägte Formalitäten
Schwergewichtiger Prozess

Wenig Viel
Zeremoniell Zeremoniell

Scrum Scrum in Traditionelle


regulierter dokumentgesteuerte
Umgebung Entwicklung

Abb. 3.17: Der Grad des Zeremoniells

쐽 es unser Ziel ist, eine wichtige Diskussion, Entscheidung oder Vereinbarung festzuhal-
ten, damit wir uns in Zukunft genau daran erinnern können, was diskutiert, entschie-
den oder vereinbart wurde,
쐽 es eine sinnvolle Methode darstellt, um neue Teammitglieder schnellstmöglich einzuar-
beiten,
쐽 es eine regulatorische Anforderung ist, ein bestimmtes Dokument zu schreiben (was
nötig sein könnte, wenn man in einer entsprechend überwachten Branche arbeitet).
Wir versuchen lediglich, Arbeit zu vermeiden, die keinen kurzfristigen oder langfristigen
ökonomischen Wert erbringt. In Scrum glauben wir, dass Zeit und Geld besser investiert
werden, um einen Wert für den Kunden zu erbringen.

3.8 Abschließende Bemerkungen


In diesem Kapitel konzentrierte ich mich darauf, agile Kernprinzipien zu beschreiben – die
grundsätzlichen Vorstellungen, die hinter unserer Arbeit mit Scrum stehen. Dabei verglich
ich, inwieweit sich diese Vorstellungen von denen unterscheiden, die einer lehrbuchmäßi-
gen, traditionellen, plangesteuerten, sequenziellen Entwicklung zugrunde liegen (und in
Tabelle 3.4 zusammengefasst werden).

92
3.8
Abschließende Bemerkungen

Die Zielsetzung dieses Vergleichs bestand nicht darin, Sie davon zu überzeugen, dass das
Wasserfall-Modell schlecht und Scrum gut ist. Vielmehr wollte ich verdeutlichen, dass das
Wasserfall-Modell aufgrund der ihm zugrundeliegenden Überzeugungen für eine andere
Klasse von Problemen geeignet ist als Scrum. Generell bleibt es damit Ihnen selbst überlas-
sen einzuschätzen, welcher Art von Problemen sich Ihre Organisation gegenübersieht und
welches Werkzeug für Sie das passendere ist. Die nachfolgenden Kapitel dieses Buches
beschreiben ausführlich, wie diese Prinzipien einander unterstützen und stärken und
damit einen leistungsstarken Ansatz für die Produktentwicklung liefern.

Thema Plangesteuertes Prinzip Agiles Prinzip


Ähnlichkeit zwischen Ent- Beide folgen einem definier- Die Entwicklung ist keine
wicklung und Herstellung ten Prozess. Herstellung – sie erzeugt die
Rezeptur für das Produkt.
Prozessstruktur Die Entwicklung erfolgt pha- Die Entwicklung sollte itera-
senbasiert und sequenziell. tiv und inkrementell sein.
Grad der Prozess- und Pro- Versucht, Prozess- und Pro- Nutzt die Variabilität durch
duktvariabilität duktvariabilität zu eliminie- Untersuchung, Anpassung
ren. und Transparenz aus.
Umgang mit Unsicherheit Eliminiert zuerst die End- Reduziert alle Unsicherhei-
Unsicherheit und dann die ten gleichzeitig.
Methoden-Unsicherheit.
Entscheidungsfindung Jede Entscheidung wird in Hält Optionen offen.
der dafür vorgesehenen
Phase getroffen.
Es gleich beim ersten Mal Nimmt an, dass wir bereits Wir können es nicht von
richtig machen im Vorfeld über alle korrek- Anfang an richtig machen.
ten Informationen zur
Erstellung von Anforderun-
gen und Plänen verfügen.
Untersuchung versus Aus- Nutzt aus, was momentan Bevorzugt einen adaptiven,
nutzung bekannt ist, und stellt Mut- untersuchenden Ansatz.
maßungen über das an, was
nicht bekannt ist.
Änderung/Emergenz Änderungen stören Pläne Nimmt Änderungen auf
und sind teuer, sie sollten wirtschaftlich vernünftige
deshalb vermieden werden. Weise an.
Prädiktiv versus adaptiv Der Prozess ist stark prädik- Gleicht prädiktive Vorarbeit
tiv. mit adaptiver Just-in-time-
Arbeit aus.
Annahmen (nicht validiertes Der Prozess ist tolerant Validiert wichtige Annah-
Wissen) gegenüber langlebigen men schnell.
Annahmen.
Tabelle 3.4: Vergleichende Zusammenfassung plangesteuerter und agiler Prinzipien

93
Kapitel 3
Agile Prinzipien

Thema Plangesteuertes Prinzip Agiles Prinzip


Feedbacks Entscheidendes Wissen wird Nutzt mehrere gleichzeitige
während einer der großen Lernschleifen aus.
Analysieren-Design-Pro-
grammieren-Testen-Schlei-
fen gewonnen.
Schnelle Feedbacks Der Prozess ist tolerant Organisiert den Arbeitsab-
gegenüber spätem Wissens- lauf für schnelle Feedbacks.
erwerb.
Batch-Größe (wie viel Arbeit Batches sind groß, häufig Nutzt kleinere, wirtschaft-
wird abgeschlossen, bevor 100%. Die Wirtschaftlich- lich vernünftige Batch-Grö-
die nächste Aktivität begin- keit des Maßstabs sollte gel- ßen.
nen kann) ten.
Bestand/Work in Process Der Bestand wird im Erkennt Bestände und orga-
(WIP) zugrundeliegenden Grund- nisiert sie, um einen guten
prinzip nicht berücksichtigt Workflow zu erreichen.
und liegt deshalb nicht im
Fokus.
Personal- versus Arbeitsver- Es wird versucht, ein hohes Konzentriert sich auf unerle-
schwendung Auslastungsniveau des Per- digte Arbeit, nicht auf untä-
sonals zu erreichen. tige Arbeiter.
Kosten der Verzögerung Die Verzögerungskosten Beachtet immer die Verzöge-
werden nur selten beachtet. rungskosten.
Einhaltung des Plans Die Einhaltung wird als ein Adaptiert und plant neu,
wichtiges Mittel zum Errei- anstatt einen Plan einzuhal-
chen eines guten Ergebnis- ten.
ses betrachtet.
Fortschritt Fortschritt wird demonst- Misst den Fortschritt, indem
riert, indem man sich durch funktionierende Güter vali-
Stadien oder Phasen bewegt. diert werden.
Zentriertheit Prozesszentriert – folge dem Wertzentriert – liefere den
Prozess. Wert ab.
Geschwindigkeit Folge dem Prozess, mache Gehe schnell, aber eile nicht.
Dinge gleich beim ersten
Mal richtig und gehe schnell
voran.
Wann bekommen wir hohe Qualität kommt am Ende, Baue gleich von Anfang an
Qualität nach einer umfassenden Qualität ein.
Test-und-Reparaturphase.
Formalität (Zeremonie) Formalität (wohldefinierte Kommt mit minimalem
Prozeduren und Check- Zeremoniell aus.
points) ist für eine effektive
Ausführung wichtig.
Tabelle 3.4: Vergleichende Zusammenfassung plangesteuerter und agiler Prinzipien (Forts.)

94
Kapitel 4

Sprints

Scrum organisiert die Arbeit in Iterationen oder Zyklen von bis zu einem Kalendermonat
Länge, den sogenannten Sprints. In diesem Kapitel schauen wir uns genauer an, was
Sprints eigentlich sind. Wir diskutieren die unterschiedlichen Schlüsseleigenschaften von
Sprints: sie bestehen aus festen Zeiteinheiten – den Timeboxen –, haben eine kurze und
konsistente Zeitdauer, verfolgen ein Ziel, das nicht geändert werden sollte, sobald sie ein-
mal gestartet wurden, und müssen den Endzustand erreichen, der durch die Definition des
Teams von Fertig (»Done«) festgelegt ist.

4.1 Überblick
Sprints bilden das Grundgerüst des Scrum-Frameworks (siehe Abbildung 4.1).

Kurze Dauer
1 Woche bis
Konsistente Länge 1 Kalendermonat
Timeboxed

Sprint 1 Sprint 2 Sprint 3 Sprint 4

Keine das Ziel beein- Vereinbarte


flussenden Änderungen Definition von Fertig

Abb. 4.1: Sprints sind das Grundgerüst des Scrum-Frameworks

95
Kapitel 4
Sprints

Der große graue Hauptpfeil in der Abbildung, der sich vom Product Backlog durch die
gesamte Sprint-Durchführung erstreckt und die Mitglieder des Scrum-Teams einbezieht,
repräsentiert den Sprint. Die anderen Scrum-Artefakte und -Aktivitäten werden entspre-
chend dem relativen Zeitpunkt ihres Auftretens im Sprint angezeigt. Die Sprint-Ausfüh-
rung wird zwar oft mit »dem Sprint« verwechselt, ist aber eigentlich nur eine Aktivität, die
während des Sprints auftritt – neben der Sprint-Planung, dem Sprint Review und der
Sprint-Retrospektive.
Alle Sprints nutzen das sogenannte Timeboxing. Das bedeutet, dass sie feste Anfangs- und
Endzeitpunkte haben. Außerdem müssen Sprints kurz sein, irgendwo zwischen einer
Woche und einem Kalendermonat. Die Länge der Sprints sollte konsistent sein, wobei
unter bestimmten Bedingungen Ausnahmen erlaubt sind. Es gilt die Regel, dass während
eines Sprints keine das Ziel beeinflussenden Änderungen an Umfang oder Personal vorge-
nommen werden dürfen. Und schließlich muss während jedes Sprints ein potenziell aus-
lieferungsfähiges Produktinkrement fertiggestellt werden, das der vom Scrum-Team
vereinbarten Definition von Fertig entspricht. Auch wenn jede Organisation ihre eigene
Implementierung von Scrum benutzen wird, sollten diese Sprint-Charakteristika dennoch
für jeden Sprint und jedes Team gelten. Auf Ausnahmen von dieser Regel werden wir
natürlich auch eingehen. Schauen wir uns nun einmal alle Eigenschaften im Detail an, um
sie besser verstehen zu können.

4.2 Timeboxing
Sprints sind im Konzept des Timeboxing verwurzelt, einer Zeitmanagementtechnik, die
dabei hilft, die Durchführung und den Umfang der Arbeit zu organisieren. Jeder Sprint fin-
det in einem Zeitrahmen mit festen Anfangs- und Endzeitpunkten statt, der als Timebox
bezeichnet wird. Vom Team wird erwartet, innerhalb dieser Timebox mit einer nachhalti-
gen Geschwindigkeit zu arbeiten, um eine festgelegte Arbeitsmenge abzuschließen, die zur
Erreichung des Sprint-Ziels beiträgt.
Das Timeboxing ist aus verschiedenen Gründen wichtig (siehe Abbildung 4.2).

4.2.1 Legt ein WIP-Limit fest


Das Timeboxing ist eine Technik, mit der sich die Menge der in Arbeit befindlichen Ware
(WIP, Work in Process) beschränken lässt. Die WIP repräsentiert einen Bestand an Arbeit,
die zwar begonnen, aber noch nicht abgeschlossen wurde. Wenn man es nicht schafft, die-
sen Bestand anständig zu verwalten und zu organisieren, kann das ernsthafte wirtschaftli-
che Folgen haben. Da das Team nur an den Elementen, von denen es glaubt, dass es sie
innerhalb des Sprints anfangen und beenden kann, zu arbeiten plant, wird durch das Time-
boxing für jeden Sprint ein WIP-Limit etabliert.

4.2.2 Erzwingt eine Priorisierung


Das Timeboxing zwingt uns zu priorisieren und nur die geringe Menge an Arbeit durchzu-
führen, die am wichtigsten ist. Dies setzt unseren Fokus darauf, schnell etwas Werthaltiges
fertigzustellen.

96
4.2
Timeboxing

4.2.3 Demonstriert Fortschritt


Das Timeboxing hilft uns auch dabei, relevanten Fortschritt zu demonstrieren, indem zu
einem bekannten Zeitpunkt (dem Ende des Sprints) wichtige Teile der Arbeit abgeschlos-
sen und validiert werden. Diese Art von Fortschritt verringert das organisatorische Risiko,
indem der Blick von unzuverlässigen Formen der Fortschrittsinformation, wie etwa der
Konformität mit einem Plan, weggelenkt wird. Das Timeboxing hilft uns außerdem, den
Fortschritt in Bezug auf große Funktionen zu demonstrieren, die mehr als eine Timebox
zur Fertigstellung benötigen. Indem man einen Teil der Arbeit für diese Funktionen
abschließt, stellt man sicher, dass in jedem Sprint werthaltiger, messbarer Fortschritt erzielt
wird. Die Stakeholder und das Team können auf diese Weise exakt in Erfahrung bringen,
was noch getan werden muss, um die gesamte Funktion auszuliefern.

Legt ein WIP-Limit fest

Erzwingt eine Priorisierung

Demonstriert Fortschritt

Timeboxing-Vorteile

Verhindert unnötigen Perfektionismus

Motiviert die Fertigstellung

Verbessert die Vorhersagbarkeit

Abb. 4.2: Die Vorteile des Timeboxing

4.2.4 Verhindert unnötigen Perfektionismus


Das Timeboxing hilft dabei, unnötigen Perfektionismus zu vermeiden. Irgendwann einmal
haben wir doch alle schon mal zu viel Zeit damit zugebracht, etwas »perfekt« hinzubekom-
men, obwohl »gut genug« völlig ausgereicht hätte. Das Timeboxing erzwingt ein Ende für
potenziell unbegrenzte Arbeit, indem ein fester Endzeitpunkt festgelegt wird, bis zu dem
eine gute Lösung gefunden werden muss.

4.2.5 Motiviert die Fertigstellung


Das Timeboxing motiviert außerdem die Fertigstellung. Ich habe die Erfahrung gemacht,
dass Dinge viel wahrscheinlicher rechtzeitig fertiggestellt werden, wenn die Teams den
Endzeitpunkt kennen. Die Tatsache, dass das Ende des Sprints eine harte Deadline mit sich

97
Kapitel 4
Sprints

bringt, regt die Mitglieder des Teams an, sich unermüdlich zu bemühen, die Arbeit pünkt-
lich abzuschließen. Ohne einen bekannten Endtermin wirkt die Arbeit auf einmal gar nicht
mehr so dringend.

4.2.6 Verbessert die Vorhersagbarkeit


Das Timeboxing verbessert die Vorhersagbarkeit. Wir können zwar nicht mit allzu großer
Sicherheit prophezeien, welche Arbeit wir nun genau in einem Jahr abgeschlossen haben
werden, aber es ist völlig vernünftig anzunehmen, dass wir vorhersehen können, was wir
im nächsten kurzen Sprint schaffen.

4.3 Kurze Zeitdauer


Kurze Sprints bringen viele Vorteile mit sich (siehe Abbildung 4.3).

Erleichterte Planung

Schnelles Feedback

Begrenzte Fehler

Vorteile einer kurzen Dauer

Verbesserter Return on Investment

Wiedererweckte Begeisterung

Häufige Checkpoints

Abb. 4.3: Die Vorteile kurzer Sprints

4.3.1 Erleichterte Planung


Kurze Sprints erleichtern die Planung. Es ist einfacher, die Arbeit für mehrere Wochen zu
planen, als die Arbeit für das nächste halbe Jahr. Die Planung solcher kurzen Zeitspannen
ist außerdem weniger aufwendig und dabei viel genauer als die Planung für einen längeren
Zeitraum.

98
4.3
Kurze Zeitdauer

4.3.2 Schnelles Feedback


Kurze Sprints generieren schnelles Feedback. Während jedes Sprints erzeugen wir funktio-
nierende Software. Danach haben wir die Möglichkeit, das, was wir gebaut haben und wie
wir es gebaut haben, zu überprüfen und zu ändern. Dieses schnelle Feedback erlaubt es
uns, ungünstige Produktpfade oder Entwicklungsansätze schnell wieder aufzugeben, bevor
wir eine schlechte Entscheidung mit vielen nachfolgenden Entscheidungen koppeln, die
auf darauf aufbauen. Darüber hinaus können wir aufgrund der schnellen Rückmeldungen
sich ergebende zeitkritische Möglichkeiten zügig aufdecken und ausnutzen.

4.3.3 Verbesserter Return on Investment


Kurze Sprints verbessern dank der schnellen Feedbacks nicht nur die Wirtschaftlichkeit,
sondern fördern auch frühzeitige und häufigere Auslieferungen. In der Folge generieren
wir bereits früher einen Gewinn, was den gesamten Return on Investment verbessert (ein
Beispiel hierzu finden Sie in Kapitel 14).

4.3.4 Begrenzte Fehler


Kurze Sprints schränken das Fehlerpotenzial ein. Wie falsch können wir in einem zweiwö-
chigen Sprint liegen? Selbst wenn wir die ganze Sache in den Sand setzen, haben wir nur
zwei Wochen verloren. Wir bestehen auf kurzen Sprints, weil wir uns dadurch häufig koor-
dinieren müssen und mehr Feedbacks erhalten. Und sollten doch einmal Fehler vorkom-
men, zieht das wenigstens keine allzu schwerwiegenden Konsequenzen nach sich.

4.3.5 Wiedererweckte Begeisterung


Kurze Sprints helfen dabei, die Begeisterung für die Sache wieder zum Leben zu erwecken.
Es liegt in der menschlichen Natur, dass das Interesse und die Begeisterung für eine Tätig-
keit nachlassen, je länger wir auf die »Belohnung« bzw. Anerkennung warten müssen
(siehe Abbildung 4.4).
Wenn sich die Arbeit an einem Projekt sehr lange hinzieht, besteht nicht nur eine höhere
Wahrscheinlichkeit, dass wir damit scheitern, sondern wir werden aller Voraussicht nach
auch schneller den Enthusiasmus für die Arbeit verlieren. (Als ich bei IBM arbeitete, nann-
ten wir diese Projekte »den Ozean aufkochen«, weil es viel Zeit und Mühe kostete, sie fer-
tigzustellen, sofern man es überhaupt schaffte – fast so, als wollte man versuchen, den
Ozean zum Kochen zu bringen.) Wenn weder Fortschritt noch Ende in Sicht sind, verlieren
die Beteiligten nach und nach das Interesse an der Sache und würden zum Ende hin fast
alles dafür geben, um an einem anderen Produkt arbeiten zu dürfen!
Kurze Sprints halten dagegen die Begeisterung der Beteiligten durch häufigere Ausliefe-
rungen funktionierender Teilbestände wach. Die Belohnung bzw. Anerkennung, die frühe
und häufige Auslieferungen mit sich bringen, erweckt die Begeisterung und das Interesse
an der Sache wieder zum Leben und wir sind weiterhin gewillt, auf das Ziel zuzuarbeiten.

99
Kapitel 4
Sprints

Begeisterung
Den Ozean
aufkochen

Begeisterung Zeit

Inkrementelle
Releases
kurzer Dauer

Zeit

Abb. 4.4: Begeisterungsspanne über den Projektzeitraum hinweg

4.3.6 Häufige Checkpoints


Kurze Sprints gewährleisten mehrere maßgebliche Checkpoints (siehe Abbildung 4.5).

Wasserfall-Checkpoints
Analyse

Design

Programmierung

Tests

Betrieb

Scrum-Checkpoints

Abb. 4.5: Vergleich der Checkpoints

100
4.4
Konsistente Dauer

Ein geschätzter Aspekt von nach dem sequenziellen Entwicklungsverfahren durchgeführ-


ten Projekten ist der Umstand, dass es eine wohldefinierte Menge an Meilensteinen
(»Milestones«) gibt. Diese Meilensteine umfassen auch bestimmte Checkpoints, die übli-
cherweise an Finanzierungsentscheidungen des Managements für die nächste Phase
gekoppelt sind. Wie ich bereits in Kapitel 3 ausgeführt habe, sind diese Meilensteine aus
regulatorischer Sicht potenziell recht nützlich, dennoch liefern sie nur sehr unzuverlässige
Anhaltspunkte über den wahren Status der erzielten Werte für den Kunden.
Scrum bietet Managern, Stakeholdern, Product Ownern und anderen hingegen deutlich
mehr Checkpoints als das sequenzielle Entwicklungsverfahren. Am Ende jedes kurzen
Sprints steht ein wichtiger Checkpoint (Sprint Review), der es allen Beteiligten ermöglicht,
ihre Entscheidungen anhand von demonstrier- und durchführbaren Funktionen zu treffen.
Generell sind Menschen besser in der Lage, mit einer komplexen Umgebung zurechtzu-
kommen, je mehr nachvollziehbare Checkpoint-Gelegenheiten ihnen zum Überprüfen
und Anpassen geboten werden.

4.4 Konsistente Dauer


Das Team sollte für jedes Entwicklungsprojekt jeweils eine konsistente Sprint-Dauer
bestimmen, die – einmal festgelegt – nur dann geändert wird, wenn es einen wirklich
zwingenden Grund dafür gibt, wie z.B.:
쐽 Möglicherweise wäre es sinnvoll, zwecks Generierung häufigerer Feedbacks von vier-
wöchigen auf zweiwöchige Sprints zu wechseln. Zunächst sollen aber einige zweiwö-
chige Sprints ausprobiert werden, bevor eine endgültige Entscheidung fällt.
쐽 Unter Berücksichtigung der jährlichen Feriensaison oder des Endes des Finanzjahres
erscheint es praktischer, zu diesen Zeitpunkten jeweils einen dreiwöchigen Sprint
durchzuführen als den üblichen zweiwöchigen Sprint.
쐽 Die Freigabe des Produkts erfolgt bereits in einer Woche, so dass ein zweiwöchiger
Sprint relativ sinnlos wäre.
Die Tatsache, dass das Team seine Arbeit innerhalb der aktuell festgelegten Sprint-Länge
nicht schafft, würde dagegen keinen zwingenden Grund für die Verlängerung der Sprint-
Dauer darstellen. Nicht tolerierbar ist auch, wenn bis zum letzten Tag des Sprints gewartet
wird, um festzustellen, dass man nicht fertig wird, und dies dann zum Anlass genommen
wird, um sich für einen zusätzlichen Tag oder gar eine ganze zusätzliche Woche einzuset-
zen. Solche Fälle sind vielmehr symptomatisch dafür, dass etwas schiefläuft und die
Arbeitsabläufe verbessert werden müssen, aber keine zwingenden Gründe, um die Sprint-
Dauer zu ändern.
Wenn sich ein Team für zweiwöchige Sprints entscheidet, dann sollten auch wirklich alle
Sprints zwei Wochen dauern. Bei den meisten (aber nicht bei allen) Teams bedeuten zwei
Wochen übrigens zehn Wochentage. Fällt ein Feiertag in den Sprint oder findet während-
dessen ein Training statt, reduziert dies zwar die Kapazität des Teams für diesen einen
Sprint, eine generelle Änderung der Sprint-Länge ist deswegen aber nicht erforderlich.
Nutzt man immer dieselbe Sprint-Länge, dann macht man sich die Vorteile der Kadenz
zunutze und vereinfacht die Planung.

101
Kapitel 4
Sprints

4.4.1 Vorteile der Kadenz


Sprints derselben Dauer liefern uns eine Kadenz – einen regelmäßigen, vorhersehbaren
Rhythmus oder »Herzschlag« für die Scrum-Entwicklung. Ein stetiger, gesunder Herz-
schlag erlaubt es dem Scrum-Team und der Organisation, ein Gefühl dafür zu entwickeln,
wann Dinge geschehen müssen, um einen schnellen, flexiblen Flow des Geschäftswertes
(Business Value) zu erreichen. Meiner Erfahrung nach haben die Leute bei einer regel-
mäßigen Kadenz die Möglichkeit, »in den richtigen Tritt zu kommen«. Ich glaube, das
geschieht, weil ein regelmäßiger Rhythmus die gewöhnlichen, aber notwendigen Aktivi-
täten zur Gewohnheit werden lässt, wodurch mentale Kapazitäten frei werden, um sich auf
die wirklich interessanten Arbeiten zu konzentrieren.
Mit einer kurzen Sprint-Kadenz wird außerdem die Intensität der Arbeit ausgeglichen. Im
Gegensatz zu traditionellen, sequenziellen Projekten, bei denen wir in späteren Phasen
eine steile Zunahme der Intensität beobachten, besitzt jeder Sprint ein Intensitätsprofil,
das dem anderer Sprints ähnelt. Wie ich in Kapitel 11 zeigen werde, gestattet die Sprint-
Kadenz dem Team, in einer nachhaltigen Geschwindigkeit zu arbeiten.
»Sprintet« man mit einer gleichmäßigen Kadenz, verringert sich der Aufwand für die Koor-
dination ganz beträchtlich. Bei Sprints fester Länge können wir solche Aktivitäten wie
Sprint-Planung, Sprint Review und Sprint-Retrospektive für viele Sprints gleichzeitig pla-
nen. Und da jeder weiß, wann diese Aktivitäten dran sind, ist der Aufwand für die zeitliche
Planung auch für viele Sprints nur gering.
Ein Beispiel: Wenn wir bei einer Entwicklung, die ein Jahr dauern soll, zweiwöchige
Sprints durchführen, können wir das sich wiederholende Ereignis der nächsten 26 Sprint
Reviews in alle Kalender eintragen. Würden wir es zulassen, dass sich die Länge der Sprints
ständig ändert, wäre der Aufwand für die Koordination viel höher. Stellen Sie sich nur ein-
mal vor, Sie hätten lediglich zwei Wochen Vorlauf, um die Stakeholder zu informieren,
deren Terminkalender mit hoher Wahrscheinlichkeit schon für viele Wochen im Voraus
gefüllt sind!
Arbeiten schließlich mehrere Teams am selben Projekt, dann erlaubt eine ähnliche Kadenz
für alle Teams eine relativ einfache Synchronisation der Arbeit über Teamgrenzen hinweg
(mehr dazu in Kapitel 12).

4.4.2 Vereinfacht die Planung


Eine konsistente Sprint-Dauer vereinfacht die Planungsaktivitäten. Wenn alle Sprints
gleich lang sind (selbst wenn die Kapazität pro Sprint wegen eines Feiertags oder Ähnli-
chem um einen oder mehrere Tage reduziert ist), gewöhnt sich das Team an die Menge an
Arbeit, die es in einem typischen Sprint schaffen kann (als Entwicklungsgeschwindigkeit
oder Velocity bezeichnet). Die Velocity ist typischerweise für einen Sprint genormt. Würde
die Länge des Sprints variieren, könnten wir eigentlich keine genormten Sprint-Einheiten
haben. Es wäre sinnlos, so etwas zu sagen wie: »Das Team hat eine durchschnittliche Velo-
city von 20 Punkten pro Sprint«.
Es ist zwar sicher irgendwie möglich, die Velocity eines Teams auch dann zu berechnen,
wenn es Sprints variabler Länge nutzt, allerdings ist das komplizierter. Bleiben wir dagegen
bei einer konsistenten Sprint-Dauer, vereinfachen wir die Berechnungen mit den bisheri-
gen Velocity-Daten des Teams.

102
4.5
Keine das Ziel beeinflussenden Änderungen

Eine konsistente Sprint-Dauer vereinfacht auch die restlichen Planungsberechnungen.


Arbeiten wir z.B. mit einem Release mit festem Termin und haben konsistente Sprint-Län-
gen, dann müssen wir für die Berechnung der Anzahl der Sprints einfach einen Blick in
den Kalender werfen (wir kennen das heutige Datum, wir wissen, wann wir fertig sein
müssen, und wir wissen, dass alle Sprints gleich lang sind). Dürften die Sprint-Längen vari-
ieren, dann wäre die Berechnung der Anzahl der Sprints in diesem Projekt eine deutlich
größere Herausforderung (weil wir bereits früh sehr umfangreich planen müssten), unnö-
tig aufwendig und würde vermutlich keine zuverlässigen Ergebnisse liefern.

4.5 Keine das Ziel beeinflussenden Änderungen


Eine wichtige Scrum-Regel besagt, dass keine Änderung erlaubt ist, die das Sprint-Ziel
wesentlich beeinflussen kann, sobald dieses erst einmal festgelegt wurde und die Ausfüh-
rung des Sprints begonnen hat.

4.5.1 Was ist ein Sprint-Ziel?


Jeder Sprint kann in einem Sprint-Ziel zusammengefasst werden, das den Geschäftszweck
und den Wert des Sprints beschreibt. Das Sprint-Ziel besitzt typischerweise einen einzigen,
klaren Fokus, wie etwa:
쐽 Unterstützen der initialen Generierung eines Reports,
쐽 Laden und Aufbereiten der Kartendaten von Nordamerika,
쐽 Demonstrieren der Fähigkeit, eine Textnachricht über einen integrierten Software-,
Firmware- und Hardware-Stack zu senden.
Manchmal kann das Sprint-Ziel jedoch auch mehrere Aspekte aufweisen: »Das einfache
Drucken zum Laufen bringen und die Suche nach dem Datum unterstützen.«
Während der Sprint-Planung sollte das Entwicklungsteam mithelfen, das Sprint-Ziel zu
verfeinern und abzustimmen und es benutzen, um die Elemente des Product Backlogs zu
bestimmen, die es zum Ende des Sprints abschließen kann (mehr dazu in Kapitel 19).
Diese Backlog-Elemente dienen dazu, das Sprint-Ziel näher zu beschreiben.

4.5.2 Gegenseitige Verpflichtung


Das Sprint-Ziel ist die Grundlage einer gegenseitigen Verpflichtung durch das Team und
den Product Owner: Das Team verpflichtet sich dazu, am Ende des Sprints das Ziel zu
erfüllen, der Product Owner wiederum verpflichtet sich, das Ziel während des Sprints nicht
zu verändern.
Diese gegenseitige Verpflichtung demonstriert die Bedeutung, die der Sprint besitzt: Einer-
seits muss das Unternehmen flexibel gegenüber Änderungen sein, andererseits soll dem
Team erlaubt werden, sich zu konzentrieren und seine Talente effizient einzusetzen, um
während einer kurzen, begrenzten Dauer einen Wert zu schaffen. Indem das Scrum-Team
ein Sprint-Ziel definiert und sich daran hält, kann es auf ein definiertes, werthaltiges Ziel
fokussiert bleiben.

103
Kapitel 4
Sprints

4.5.3 Änderungen versus Klärung


Das Sprint-Ziel sollte zwar nicht grundlegend geändert werden, es ist aber zulässig, es zu
erläutern. Den Unterschied werde ich nachfolgend genauer erklären.
Was zeichnet eine Änderung aus? Eine Änderung bedeutet jeden Wechsel in Arbeit oder
Ressourcen, die das Potenzial besitzt, eine wirtschaftlich bedeutsame Verschwendung nach
sich zu ziehen, den Workflow beträchtlich zu stören oder den Umfang der Arbeit innerhalb
eines Sprints wesentlich zu vergrößern. Das würde z.B. bedeuten, dass man ein Element
aus dem Product Backlog entfernt oder zu ihm hinzufügt oder den Umfang eines solchen
Elements, das bereits in dem Sprint bearbeitet wird, signifikant ändert. Das folgende Bei-
spiel verdeutlicht eine Änderung:
Product Owner: »Oh, als ich sagte, dass wir in der Lage sein müssen, die Polizeidaten-
bank nach einem jugendlichen Straftäter zu durchsuchen, da meinte ich nicht nur nach
Nachnamen und Vornamen, sondern auch nach einer Abbildung der Tätowierungen
des Verdächtigen.«
Die zusätzliche Fähigkeit, auch anhand eines Bildes in der Datenbank zu suchen, bedeutet
wahrscheinlich einen deutlich höheren Aufwand und würde mit Sicherheit die Fähigkeit
des Teams beeinflussen, die Verpflichtung zu erfüllen, eine Suche nach dem Vor- und
Nachnamen abzuliefern. In diesem Fall sollte der Product Owner es lieber in Betracht zie-
hen, ein neues Element für das Product Backlog anzulegen, das die Funktion »Bildsuche«
umfasst und in einem späteren Sprint bearbeitet wird.
Und was zeichnet eine Klärung aus? Klärungen sind zusätzliche Details, die während des
Sprints zur Verfügung gestellt werden und dem Team helfen, das Sprint-Ziel zu erreichen.
Wie ich in Kapitel 5 diskutieren werde, sind am Anfang eines Sprints möglicherweise nicht
alle die Elemente des Product Backlogs betreffenden Einzelheiten vollständig bekannt oder
festgelegt. Deshalb ist es absolut vernünftig, wenn das Team während eines Sprints klä-
rende Fragen stellt und der Product Owner diese Fragen beantwortet. Das folgende Beispiel
verdeutlicht eine Klärung:
Entwicklungsteam: »Als Sie gesagt haben, dass die Treffer für die Suche nach einem
jugendlichen Straftäter in einer Liste dargestellt werden sollen, haben Sie da auch
gesagt, wie die Liste sortiert werden soll?«
Product Owner: »Sortiert sie bitte alphabetisch nach dem Nachnamen.«
Entwicklungsteam: »Okay, das geht.«
Der Product Owner kann und sollte auf diese Weise während des Sprints für Klärung sorgen.

4.5.4 Konsequenzen einer Änderung


Es sieht vielleicht so aus, als würde die Regel, dass keine Änderung erfolgen darf, in direk-
tem Widerspruch zu dem Scrum-Prinzip stehen, dass wir Änderungen annehmen sollen.
Wir nehmen Änderungen ja an, allerdings wollen wir das auf ausgeglichene, wirtschaftlich
sinnvolle Weise tun.
Die wirtschaftlichen Konsequenzen einer Änderung werden immer größer, je mehr wir
schon in die geänderte Arbeit investiert haben (siehe Abbildung 4.6).

104
4.5
Keine das Ziel beeinflussenden Änderungen

Wir investieren in Elemente des Product Backlogs, um sie für die Bearbeitung in einem
Sprint vorzubereiten. Sobald jedoch ein Sprint beginnt, hat unsere Investition in diese Pro-
duct-Backlog-Elemente zugenommen (weil wir während der Sprint-Planung Zeit damit
zugebracht haben, sie auf Aufgabenebene zu diskutieren und zu planen). Falls wir nach der
Sprint-Planung eine Änderung vornehmen wollen, dann gefährden wir nicht nur die Pla-
nungsinvestition, sondern verursachen auch noch zusätzliche Kosten, weil wir für die
Änderungen während des Sprints neue Pläne schaffen müssen.
Kumulatives Investment

Bereit Noch zu tun In Arbeit Fertig


(Pflege) (Sprint-Planung)
Abb. 4.6: Kumulatives Investment in verschiedenen Stadien

Sobald wir mit der Ausführung eines Sprints beginnen, steigert sich unsere Investition in
die Arbeit sogar noch weiter, da immer mehr Elemente des Product Backlogs durch die
Zustände »Noch zu erledigen« (Arbeit, die noch nicht begonnen wurde), »Wird erledigt«
(Ware in Arbeit) und »Fertig« (Arbeit abgeschlossen) läuft.
Nehmen wir einmal an, wir wollen Funktion X, die momentan Teil der Sprint-Verpflich-
tung ist, durch Funktion Y ersetzen, die zurzeit nicht in der Sprint-Verpflichtung enthalten
ist. Selbst wenn wir noch nicht begonnen haben, an Funktion X zu arbeiten, verursachen
wir eine Verschwendung von Planungsarbeiten. Funktion X könnte darüber hinaus Abhän-
gigkeiten zu anderen Funktionen im Sprint haben, so dass eine Änderung, die Funktion X
beeinflusst, auch Auswirkungen auf andere Funktionen haben könnte. Das verstärkt den
Einfluss auf das Sprint-Ziel.
Falls die Arbeit an Funktion X bereits begonnen hat, kommen neben der schon erwähnten
noch weitere mögliche Verschwendungen hinzu. So muss möglicherweise die gesamte
Arbeit, die schon an Funktion X durchgeführt wurde, weggeworfen werden. Und wir haben
vielleicht die zusätzliche Verschwendung, dass wir die teilweise fertiggestellte Arbeit an
Funktion X entfernen müssen, die wir in Zukunft vermutlich nie benutzen werden (wir

105
Kapitel 4
Sprints

werden am Ende des Sprints keine teilweise beendete Arbeit in ein potenziell ausliefe-
rungsfähiges Produktinkrement einbauen).
Sollte Funktion X zudem bereits abgeschlossen sein, haben wir natürlich die komplette
Investition in Funktion X verschwendet. Der Schaden wächst also immer weiter!
Die Verschwendung betrifft jedoch nicht nur die unmittelbar wirtschaftlich messbaren
Konsequenzen – sie wirkt sich auch auf die Motivation des Teams und die Zuversicht, die
mit einer Änderung einhergeht. Wenn der Product Owner sich verpflichtet, das Ziel nicht
zu ändern, und diese Verpflichtung dann bricht, wird das Team natürlich demotiviert, was
sich mit hoher Wahrscheinlichkeit auf seinen Eifer auswirkt, andere Elemente des Product
Backlogs fertigzustellen. Darüber hinaus könnte auch die Zuversicht innerhalb des Scrum-
Teams leiden, weil das Entwicklungsteam nicht mehr daran glaubt, dass der Product
Owner sich an seine Verpflichtungen hält.

4.5.5 Pragmatisch sein


Die Keine-Zieländerung-Regel ist genau das – eine Regel, kein Gesetz. Das Scrum-Team
muss pragmatisch sein.
Was ist, wenn sich die Geschäftsbedingungen auf eine Weise ändern, die eine Änderung
des Sprint-Ziels gerechtfertigt erscheinen lassen? Sagen wir mal, ein Konkurrent bringt
während unseres Sprints sein neues Produkt heraus. Nach einer Untersuchung des neuen
Produkts stellen wir fest, dass wir das Ziel, das wir für den aktuellen Sprint vorgesehen hat-
ten, ändern müssen, weil unsere Arbeit offenbar nicht mit der des Konkurrenten mithalten
kann. Sollten wir blind der Regel folgen, dass keine das Ziel beeinflussenden Änderungen
vorgenommen werden dürfen? Vermutlich nicht.
Was ist, wenn ein wichtiges Produktionssystem jämmerlich versagt hat und Leute aus
unserem Team (einige oder sogar alle) dies reparieren können? Sollten wir nicht unseren
aktuellen Sprint unterbrechen, um auszuhelfen? Sagen wir dem Unternehmen, dass wir
den Schaden in der Produktion sofort nach dem nächsten Sprint reparieren werden? Ver-
mutlich nicht.
Am Ende ist es besser, pragmatisch zu sein, als sich sklavisch an die Keine-Änderung-Regel
zu halten. Wir müssen auf wirtschaftlich sinnvolle Weise handeln. Jeder im Scrum-Team
weiß das zu schätzen. Wenn wir den aktuellen Sprint ändern, werden wir die bereits disku-
tierten negativen wirtschaftlichen Auswirkungen spüren. Falls jedoch die wirtschaftlichen
Konsequenzen der Änderung deutlich geringer sind als die wirtschaftlichen Konsequenzen
des Verzichts auf eine Änderung, dann ist das Ändern eine kluge geschäftliche Entschei-
dung. Sind die wirtschaftlichen Auswirkungen bei beiden Entscheidungen ähnlich, sollten
Sie keine Änderung am Sprint-Ziel vornehmen.
In Bezug auf die Motivation und das Vertrauen des Teams habe ich die Erfahrung gemacht,
dass die meisten Teams bei einer offenen und auf die wirtschaftlichen Aspekte fokussierten
Diskussion des Product Owners mit dem Team über die Notwendigkeit einer Änderung
Verständnis für die Entscheidung zeigen. Motivation und Vertrauen werden also nicht
beschädigt.

106
4.5
Keine das Ziel beeinflussenden Änderungen

4.5.6 Abnormaler Abbruch


Sollte das Sprint-Ziel vollkommen ungültig werden, könnte das Scrum-Team zu dem
Schluss kommen, dass es sinnlos wäre, den aktuellen Sprint fortzusetzen, und dem Pro-
duct Owner raten, den Sprint vorzeitig, sozusagen außer der Reihe abzubrechen. Der aktu-
elle Sprint wird in diesem Fall sofort beendet und das Scrum-Team versammelt sich zu
einer Sprint-Retrospektive. Anschließend trifft sich das Team mit dem Product Owner, um
den nächsten Sprint zu planen – mit einem anderen Sprint-Ziel und anderen Elementen
aus dem Product Backlog.
Ein Sprint-Abbruch ist dann sinnvoll, wenn ein wirtschaftlich bedeutsames Ereignis einge-
treten ist, das den Sprint ungültig werden lässt (wie etwa irgendwelche Aktionen eines Kon-
kurrenten), oder wenn sich die Finanzierung des Produkts grundlegend geändert hat.
Obwohl sich Product Owner zwar das Recht vorbehalten, jeden Sprint einfach abzubre-
chen, kommt es meiner Erfahrung nach nur selten vor, dass sie auch tatsächlich davon
Gebrauch machen. Häufig kann das Scrum-Team deutlich weniger dramatische Maßnah-
men ergreifen, um der Situation wieder Herr zu werden. Vergessen Sie nicht: Sprints sind
kurz – und üblicherweise hat das Team einen Sprint bereits zur Hälfte hinter sich gebracht,
wenn eine Situation eintritt, die nach einer Änderung ruft. Da somit oftmals nur eine
Woche oder weniger Zeit bleibt, ist es wirtschaftlich meist nicht sinnvoll, den Sprint abzu-
brechen. Und in vielen Fällen lässt sich die Situation durch eine weniger drastische Ände-
rung retten, etwa indem man eine Funktion aufgibt, so dass Zeit bleibt, andere Schäden
abzuwenden.
Generell gilt es hierbei zu berücksichtigen, dass ein vorzeitiger Abbruch eines Sprints nicht
nur einen negativen Einfluss auf die Moral hat, sondern auch eine ernsthafte Unterbre-
chung des schnellen, flexiblen Funktions-Flows nach sich zieht und viele der erwähnten
Vorteile von Sprints mit einer konsistenten Zeitdauer negiert. Der Abbruch eines Sprints
sollte daher immer der letzte Ausweg sein.
Falls ein Sprint abgebrochen wurde, muss das Scrum-Team die Länge des nächsten Sprints
festlegen (siehe Abbildung 4.7).

Option 1

Option 2

Option 3

Abb. 4.7: Nach Abschluss eines Sprints über die nächste Sprint-Dauer entscheiden

107
Kapitel 4
Sprints

Hier bieten sich drei offensichtliche Möglichkeiten an:


1. Man belässt es bei der ursprünglichen Sprint-Länge. Dies hat den Vorteil, dass man
während der gesamten Entwicklung eine einheitliche Sprint-Länge beibehält (natürlich
abgesehen von dem abgebrochenen Sprint). Wenn mehrere Scrum-Teams an derselben
Entwicklung arbeiten, dann bleibt das Scrum-Team, das den Sprint abgebrochen hat,
mit den anderen Teams synchron.
2. Man legt die Länge des nächsten Sprints nur bis zum Enddatum des abgebrochenen
Sprints fest. Sollte das Scrum-Team z.B. einen zweiwöchigen Sprint am Ende der ersten
Woche abgebrochen haben, würde der nächste Sprint dann nur eine Woche dauern,
damit das Team wieder in seine ursprüngliche Sprint-Kadenz zurückkehrt.
3. Man macht den nächsten Sprint länger als einen normalen Sprint, um die verbleibende
Zeit des abgebrochenen Sprints sowie die Zeit für den nächsten vollständigen Sprint
abzudecken. Um das vorherige Beispiel noch mal aufzugreifen: Der nächste Sprint
würde hier drei Wochen dauern, damit das Team wieder in seine ursprüngliche Sprint-
Kadenz zurückkehrt.
Bei einem Entwicklungsprojekt mit mehreren Teams würde man sich für Möglichkeit 2
oder 3 entscheiden. In allen Fällen müssen Sie Ihren speziellen Kontext in Betracht ziehen,
um herauszufinden, welche Entscheidung am besten ist.

4.6 Definition von Fertig (Done)


Wie ich in Kapitel 2 erläutert habe, sollte das Ergebnis eines jeden Sprints ein potenziell
auslieferungsfähiges Produktinkrement sein. Ich erwähnte außerdem, dass »potenziell
auslieferungsfähig« nicht heißt, dass das, was gebaut wurde, auch tatsächlich ausgeliefert
werden muss. Die Auslieferung ist eine Geschäftsentscheidung, die oft in einem anderen
Rhythmus verläuft – in manchen Organisationen ist es möglicherweise nicht sinnvoll, am
Ende jedes Sprints auszuliefern.
Stellen Sie sich potenziell auslieferungsfähig lieber als einen Grad der Zuversichtlichkeit
vor, dass das, was im Sprint gebaut wurde, auch tatsächlich fertig ist. Das heißt, es wurden
keine grundlegend wichtigen Arbeiten unerledigt gelassen (wie etwa wichtige Tests oder
Integration usw.), die abgeschlossen sein müssten, bevor wir die Ergebnisse des Sprints
ausliefern könnten, falls dies unser Ziel wäre. Um festzustellen, ob das Produkt potenziell
auslieferungsfähig ist, braucht das Scrum-Team eine gute, gemeinschaftlich festgelegte
Definition von Fertig (Done).

4.6.1 Wie lautet die Definition von Fertig?


Konzeptuell besteht die Definition von Fertig in einer Checkliste all der Arbeiten, die das
Team erfolgreich abschließen muss, bevor es seine Arbeit für potenziell auslieferungsfähig
erklären kann (siehe Tabelle 4.1).
Die speziellen Elemente auf der Checkliste hängen ganz offensichtlich von einer Reihe von
Variablen ab:
쐽 der Natur des zu bauenden Produkts,
쐽 den zum Bauen verwendeten Technologien,

108
4.6
Definition von Fertig (Done)

쐽 der Organisation, die es baut,


쐽 den aktuellen Hindernissen, die beeinflussen, was möglich ist.

Meist wird es so sein, dass eine Minimaldefinition von Fertig ein komplettes Stück Pro-
duktfunktionalität ergibt – eins, das entworfen, gebaut, integriert, getestet und dokumen-
tiert wurde und nachweislich einen Wert für den Kunden erbringt. Für eine sinnvolle
Checkliste müssen diese relativ groben Elemente jedoch weiter verfeinert werden. Was
bedeutet z.B. getestet? Ein Unit Test? Integrationsgetestet? Systemgetestet? Plattformgetes-
tet? Internationalisierung getestet? Sie können sich sicher noch viele andere Formen des
Testens vorstellen, die auf Ihr Produkt zutreffen. Sind all Testvarianten in Ihrer Definition
von Fertig enthalten?

Definition von »Fertig«


S Design überprüft

S Code abgeschlossen
Code restrukturiert
Code in Standardformat
Code ist kommentiert
Code ist eingecheckt
Code ist überprüft
S Endanwenderdokumentation aktualisiert

S Getestet
Unit Test durchgeführt
Integration getestet
Regression getestet
Plattform getestet
Sprache getestet
S Keine bekannten Fehlfunktionen

S Akzeptanz getestet

S Live auf Produktionsservern

Tabelle 4.1: Beispiel-Checkliste für die Definition von »Fertig«

Denken Sie daran: Wenn Sie die wichtigen Tests (z.B. Leistungstests) nicht während jedes
Sprints durchführen, werden Sie sie irgendwann einmal nachholen müssen. Haben Sie
vielleicht vor, die Leistung zu irgendeinem zukünftigen Zeitpunkt in einem eigenen Sprint
testen? Wenn dem so ist, haben Sie definitiv nicht nach jedem Sprint ein potenziell auslie-
ferungsfähiges Produktinkrement zur Verfügung, denn Leistungstests sind für den
Zustand »Fertig« unerlässlich. Was aber noch schlimmer ist: Wenn Sie dann tatsächlich
erst später einen Leistungstest durchführen und dieser nicht wie geplant verläuft, sind Sie
nicht nur in einem sehr fortgeschrittenen Stadium der Entwicklung mit einem ernsten
Problem konfrontiert, sondern müssen auch mehr Zeit und Geld aufwenden, um dieses
Problem zu beheben, als wenn Sie den Leistungstest früher durchgeführt hätten.

109
Kapitel 4
Sprints

Manchmal dauern die Tests länger als ein Sprint. Sollte dies der Fall sein, weil das Entwick-
lungsteam bislang viele manuelle Tests schuldig geblieben ist, dann müssen die Tests auto-
matisiert werden, damit sie innerhalb eines Sprints beendet werden können. Sollte die
längere Ausführungsdauer hingegen in der Art des Tests begründet sein, dann müssen wir
akzeptieren, dass es nötig ist, ihn in einem Sprint zu beginnen und in einem künftigen
Sprint zu beenden. So baute z.B. eine Organisation, in der ich als Trainer tätig war, ein
Gerät, das aus Hardware, Firmware und Software bestand. Einer ihrer Standardtests
bestand in einem 1.500 Stunden andauernden Dauertest, um festzustellen, ob das Gerät
über diese Zeitspanne hinweg durchhalten würde. Ein solcher Test kann natürlich nicht
innerhalb eines zweiwöchigen Sprints abgeschlossen werden, deshalb passte das Scrum-
Team die Definition von Fertig entsprechend an: Ein Sprint konnte auch dann als beendet
betrachtet werden, wenn der 1.500-Stunden-Test noch nicht abgeschlossen worden war.
Oft werde ich gefragt: »Was ist, wenn es einen gravierenden Defekt gibt, der am letzten Tag
des Sprints noch vorhanden ist? Ist das Element aus dem Product Backlog dann fertig?«
Nein, es ist nicht fertig! Und weil wir Sprints gemäß unserer Regel nicht über den geplan-
ten Zeitraum hinaus verlängern, würden wir den Sprint auch nicht um einen oder zwei
Tage ausdehnen, um den Defekt im aktuellen Sprint zu beheben. Stattdessen wird das
unvollständige Backlog-Element am geplanten Ende des Sprints aus dem aktuellen Sprint
herausgenommen und wieder in das Product Backlog eingefügt, und zwar in der richtigen
Reihenfolge unter den anderen Elementen, die sich momentan im Product Backlog befin-
den. Das unvollständige Element kann dann in einem künftigen Sprint beendet werden.
Scrum-Teams brauchen eine solide Definition von Fertig – eine die ein hohes Maß an
Zuversicht vermittelt, dass ihr Produktinkrement von hoher Qualität ist und ausgeliefert
werden kann. Jede schwächere Definition beraubt die Organisation der geschäftlichen
Gelegenheit, nach ihrem Ermessen auszuliefern und kann dazu führen, dass technische
Schulden angehäuft werden (wie ich in Kapitel 8 näher ausführen werde).

4.6.2 Die Definition von Fertig kann sich im Laufe


der Zeit weiterentwickeln
Die Definition von Fertig gibt den am Ende des Sprints angestrebten Zustand der Arbeit
vor. In aller Regel beschreibt sie also den Endzustand, in dem die Arbeit potenziell ausgelie-
fert werden kann – und diese Definition bleibt im Verlauf des gesamten Entwicklungszyk-
lus normalerweise relativ unangetastet.
Als ich z.B. im Jahre 2007 als Product Owner für das Redesign-Projekt der Scrum-Alliance-
Website tätig war, führten wir einwöchige Sprints durch. Unsere Definition von Fertig lau-
tete »online auf den Produktionsservern« – das war die Zielsetzung, die das Team und ich
am Ende jedes Sprints erreichen wollten. Und nachdem wir uns zu Beginn der Entwick-
lung auf diese Definition des angestrebten Endzustands geeinigt hatten, wurde sie, solange
ich Product Owner für die Site war, auch nicht mehr geändert.
Viele Teams gehen jedoch mit einer Definition von Fertig ans Werk, die nicht in einem
Zustand endet, in dem alle Funktionen in einem Maße abgeschlossen sind, dass sie in
Betrieb genommen oder ausgeliefert werden können. Manchmal stellen sich schon gleich
zu Beginn der Entwicklungsarbeit größere organisatorische Hürden in den Weg, die das
Erreichen dieses Endzustands, selbst wenn dies die ultimative Zielsetzung ist, unmöglich

110
4.6
Definition von Fertig (Done)

machen. Deshalb wird in solchen Fällen mit einem weniger anspruchsvollen Endzustand
begonnen und die Definition von Fertig mit dem fortschreitenden Abbau der organisatori-
schen Hürden entsprechend angepasst.
Ich besuchte z.B. einmal ein Unternehmen, das ein medizinisches Datenmanagementsys-
tem für Krankenhäuser entwickelt, mit dem sich eine Vielzahl von medizinischen Daten
verwalten lassen (von denen einige sogar direkt von den diagnostischen und therapeuti-
schen Geräten übermittelt werden). Es war von vornherein klar, dass das System vor der
Auslieferung einem praktischen Test unterzogen werden musste, d.h., das Produkt musste
vor Ort in einem Krankenhauslabor installiert werden, um sicherzugehen, dass es mit der
Krankenhaus-Hardware funktionierte. Weil das Team aber keinen regelmäßigen Zugang
zu einem Labor hatte, hatte es zunächst keine klinischen Tests in seine Definition von Fer-
tig aufgenommen. Stattdessen waren am Ende jedes Releases spezielle »Kliniktest-Sprints«
vorgesehen.
In unseren Besprechungen erfuhr ich, dass diese entscheidenden Kliniktests sowohl dem
Marketing als auch dem Team regelrecht verhasst waren. Niemand konnte vorhersagen,
wie viele Sprints es dauern würde, bis alle Mängel behoben wären. Andererseits konnte das
Produkt aber natürlich erst dann ausgeliefert werden, wenn es keine Mängel mehr gab. Als
wir über mögliche Lösungen nachgrübelten, ergriff der technische Leiter das Wort und
fragte sein Team: »Wärt ihr in der Lage, in jedem Sprint klinische Tests durchzuführen,
wenn ihr Zugang zu einem Krankenhauslabor hättet?«
Die Teammitglieder diskutierten ein wenig und antworteten schließlich: »Ja, aber das
würde bedeuten, dass wir in den einzelnen Sprints weniger Funktionen fertigstellen.« Also
wollte der technische Leiter nun versuchen, das Problem zu lösen, indem er dem Team
Zugang zu einem Labor der örtlichen Universität verschaffte. Auch der Product Owner
stimmte zu, dass die Fertigstellung einer geringeren Zahl an Funktionen in jedem Sprint
ein vernünftiger Kompromiss war, wenn dafür andererseits sichergestellt wäre, dass die
ausgelieferten Funktionen den Praxistest bestanden hatten. Das Team konnte seine Defini-
tion von Fertig somit dergestalt weiterentwickeln, dass es tatsächlich den Zustand »poten-
ziell auslieferungsfähig« erreichte. Und letztendlich gewannen auf diese Weise alle
Beteiligten ein höheres Maß an Vertrauen in die Arbeit, die in den einzelnen Sprints abge-
schlossen wurde.
Manchmal kann sich ein Team aber auch einem Problem gegenübersehen, das nicht so
einfach aus der Welt zu schaffen ist – und damit steht bereits im Vorfeld fest, dass die
Definition von Fertig im Laufe der Entwicklungsarbeit zwangsläufig nachgebessert wer-
den muss. Ein verbreitetes Beispiel hierfür ist ein Produkt, das sowohl Hardware als auch
Software beinhaltet. Ich habe Scrum schon bei vielen solcher Produktentwicklungen im
Einsatz gesehen und die Software-Leute häufig sagen hören: »Die Hardware kommt
immer zu spät!« In derartigen Fällen kann das Team am Ende des Sprints nicht guten
Gewissens behaupten, dass die Ergebnisse potenziell auslieferungsfähig sind – weil
schlicht und ergreifend die Hardware fehlt, um die gebaute Software zu testen. Im besten
Fall ist die Software »emulatorfertig«, weil die Tests in frühen Sprints typischerweise auf
einer Software erfolgen, die die eigentliche Hardware emuliert. Erst wenn später die tat-
sächliche Hardware zur Verfügung steht, entwickelt sich die Definition von Fertig ent-
sprechend weiter.

111
Kapitel 4
Sprints

4.6.3 Definition von Fertig versus Akzeptanzkriterien


Die Definition von Fertig gilt immer für das Produktinkrement, das während des Sprints
entwickelt wird. Dieses Produktinkrement besteht aus einer Reihe von Elementen des Pro-
duct Backlogs. Deshalb muss jedes Backlog-Element entsprechend der Arbeit fertiggestellt
werden, die durch die »Definition-von-Fertig«-Checkliste festgelegt wurde.
Wie ich in Kapitel 5 diskutieren werde, sollte es für jedes Backlog-Element, das in den
Sprint eingebracht wird, eine Reihe von Zufriedenheitsbedingungen (Conditions of Satis-
faction), sprich elementspezifische Akzeptanzkriterien geben, die vom Product Owner fest-
gelegt werden. Und diese Akzeptanzkriterien werden dann in Akzeptanztests verifiziert,
die der Product Owner bestätigt, um festzustellen, ob das Backlog-Element so funktioniert,
wie gewünscht. Falls z.B. das Backlog-Element »Erlaube einem Kunden, mit der Kredit-
karte einzukaufen« lautet, dann könnten die Zufriedenheitsbedingungen sein: »Funktio-
niert mit AmEx, Visa und MasterCard«. Auf diese Weise bekommt jedes Backlog-Element
seine eigenen Akzeptanzkriterien. Diese elementspezifischen Kriterien gelten zusätzlich zu
den Fertigstellungskriterien der Definition-von-Fertig-Checkliste für alle Backlog-Ele-
mente, nicht anstelle dieser Kriterien.
Ein Element des Product Backlogs kann nur dann als fertig betrachtet werden, wenn
sowohl die elementspezifischen Akzeptanzkriterien (z.B. »funktioniert mit allen genann-
ten Kreditkarten«) als auch die Objekte der Definition-von-Fertig-Liste auf Sprint-Ebene
(z.B. »läuft auf dem Produktionsserver«) erfüllt sind.
Sollte Ihnen der Begriff Fertig für die Elemente des Product Backlogs, die Ihre Akzeptanz-
kriterien bestehen, zu irreführend erscheinen, dann können Sie sie alternativ natürlich
auch als abgeschlossen oder akzeptiert bezeichnen.

4.6.4 Fertig versus Fertig-Fertig


Manche Teams haben neben »Fertig« auch noch das Konzept »Fertig-Fertig« übernom-
men. Im Prinzip soll Fertig-Fertig bedeuten, dass etwas »fertiger« ist als einfach nur fertig!
Eigentlich sollten Teams keine zwei unterschiedlichen Konzepte benutzen, allerdings habe
ich mich irgendwann selbst dabei ertappt, dass ich beide Begriffe bei der Überprüfung der
Hausaufgaben meines Sohnes verwendete. Ich fragte ihn immer, ob er mit seinen Haus-
aufgaben »fertig« sei, und er behauptete, das sei er. Eines Tages fragte ich dann einmal
seine Lehrerin auf dem Elternsprechtag: »Sind seine Hausaufgaben denn fertig, wenn er
sie abgibt?« Und sie antwortete: »Eigentlich nicht!«
Nachdem ich daraufhin bei meinem Sohn ein wenig nachgebohrt hatte, kam ich zu der
Erkenntnis, dass seine Definition von Fertig »Ich habe so viel Arbeit gemacht, wie ich
geschafft habe« lautete. Und von diesem Augenblick an benutzte ich den Begriff Fertig-Fer-
tig, der für uns beide bedeutete: »Fertig in einem Maße, mit dem auch der Lehrer einver-
standen ist.«
Teams, die es nicht gewöhnt sind, Dinge wirklich frühzeitig und oft fertigzustellen, benut-
zen Fertig-Fertig vermutlich eher einmal als Hilfestellung. Für sie bedeutet es, dass sich
»Fertig« (so viel Arbeit erledigen, wie man schaffen kann) von »Fertig-Fertig« unterscheidet
(die Arbeit erledigen, die notwendig ist, damit die Kunden glauben, dass sie fertig ist).
Teams, die wirklich verinnerlicht haben, dass man erst dann fertig ist, wenn man alle

112
4.7
Abschließende Bemerkungen

Arbeiten zur Kundenzufriedenheit erledigt hat, brauchen keine zwei Zustände – wenn sie
fertig sind, dann sind sie auch wirklich fertig!

4.7 Abschließende Bemerkungen


In diesem Kapitel habe ich schwerpunktmäßig die entscheidende Rolle der Sprints im
Scrum-Framework erläutert. Sprints stellen das grundlegende Scrum-Gerüst zur Verfü-
gung, in das die meisten anderen Aktivitäten und Artefakte eingefügt werden. Sprints sind
kurz, haben vorgegebene Anfangs- und Endzeiten (»Timeboxen«) und sind immer gleich
lang. Sie werden typischerweise durch ein Sprint-Ziel definiert – ein Ziel, das nicht ohne
wirklich triftigen wirtschaftlichen Grund geändert werden sollte. Sprints sollten ein poten-
ziell auslieferungsfähiges Produktinkrement erzeugen, das entsprechend einer zuvor ver-
einbarten Definition von Fertig (Done) abgeschlossen wird. Im nächsten Kapitel werde ich
mich auf die Vorgaben für die Sprints konzentrieren: Anforderungen und ihre gebräuchli-
che Repräsentation, die User Story.

113
Kapitel 5

Anforderungen und User Stories

Anforderungen werden in einem Scrum-Projekt anders behandelt als in einem traditionel-


len Projekt. Dies vorausgeschickt, beschreibe ich in diesem Kapitel die Rolle der User Sto-
ries als allgemein übliches Format zum Darstellen von Elementen, die einen geschäftlichen
Wert besitzen. Dabei konzentriere ich mich im Wesentlichen auf die Frage, was User Sto-
ries sind, wie sie auf verschiedenen Abstraktionsebenen einen Geschäftswert repräsentie-
ren können und wie man feststellt, ob sie gut sind. Außerdem werden Sie erfahren, wie
man mit nichtfunktionalen Anforderungen umgeht und wie der Prozess des Wissenser-
werbs in einem Scrum-Projekt vonstattengeht. Und zum Schluss stelle ich Ihnen noch
zwei Techniken zum Sammeln von User Stories vor.

5.1 Überblick
Anforderungen werden in Scrum und in der sequenziellen Produktentwicklung ganz
unterschiedlich behandelt. Bei der sequenziellen Produktentwicklung sind sie nicht ver-
handelbar, werden gleich zu Beginn in detaillierter Form festgelegt und sollen für sich
allein stehen. In Scrum werden die Einzelheiten einer Anforderung hingegen in den wäh-
rend des gesamten Entwicklungsprozesses kontinuierlich geführten Gesprächen sowohl in
zeitlicher als auch in inhaltlicher Hinsicht bedarfsorientiert ausgearbeitet, so dass die Teams
mit dem Bau der entsprechenden Funktionalität beginnen können.
Bei der sequenziellen Produktentwicklung werden Anforderungen genauso behandelt wie
in der Fertigung: Sie repräsentieren notwendige, nicht verhandelbare Spezifikationen,
denen das Produkt entsprechen muss. Diese werden im Voraus ausformuliert und dem
Entwicklungsteam in Form einer sehr detaillierten Dokumentation übergeben. Und dessen
Aufgabe besteht dann darin, ein Produkt herzustellen, das diesen ausführlichen Anforde-
rungen gerecht wird.
Wenn eine Abweichung von der ursprünglichen Projektplanung notwendig erscheint,
muss ein formeller Änderungskontrollprozess durchlaufen werden. Da die Zielsetzung
jedoch darin besteht, eine Konformität mit den vorgegebenen Spezifikationen zu erreichen,
sind solche Abweichungen unerwünscht und teuer – immerhin müsste unter Umständen
ein Großteil der laufenden Arbeit (Work in Process; WIP), sprich die stark detaillierten
Anforderungen (und sämtliche darauf basierenden Arbeiten), geändert oder verworfen
werden.
Im Gegensatz dazu werden die Anforderungen in Scrum als wichtiger Handlungsspiel-
raum erachtet, den wir manipulieren können, um unsere geschäftlichen Ziele zu errei-
chen. Falls uns z.B. das Geld oder die Zeit ausgeht, können wir Anforderungen von
geringem Nutzen verwerfen. Sollten neue Erkenntnisse, die wir während des Entwick-
lungsprozesses hinzugewinnen, darauf hinweisen, dass das Kosten-Nutzen-Verhältnis

115
Kapitel 5
Anforderungen und User Stories

einer Anforderung deutlich ungünstiger ausfällt, als ursprünglich erwartet, können wir
beschließen, sie aus dem Produkt zu entfernen. Und sollte sich eine neue hochwertige
Anforderung ergeben, haben wir die Möglichkeit, sie zu dem Produkt zu ergänzen, indem
wir ggf. eine niederwertige Anforderung verwerfen, um entsprechende Kapazitäten zu
schaffen.
Wir haben wahrscheinlich alle schon die Erfahrung gemacht, dass sich – obwohl zu Beginn
der Entwicklung ein »vollständiges« Anforderungsdokument vorlag – später doch heraus-
stellte, dass eine wichtige Anforderung fehlte. Nach dem Entdecken einer solchen fehlen-
den Anforderung könnte dann ein Gespräch wie das folgende stattgefunden haben:
Kunde: »Jetzt, wo ich diese erstellten Funktionen sehe, merke ich gerade, dass ich
außerdem noch diese andere Funktion brauche, die nicht im Anforderungsdokument
steht.«
Entwickler: »Warum haben Sie diese Funktion denn nicht vorher schon spezifiziert,
wenn Sie sie gern haben wollten?«
Kunde: »Na ja, das ist mir erst aufgefallen, als ich das Produkt gesehen habe.«
Entwickler: »Tja, wenn Sie gleich von vornherein intensiver über die Anforderungen
nachgedacht hätten, dann wäre Ihnen diese Funktion sicher schon früher eingefallen.«
Tatsache ist allerdings: Wenn Sie innovative Produkte entwickeln, können Sie nicht im Vo-
raus schon vollständige Anforderungen aufstellen, indem Sie einfach nur länger und härter
arbeiten oder nachdenken. Manche Anforderungen und Designentscheidungen treten erst
zutage, wenn die Produktentwicklung bereits im Gang ist. Das lässt sich auch durch noch
so umfassende Vorarbeit nicht verhindern.
Wenn wir Scrum einsetzen, wenden wir deshalb nicht übermäßig viel Zeit und Geld auf,
um die Anforderungen bereits im Voraus in aller Ausführlichkeit zu ermitteln. Da wir
ohnehin damit rechnen, dass sich die Spezifika im Laufe der Zeit ändern, während wir
mehr über das Produkt lernen, das wir entwickeln, können wir es vermeiden, zu viel Ener-
gie in Anforderungen zu investieren, die wir später möglicherweise wieder verwerfen.
Anstatt also vorab einen ausführlichen Anforderungskatalog zusammenzustellen, legen
wir Platzhalter für die Anforderungen an, die sogenannten Product-Backlog-Elemente
(Product Backlog Items; PBIs), von denen jedes einen erstrebenswerten Geschäftswert
repräsentiert (siehe Abbildung 5.1).
Zu Anfang sind die Product-Backlog-Elemente umfangreich (sie repräsentieren große
Bereiche des Geschäftswertes) und nicht besonders detailliert. Im Laufe der Zeit werden
diese PBIs jedoch in einer Reihe von Gesprächen zwischen den Stakeholdern, dem Product
Owner und dem Entwicklungsteam so weit verfeinert, dass eine Ansammlung kleinerer,
detaillierterer PBIs entsteht. Und schließlich ist ein Product-Backlog-Element dann klein
und detailliert genug, um es in einen Sprint überführen zu können, in dem es entworfen,
gebaut und getestet wird. Aber auch während des Sprints werden sich in Gesprächen zwi-
schen dem Product Owner und dem Entwicklungsteam noch weitere Details ergeben.
Wie ich in Kapitel 6 ausführen werde, ist das Product Backlog lediglich eine Momentauf-
nahme der aktuellen Sammlung der Product-Backlog-Elemente und der mit ihnen ver-
knüpften Details.
Scrum gibt zwar kein Standardformat für diese Product-Backlog-Elemente vor, die meisten
Teams stellen sie jedoch als User Stories dar. Zwingend erforderlich ist das aber wie gesagt

116
5.2
Gespräche

nicht: Manche Teams bevorzugen stattdessen Use Cases und andere wiederum haben auch
eigene Formate für ihre PBIs.
In diesem Buch werde ich die User Stories als maßgebliche Repräsentationsform der Pro-
duct-Backlog-Elementen aufgreifen. Genaueres dazu erfahren Sie später in diesem Kapitel.
Aber selbst wenn Sie sich für eine andere Darstellungsvariante entscheiden, wird Ihnen die
Diskussion der User Stories helfen, besser zu verstehen, welche Eigenschaften Sie auch in
einer anderen anderen Repräsentationsform verwenden können bzw. sollten.

Product Backlog im Zeitverlauf

Legende
Platzhaltergröße
Größer

Kleiner
Menge an Details

Wenig Viel

Zeit
Abb. 5.1: In Scrum werden Platzhalter für die Anforderungen benutzt.

5.2 Gespräche
Anforderungen sind ein wertvolles Kommunikationsinstrument, um das gemeinsame Ver-
ständnis hinsichtlich dessen, was gebaut werden muss, zu fördern und zu erleichtern. Sie
ermöglichen es den Leuten, die eine klare Vorstellung davon haben, was geschaffen werden
soll, ihre Wünsche unmissverständlich an die Personen zu übermitteln, die das Produkt
am Ende herstellen sollen.
Die sequenzielle Produktentwicklung verlässt sich sehr stark auf schriftlich niedergelegte
Anforderungen, die eindrucksvoll sein, aber leicht missverstanden werden können. Ich
erinnere mich da an ein Gespräch mit dem Leiter des Produktmanagements in einem von
mir besuchten Unternehmen. Als ich den Herrn, dem sämtliche Geschäftsanalysten des
Unternehmens unterstanden, fragte, wie man dort mit Anforderungen umgehen würde,
antwortete er: »Am 1. Januar übergibt mein Team den Ingenieuren das Anforderungsdoku-
ment und am 31. Dezember schauen wir, was dabei herausgekommen ist.«

117
Kapitel 5
Anforderungen und User Stories

Ich wollte wissen, wer von seinem Team den Entwicklern das Jahr hindurch für Fragen und
ggf. eingehendere Erläuterungen der Anforderungen zur Verfügung stehen würde. Und er
sagte: »Niemand. Das gesamte Zeitkontingent, das meinem Team für dieses Projekt zuge-
dacht ist, wird in die Erstellung des Anforderungsdokuments investiert. Und dann sind
meine Analysten gleich schon wieder mit den Anforderungsdokumenten für andere Pro-
jekte beschäftigt. Aber keine Panik, wir arbeiten die Dokumentationen sorgfältig aus, so
dass alle Fragen, die die Entwickler oder Tester haben könnten, darin beantwortet werden,
sofern sie es gründlich lesen.«
Mir erschien es allerdings unwahrscheinlich, dass es in seinem 150 Seiten langen, ausführ-
lichen Use-Case-Dokument für ein neues elektronisches Aufzeichnungssystem für medizi-
nische Daten keine Unklarheiten geben sollte – denn normalerweise sind die in
Schriftform festgehaltenen Ausführungen sehr viel weniger präzise, als wenn man eine
Problemstellung in einer direkten, mündlichen Kommunikation erörtert.
Ein besserer Weg, um sicherzustellen, dass die gewünschten Funktionen gebaut werden,
besteht darin, dass die Leute, die wissen, was genau sie haben wollen, rechtzeitig mit den
Leuten reden, die diese Funktionen entwerfen, bauen und testen.
In Scrum dient uns das Gespräch an sich als ein wichtiges Instrument, das dafür sorgt,
dass die Anforderungen richtig diskutiert und kommuniziert werden. Die verbale Kommu-
nikation bringt den riesigen Vorteil mit sich, dass sie eine hohe Bandbreite besitzt und ein
schnelles Feedback gewährleistet, wodurch sich leichter und billiger ein gegenseitiges Ver-
ständnis erreichen lässt. Darüber hinaus erlauben Gespräche eine bidirektionale Kommu-
nikation, die Ideen in Bezug auf Probleme und Chancen zünden lassen kann –
Diskussionen, die beim Lesen eines Dokuments sicher nicht entstehen würden.
Das Gespräch ist jedoch nur ein Werkzeug, kein Ersatz für eine ausführliche Dokumenta-
tion. In Scrum ist das Product Backlog ein »lebendiges Dokument«, das während der Pro-
duktentwicklung ständig zur Verfügung steht. Und sollte darüber hinaus auch ein
separates Spezifikationsdokument für die Anforderungen benötigt werden, lässt sich dies
jederzeit bewerkstelligen, indem man einfach die Elemente aus dem Product Backlog und
die dazugehörigen Details in einem Dokument zusammenfügt.

5.3 Progressive Verfeinerung


Bei einer sequenziellen Produktentwicklung müssen alle Anforderungen gleichzeitig den-
selben Detaillierungsgrad aufweisen. Speziell das bestätigte Anforderungsdokument muss
jede einzelne Anforderung möglichst genau ausweisen, damit die Teams, die Entwurf, Bau
und Test durchführen, verstehen, wie sie diese Spezifikationen umsetzen können. Es blei-
ben keine Details mehr übrig, die man noch hinzufügen könnte.
Wenn man alle Anforderungen auf Detaillierungsgrad zwingt, bringt das allerdings viele
Nachteile mit sich:
쐽 Wir müssen all diese Details zu einem frühen Zeitpunkt in der Produktentwicklung
vorhersagen, wenn wir am wenigsten über das Produkt wissen.
쐽 Wir behandeln alle Anforderungen ungeachtet ihrer Prioritäten gleich, was uns zwingt,
heute wertvolle Ressourcen dafür einzusetzen, um Details für Anforderungen auszuar-
beiten, die wir vielleicht nie bauen werden.

118
5.4
Was sind User Stories?

쐽 Wir erstellen einen großen Anforderungskatalog, dessen Überarbeitung entweder sehr


teuer wird oder den wir einfach verwerfen, wenn die Dinge sich ändern.
쐽 Wir verringern die Wahrscheinlichkeit, dass die Anforderungen in Gesprächen aus-
führlicher erläutert werden, weil sie bereits »vollständig« sind.
Wie Abbildung 5.1 zeigt, müssen beim Einsatz von Scrum dagegen nicht alle Anforderun-
gen gleichzeitig denselben Detaillierungsgrad aufweisen. Anforderungen, an denen wir
eher arbeiten, sind kleiner und detaillierter als diejenigen, mit denen wir uns erst später
befassen. Wir nutzen eine Strategie der progressiven Verfeinerung, um nach und nach
große, relativ grob umrissene Anforderungen in kleinere, detailliertere Elemente zu zer-
legen.

5.4 Was sind User Stories?


User Stories sind ein passendes Format, um den für viele Arten von Product-Backlog-Ele-
menten, speziell für Funktionen, gewünschten Geschäftswert auszudrücken. Sie werden
auf eine Weise gestaltet, die es sowohl Managern als auch Technikern leicht macht, sie zu
verstehen, sind einfach strukturiert und großartige Platzhalter für Gespräche. Darüber hin-
aus können sie unterschiedlich ausführlich dokumentiert werden und lassen sich ganz ein-
fach progressiv verfeinern.
Doch auch wenn sie hervorragend für unsere Zwecke geeignet scheinen, betrachte ich User
Stories nicht als die einzige Methode, um Product-Backlog-Elemente zu repräsentieren. Sie
sind lediglich ein einfacher Ansatz, der hübsch in die wesentlichen Agile-Prinzipien und
unseren Bedarf nach effizienten und effektiven Platzhaltern passt. Ich nutze sie als zentrale
Platzhalter, an die ich jede andere Information anhänge, die ich für relevant und hilfreich
halte, um eine Anforderung genauer zu beschreiben. Falls ich allerdings feststelle, dass
User Stories für eine bestimmte Situation gezwungen wirken (wenn man z.B. bestimmte
Defekte darstellen möchte), dann wechsle ich zu einem anderen Ansatz. So habe ich z.B.
einmal ein Team erlebt, das folgende User Story geschrieben hatte: »Als Kunde hätte ich es
gern, dass das System nicht die Datenbank beschädigt.« Ich denke, wir stimmen alle darin
überein, dass dies nicht die beste Methode ist, um dieses Problem darzustellen. Vermutlich
wäre ein einfacher Verweis auf den Defekt im Schadensverfolgungssystem passender
gewesen.
Was genau sind also User Stories? Eine einfache, aber effektive Methode, sich User Stories
vorzustellen, stammt von Ron Jeffries (Jeffries 2001). Er beschreibt sie als die drei Cs: Card
(Karte), Conversation (Gespräch) und Confirmation (Bestätigung).

5.4.1 Card (Karte)


Die Kartenidee ist ziemlich simpel: Ursprünglich schrieben die Leute ihre User Stories
direkt auf Karteikarten oder Klebezettel (und viele tun das auch heute noch).
Oft wird dabei folgende Formatvorlage benutzt (siehe linke Spalte in Abbildung 5.2): Man
gibt die Klasse der Benutzer an (die Benutzerrolle), was die Klasse der Benutzer erreichen
möchte (das Ziel) und warum die Benutzer das Ziel erreichen wollen (den Nutzen) (Cohn
2004). Der »so dass«-Teil einer User Story ist grundsätzlich zwar optional, sollte der Zweck
der Story allerdings nicht für alle Beteiligten unzweifelhaft erkennbar sein, empfiehlt es

119
Kapitel 5
Anforderungen und User Stories

sich, ihn in jedem Fall mit aufzunehmen. Die rechte Seite von Abbildung 5.2 zeigt ein Bei-
spiel für eine User Story, die auf dieser Vorlage beruht.

User-Story-Titel Suche Kritiken nahe Adresse


Als <Benutzerrolle> möchte ich <Ziel>, Als typischer Benutzer möchte ich
so dass <Vorteil>. unparteiische Kritiken eines Restaurants

rlage in der Nähe eines anzugebenden Standorts,

Vo so dass ich entscheiden kann, wo ich


essen gehe.

Abb. 5.2: Vorlage und Karte für eine User Story

Die Karte ist nicht dazu gedacht, alle Informationen zu erfassen, aus denen eine Anforde-
rung besteht. Wir benutzen sogar absichtlich kleine Karten, um eine gewisse Knappheit zu
fördern. Eine Karte sollte nur wenige Sätze enthalten, die das Wesen oder die Absicht einer
Anforderung ausdrücken, und dient als Platzhalter für ausführlichere Diskussionen, die
zwischen den Stakeholdern, dem Product Owner und dem Entwicklungsteam stattfinden.

5.4.2 Conversation (Gespräch)


Die Details einer Anforderung werden in einem Gespräch zwischen dem Entwicklungs-
team, dem Product Owner und den Stakeholdern ermittelt und kommuniziert. Die User
Story ist einfach ein Versprechen, dieses Gespräch zu führen.
Bei diesem »Gespräch«, von dem hier die Rede ist, handelt es sich aber eigentlich nicht um
ein einmaliges Ereignis, sondern vielmehr um einen anhaltenden Dialog. So könnte z.B.
ein erstes Gespräch stattfinden, wenn die User Story geschrieben wird, ein weiteres, wenn
sie verfeinert wird, ebenso, wenn sie eingeschätzt wird, noch eins während der Sprint-Pla-
nung (wenn das Team in die Details auf Aufgabenebene eintaucht) und schließlich gibt es
außerdem Gespräche, wenn die User Stories während des Sprints entworfen, gebaut und
getestet werden.
Einer der Vorteile von User Stories besteht darin, dass sie den Fokus vom Schreiben weg
und hin zu den Gesprächen verlagern. Diese Gespräche erlauben eine reichere Form des
Informationsaustauschs und der Zusammenarbeit, so dass die richtigen Anforderungen
ausgedrückt und von allen verstanden werden.
Auch wenn Gespräche größtenteils verbal stattfinden, werden sie oft von Dokumenten
begleitet. Sie könnten zu einer Skizze der Benutzeroberfläche führen oder zu einer Auslas-
sung über die Unternehmensregeln, die niedergeschrieben wird. So besuchte ich z.B. ein-
mal eine Organisation, die medizinische Bildbearbeitungssoftware entwickelte. Eine ihrer
Stories ist in Abbildung 5.3 dargestellt.
Wie Sie sehen, verweist die User Story auf einen ganzen Artikel, der gelesen werden und
über den später gesprochen werden soll.
Wir werfen also nicht auf einmal alle unsere Dokumente weg, nur weil wir jetzt User Sto-
ries mit den dazugehörigen Story-Karten haben. User Stories sind lediglich ein guter Aus-

120
5.4
Was sind User Stories?

gangspunkt, um einen ersten Eindruck davon zu bekommen, was gewünscht ist, und um
sich daran zu erinnern, dass man zu gegebener Zeit ausführlicher über die Anforderungen
diskutieren muss. Dabei können und sollten User Stories auf jeden Fall durch alle schriftli-
chen Informationen ergänzt werden, die weitere Klarheit darüber verschaffen, was
gewünscht wird.

Johnson-Visualisierung von MRI-Daten


Als Radiologe möchte ich MRI-Daten mit
Dr. Johnsons neuem Algorithmus visuali-
sieren. Mehr Details siehe Ausgabe Jan.
2007 des Journal of Mathematics,
Seiten 110-118.

Abb. 5.3: User Story mit zusätzlichen Daten

5.4.3 Confirmation (Bestätigung)


Darüber hinaus enthält eine User Story bestätigende Informationen in Form der Zufrie-
denheitsbedingungen. Dabei handelt es sich um die Akzeptanzkriterien, die das
gewünschte Verhalten veranschaulichen. Das Entwicklungsteam nutzt sie, um besser ver-
stehen zu können, was gebaut und getestet werden soll, und der Product Owner greift auf
sie zurück, um sicherzustellen, dass die User Story zu seiner Zufriedenheit umgesetzt
wird.
Falls auf der Vorderseite der Karte eine kurze Beschreibung der Story steht, sollten auf der
Rückseite die Zufriedenheitsbedingungen zu finden sein (siehe Abbildung 5.4).
Diese Zufriedenheitsbedingungen können als allgemeine Akzeptanztests ausgedrückt wer-
den. Allerdings wären dies nicht die einzigen Tests, die ausgeführt werden, wenn die Story
entwickelt wird. Den wenigen Akzeptanztests, die mit einer User Story verbunden sind,
stehen auf der technischen Ebene deutlich mehr andere Tests gegenüber (etwa 10 bis 100
mal mehr), die das Team durchführt und von denen der Product Owner vermutlich gar
nichts weiß.
Die mit der Story verbundenen Akzeptanztests gibt es aus verschiedenen Gründen. Erstens
stellen sie eine wichtige Methode dar, um aus Sicht des Product Owners festzustellen und
zu kommunizieren, ob die Story korrekt umgesetzt wurde.
Außerdem können diese Tests auch dabei helfen, erste Stories zu erstellen und diese
anschließend progressiv zu verfeinern, wenn weitere Details bekannt werden. Dieser
Ansatz wird auch als Spezifikation nach Beispiel oder Acceptance-Test-driven Development
(ATTD), also Akzeptanztest-getriebene Entwicklung , bezeichnet. Der Gedanke dahinter ist
relativ intuitiv. Diskussionen über Stories konzentrieren sich oft darauf, bestimmte Bei-
spiele oder gewünschte Verhaltensweisen zu definieren. So verlief das Gespräch zu der in
Abbildung 5.4 gezeigten »Datei hochladen«-Story vermutlich in etwa folgendermaßen:
Lasst uns zu Anfang die Größe der hochgeladenen Dateien auf maximal 1 GB beschrän-
ken. Sorgt außerdem dafür, dass wir normale Text- und Grafikdateien richtig hochladen

121
Kapitel 5
Anforderungen und User Stories

können. Und aus rechtlichen Gründen können wir nicht zulassen, dass Dateien mit
DRM-Beschränkungen (Digital Rights Management) in das Wiki geladen werden.

Datei hochladen Zufriedenheitsbedingungen


Als Wiki-Benutzer möchte ich eine Verifiziere .txt- und .doc-Dateien
Datei in das Wiki laden, so dass ich sie Verifiziere .jpg-, .gif- und .png-Dateien
mit meinen Kollegen teilen kann. Verifiziere .mp4-Dateien <= 1 GB
Verifiziere keine DRM-geschützten
Dateien

Abb. 5.4: Zufriedenheitsbedingungen für User Story

Größe Valid()
0 True
1073741824 True
1073741825 False
Tabelle 5.1: Beispiel für automatisierten Test

Mit einem Werkzeug wie Fit oder FitNesse könnten wir diese Tests zudem ganz bequem in
tabellarischer Form definieren, wie die Beispiele für unterschiedliche Dateigrößen und
deren Gültigkeit in Tabelle 5.1 zeigen.
Indem wir solche speziellen Beispiele genauer ausführen, können wir die Erstellung der
Story und den progressiven Verfeinerungsprozess vorantreiben und (automatisierte)
Akzeptanztests für jede Story bereitstellen.

5.5 Der Detaillierungsgrad


User Stories sind ein ausgezeichnetes Hilfsmittel, um Elemente, die für Kunden oder
Anwender von Wert sind, durch den Wertschöpfungsprozess von Scrum zu tragen. Falls
wir jedoch nur eine Story-Größe haben (die Größe, die bequem in einen kurzen Sprint
passt), wird es schwierig, detailliertere Planungen vorzunehmen und die Vorteile der pro-
gressiven Verfeinerung zu nutzen.
Kleine Stories auf Sprint-Ebene sind zu klein und zu zahlreich, um Planungen auf Pro-
dukt- und Release-Ebene zu unterstützen. Auf diesen Ebenen brauchen wir weniger, nicht
so detaillierte, abstraktere Elemente. Ansonsten versinken wir in einem Sumpf überwie-
gend irrelevanter Details. Stellen Sie sich nur einmal vor, Sie haben 500 sehr kleine Stories
und werden aufgefordert, dem Management eine Beschreibung des angestrebten Produkts
zu liefern, um die Finanzierung zu sichern – oder diese 500 wirklich kleinen Elemente zu
priorisieren, um die nächste Version zu definieren.

122
5.5
Der Detaillierungsgrad

Wenn es nur eine (kleine) Größe für die Stories gibt, sind wir außerdem genötigt, alle
Anforderungen mit einem hohen Detaillierungsgrad zu definieren, obwohl das erst viel
später notwendig ist. Haben wir nur kleine Stories, dann sind alle Vorteile der progressiven
Verfeinerung der Anforderungen – die erst dann erfolgt, wenn sie wirklich notwendig ist –
hinfällig.
Glücklicherweise kann man User Stories so schreiben, dass sie die Bedürfnisse der Kunden
und Anwender auf unterschiedlichen Abstraktionsebenen erfassen.
Abbildung 5.5 stellt Stories auf unterschiedlichen Abstraktionsniveaus dar. Am größten
sind Stories, die einen Umfang von einigen bis vielen Monaten haben und sich über eine
ganze Version oder vielleicht sogar mehrere Versionen erstrecken. Manchmal werden sol-
che Stories auch als Epics bezeichnet, weil sie vom Umfang her mit literarischen Werken
epischen Ausmaßes wie Der Herr der Ringe oder Krieg und Frieden vergleichbar sind. Epics
sind insofern hilfreich, weil sie das ganze Bild zeigen und einen allumfassenden Überblick
über das liefern, was gewünscht ist (siehe Abbildung 5.6).
Allerdings würden wir ein Epic niemals zur Entwicklung in einen Sprint überführen, weil
es viel zu groß und nicht besonders detailliert ist. Stattdessen sind Epics ausgezeichnete
Platzhalter für eine große Sammlung detaillierterer Stories, die zu einem passenden späte-
ren Zeitpunkt geschaffen werden. Bei der Diskussion der Produktplanung in Kapitel 17
werde ich noch näher auf die Verwendung von Epics eingehen.

Monate Größer als eine Version

Wochen Größer als ein Sprint

Tage Sprint-bereit

Stunden Aufgaben

Abb. 5.5: Abstraktionshierarchie einer User Story

Präferenztraining-Epic
Als typischer Benutzer möchte ich dem
System beibringen, welche Arten von
Produkt- und Service-Kritiken ich
bevorzuge, so dass es in meinem Namen
entsprechend filtern kann.

Abb. 5.6: Epic-Beispiel

123
Kapitel 5
Anforderungen und User Stories

Die in Abbildung 5.5 dargestellte nächstkleinere Größe sind Stories, die sich im Rahmen
von einigen Wochen bewegen und deshalb zu groß für einen einzelnen Sprint sind. Man-
che Teams bezeichnen diese als Funktionen.
Und die kleinste Form der User Story ist schließlich diejenige, die ich üblicherweise als
Story bezeichne. Um eine Verwechslung mit Epen, Funktionen oder anderen größeren Ele-
menten zu vermeiden, bei denen es sich ebenfalls um »Stories« handelt, nennen manche
Leute diese Stories entweder sprintfähige Stories oder umsetzbare Stories (implementable
stories). Damit wollen sie andeuten, dass sie sich in Größenordnungen von einigen Tagen
bewegen und deshalb klein genug sind, um in einen Sprint zu passen und umgesetzt zu
werden. Abbildung 5.2 enthält ein Beispiel für eine sprintfähige Story.
Manche Teams benutzen auch den Begriff Theme für eine Sammlung zusammenhängen-
der Stories. Themes eignen sich gut, um auszudrücken, dass mehrere Stories etwas
gemeinsam haben, sich z.B. im selben funktionalen Bereich bewegen. In Abbildung 5.7
wird das Theme aus einer Sammlung von Stories gebildet, in denen die Details zur Durch-
führung des Stichworttrainings ausgeführt sind.

Stichworttraining-Theme
Als typischer Benutzer möchte ich das
System lehren, welche Stichwörter es
beim Filtern von Kritiken nutzen soll, so
dass es nach Wörtern filtert, die
für mich wichtig sind.

Abb. 5.7: Beispiel-Theme

Ich stelle mir ein Theme oft als eine zusammenfassende Karte für einen Stapel Karteikar-
ten vor, die mit einem Gummi zusammengehalten werden, damit klar erkennbar ist, dass
sie sich alle auf einen inhaltlichen Bereich beziehen, den wir für wichtig halten.
Aufgaben bilden die Ebene unterhalb der Stories. Sie werden typischerweise von einer, viel-
leicht von zwei Personen bearbeitet. Für ihre Ausführung sind meist nur Stunden nötig.
Wenn wir uns auf die Aufgabenebene begeben, dann geben wir an, wie etwas gebaut wer-
den soll – nicht jedoch, was gebaut wird (dies wird durch Epics, Funktionen und Stories vor-
gegeben). Aufgaben sind keine Stories, daher sollten sie auch keine zur Aufgabenebene
gehörigen Details enthalten.
Denken Sie immer daran, dass Begriffe wie Epic, Funktion, Story und Theme nur Bezeich-
nungen sind, die der Einfachheit halber vergeben werden und nicht unbedingt allgemein
üblich sind. Es spielt keine Rolle, welche Bezeichnungen Sie verwenden, solange Sie kons-
tant dabei bleiben. Zu beachten ist auch, dass Stories auf verschiedenen Abstraktionsstufen
existieren können und daher bei unseren Versuchen, auf verschiedenen Abstraktionsebe-
nen zu planen und große Elemente schrittweise zu kleinen Elementen zu verfeinern, sehr
hilfreich sein können.

124
5.6
In gute Stories INVESTieren

5.6 In gute Stories INVESTieren


Woher wissen wir, dass unsere Stories gute Stories sind? Bill Wake hat sechs Kriterien auf-
gestellt (zusammengefasst unter dem Akronym INVEST), mit denen sich ganz gut feststel-
len lässt, ob unsere Stories für ihren gewünschten Zweck geeignet sind oder weitere Arbeit
erfordern (Wake 2003).
Die INVEST-Kriterien sind Independent (unabhängig), Negotiable (verhandelbar), Valuable
(werthaltig), Estimatable (schätzbar), Small (klein, d.h. von der passenden Größe) und Testa-
ble (prüfbar). Wenn wir die Informationen kombinieren, die wir aus der Anwendung der
einzelnen Kriterien beziehen, erhalten wir ein klares Bild der Änderungen, die wir mögli-
cherweise noch an einer Story vornehmen wollen. Schauen wir uns nun die einzelnen Kri-
terien einmal genauer an.

5.6.1 Independent (unabhängig)


User Stories sollten nach Möglichkeit unabhängig voneinander oder höchstens lose mitein-
ander verbunden sein. Stories, die sehr stark miteinander verflochten sind, verkomplizie-
ren das Schätzen, Priorisieren und Planen. So hängt z.B. Story #10 auf der linken Seite in
Abbildung 5.8 von vielen anderen Stories ab.

Element Element

Story #9
Abhängigkeiten

Story #10 Story #10

Story #11

Abhängigkeiten

Abb. 5.8: Stark voneinander abhängige Stories

Bevor wir an Story #10 arbeiten können, müssen wir alle abhängigen Stories entwickeln. In
diesem speziellen Fall mag das nicht so schlimm sein – aber stellen Sie sich doch einmal
vor, Sie hätten viele unterschiedliche Stories mit einem hohen Grad an gegenseitigen

125
Kapitel 5
Anforderungen und User Stories

Abhängigkeiten haben, wie z.B. in Abbildung 5.8 rechts zu sehen. Die Prioritäten all dieser
Stories zu ermitteln und festzustellen, an welchen von ihnen man in einem Sprint zuerst
arbeiten sollte, ist – gelinde gesagt – schwierig.
Wenn man das Unabhängigkeitskriterium anwendet, besteht das Ziel nicht darin, alle
Abhängigkeiten zu eliminieren, sondern die Stories vielmehr so zu schreiben, dass Abhän-
gigkeiten minimiert werden.

5.6.2 Negotiable (verhandelbar)


Die Details der Stories sollten verhandelbar sein. Stories sind kein schriftlicher Vertrag in
Form eines vorab verfassten Anforderungsdokuments – sie sind vielmehr Platzhalter für
die Gespräche, in denen die Details ausgehandelt werden.
Gute Stories erfassen die Essenz der Business-Funktionalität, die gewünscht wird, und
wieso sie gewünscht wird, in unmissverständlicher Weise. Allerdings lassen sie dem Pro-
duct Owner, den Stakeholdern und dem Team auch Spielraum, um die Einzelheiten auszu-
handeln.
Diese Verhandelbarkeit hilft allen Beteiligten, eine Wir-gegen-sie-Mentalität zu vermeiden,
die bei der Verwendung detaillierter, im Voraus abgefasster Anforderungsdokumente sehr
verbreitet ist. Wenn Stories verhandelbar sind, können die Entwickler nicht einfach sagen:
»Wenn Sie das gewollt hätten, dann hätten Sie es in das Dokument schreiben müssen«,
weil die Einzelheiten ja zuvor mit ihnen ausgehandelt werden. Und die Leute vom Unter-
nehmen können nicht einfach sagen: »Ihr habt offensichtlich das Anforderungsdokument
nicht verstanden, ihr habt nämlich das Falsche gebaut«, schließlich stehen sie ihrerseits in
regem Austausch mit den Entwicklern, um sicherzustellen, dass alle Unklarheiten ausge-
räumt werden. Das Schreiben verhandelbarer Stories umgeht also die mit vorab verfassten
Anforderungsdokumenten verbundenen Probleme, indem es deutlich macht, dass ein Dia-
log notwendig ist.
Ein verbreitetes Beispiel, bei dem die Verhandelbarkeit verletzt wird, ist der Fall, wenn der
Product Owner dem Team sagt, wie es eine Story umsetzen soll. Bei Stories sollte es immer
um das »Was« und »Warum« gehen, nicht um das »Wie«. Wenn das Wie nicht verhandel-
bar ist, verliert das Team die Chance, innovativ zu sein – und die daraus resultierende
Verschwendung von Innovation könnte verheerende wirtschaftliche Folgen haben.
Manchmal ist es für den Product Owner jedoch von besonderer Bedeutung, wie etwas
gebaut wird. Es könnte z.B. eine behördliche Auflage geben, eine Funktion auf eine
bestimmte Weise entwickeln zu müssen. Oder vielleicht gibt es auch auf unternehmeri-
scher Ebene eine Vorgabe, die die Verwendung einer bestimmten Technik vorschreibt. In
solchen Fällen sind die Stories nicht mehr ganz so stark verhandelbar, weil ein gewisser
Aspekt des »Wie« erforderlich ist. Auch das ist natürlich in Ordnung. Nicht alle Stories sind
voll verhandelbar, aber die meisten sollten es sein.

5.6.3 Valuable (werthaltig)


Stories müssen für einen Kunden, einen Anwender oder beide einen Wert haben. Kunden
(bzw. die Entscheider) wählen das Produkt aus und zahlen dafür. Anwender benutzen das
Produkt in der Praxis. Wenn eine Story für einen von beiden nicht werthaltig ist, dann
gehört sie nicht in das Product Backlog. Ich kann mir jedenfalls nicht vorstellen, dass

126
5.6
In gute Stories INVESTieren

jemand sagt: »Story #10 hat für niemanden einen Wert, lasst sie uns trotzdem umsetzen.«
Das würden wir einfach nicht tun. Stattdessen würden wir die Story entweder umschrei-
ben, damit sie für den Kunden oder Anwender an Wert gewinnt, oder wir würden sie ver-
werfen.
Doch wie steht es mit Stories, die zwar für die Entwickler werthaltig sind, aber keinen
offensichtlichen Wert für die Kunden oder Anwender haben? Ist es in Ordnung, technische
Stories wie jene aus Abbildung 5.9 zu implementieren?
Das grundlegende Problem mit technischen Stories ist, dass der Product Owner möglicher-
weise keinen Wert in ihnen erkennt – was es schwierig, wenn nicht gar unmöglich macht,
ihnen eine Priorität gegenüber den geschäftlich werthaltigen Stories einzuräumen. Damit
eine technische Story existieren kann, muss der Product Owner verstehen, wieso er dafür
bezahlen soll und welchen Wert diese Story für ihn am Ende darstellt.

Auf eine neue Oracle-Version migrieren


Als Entwickler möchte ich das System
migrieren, damit es mit der neuesten
Version des Oracle DBMS arbeitet, damit
wir nicht mit einer Version arbeiten, die
Oracle bald außer Betrieb nimmt.

Abb. 5.9: Beispiel für eine technische Story

Im Fall der Story »Auf eine neue Version von Oracle migrieren« versteht der Product
Owner vielleicht am Anfang nicht, wieso es sinnvoll ist, die Datenbank zu wechseln. Sobald
ihm das Team jedoch die Risiken erklärt hat, die damit verbunden sind, wenn man weiter
auf einer nicht unterstützten Version einer Datenbank entwickelt, könnte der Product
Owner entscheiden, dass das Migrieren der Datenbanken werthaltig genug ist, um das
Bauen einiger neuer Funktionen auf den Zeitpunkt nach der Migration zu verschieben.
Wenn der Product Owner den Wert versteht, kann er die technische Story genauso behan-
deln wie jede andere aus geschäftlicher Sicht werthaltige Story und nach sorgfältigen Erwä-
gungen sachkundig entscheiden, ob sie schließlich in das Product Backlog aufgenommen
wird oder nicht.
In der Praxis allerdings sollten die meisten technischen Stories (wie die aus Abbildung
5.10) nicht im Product Backlog auftauchen.
Stattdessen sollten sie als Aufgaben behandelt werden, die mit der Erledigung geschäftlich
werthaltiger Stories verknüpft werden. Sofern das Entwicklungsteam eine solide Definition
von Fertig hat, sollte es eigentlich nicht notwendig sein, diese Art von Stories zu schreiben,
weil die darin ausgewiesene Arbeit durch die Definition von Fertig impliziert wird.
Der Knackpunkt des Kriteriums werthaltig ist, dass aus Sicht des Product Owners alle Sto-
ries im Backlog werthaltig sein müssen (d.h., um Werte, Zeit und Geld in sie zu investie-
ren). Schließlich repräsentiert die Sicht des Product Owners die Sicht der Kunden und
Anwender. Nicht alle Stories sind unabhängig und nicht alle Stories sind voll verhandelbar,
aber alle Stories müssen werthaltig sein.

127
Kapitel 5
Anforderungen und User Stories

5.6.4 Estimatable (schätzbar)


Stories müssen von dem Team, das sie entwirft, baut und testet, eingeschätzt werden kön-
nen. Schätzungen liefern einen Hinweis auf die Größe und somit auch auf den Aufwand
und die Kosten der Stories (größere Stories erfordern mehr Aufwand und sind daher auch
in der Entwicklung teurer als kleinere Stories).
Das Wissen um die Größe einer Story liefert dem Scrum-Team nachvollziehbare Informati-
onen. Der Product Owner muss z.B. die Kosten einer Story kennen, um ihre endgültige
Priorität im Product Backlog bestimmen zu können. Das Scrum-Team andererseits kann
anhand der Größe der Story feststellen, ob eine weitere Verfeinerung oder Zerlegung erfor-
derlich ist. Eine große Story, an der wir bald arbeiten wollen, muss in eine Reihe kleinerer
Stories aufgeteilt werden.

Automatische Builds
Als Entwickler möchte ich, dass die
Builds automatisch laufen, wenn ich den
Code einchecke, damit Regressionsfehler
erkannt werden, sobald sie auftreten.

Abb. 5.10: Unerwünschte technische Story

Sollte das Team nicht in der Lage sein, die Größe einer Story zu bestimmen, dann ist sie
entweder zu umfangreich oder zu unklar, oder das Team besitzt nicht genug Informatio-
nen, um eine Größe schätzen zu können. Ist die Story zu groß, muss das Team mit dem
Product Owner zusammenarbeiten, um sie in kleinere, besser zu handhabende Stories auf-
zuteilen. Mangelt es dem Team an Informationen, sind gewisse Erkundungsaktivitäten
erforderlich, um diese zu erlangen (darauf gehe ich gleich ein).

5.6.5 Passende Größe (klein)


Stories müssen zu dem Zeitpunkt, an dem wir beginnen, an ihnen zu arbeiten, eine ange-
messene Größe haben. Werden sie in Sprints bearbeitet, sollten sie eher klein sein. Beträgt
die Sprint-Dauer mehrere Wochen, wollen wir an mehreren Stories arbeiten, die jeweils
einige Tage umfassen. Bei einem zweiwöchigen Sprint möchten wir dagegen keine Story
haben, die sich über zwei Wochen erstreckt, weil das Risiko zu groß ist, dass wir sie nicht
abschließen.
Wir brauchen also letztendlich kleine Stories, allerdings muss das nicht heißen, dass es
schlecht ist, wenn eine Story groß ist. Nehmen wir an, wir haben eine Story von epischen
Ausmaßen, an der wir aber frühestens in einem Jahr arbeiten wollen. Für den geplanten
Zeitpunkt der Bearbeitung ist die Größe der Story genau richtig. Würden wir nämlich
heute schon damit beginnen, das Epic in eine Ansammlung kleinerer Stories aufzuteilen,
dann wäre das vermutlich komplette Zeitverschwendung. Haben wir natürlich ein Epic, an
dem wir im nächsten Sprint zu arbeiten planen, wäre die Größe nicht angemessen und wir

128
5.7
Nichtfunktionale Anforderungen

müssten uns bemühen, es erst einmal auf die passende Größe zurechtzustutzen. Sie müs-
sen also in Betracht ziehen, wann eine Story bearbeitet werden soll, wenn Sie dieses Krite-
rium anwenden.

5.6.6 Testable (prüfbar)


Stories sollten auf binäre Weise prüfbar sein – entweder bestehen sie die ihnen zugedach-
ten Tests oder sie bestehen sie nicht. Prüfbarkeit bedeutet, dass Sie gute Akzeptanzkriterien
(verwandt mit den Zufriedenheitsbedingungen) für die Story haben. Das ist der bereits dis-
kutierte »Bestätigungsaspekt«.
Woher würden wir ohne prüfbare Kriterien am Ende des Sprints wissen, ob die Story fertig
ist? Da die Tests oft wichtige Story-Details liefern, sind sie unter Umständen schon nötig,
bevor das Team die Story überhaupt erst einschätzen kann.
Es mag allerdings nicht immer notwendig oder möglich sein, eine Story zu testen. So sind
mit Stories von epischem Ausmaß wahrscheinlich keine Tests verknüpft – wir brauchen sie
auch gar nicht, da wir die Epics nicht direkt bauen.
Gelegentlich mag es außerdem eine Story geben, die der Product Owner für werthaltig hält,
deren Wert sich aber nicht praktikabel testen lässt. Mit hoher Wahrscheinlichkeit handelt es
sich hierbei um nichtfunktionale Anforderungen wie etwa »Als Anwender möchte ich, dass
das System zu 99,999% der Zeit in Betrieb ist«. Das Akzeptanzkriterium mag zwar klar
sein, es gibt aber keinen praktischen Test, den man bei Inbetriebnahme des Systems aus-
führen könnte, um dieses Maß an Betriebsfähigkeit zu beweisen. Dennoch ist die Anforde-
rung werthaltig, weil sie die Motivation hinter dem Design befördert.

Internationalisierung Webbrowser-Unterstützung
Als Benutzer möchte ich eine Oberfläche System muss IE8, IE9, Firefox 6,
in Englisch, einer romanischen Sprache Firefox 7, Safari 5 und Chrome 15
und einer komplexen Sprache, damit sie unterstützen.
in allen 70 geforderten Sprachen
funktioniert.

Abb. 5.11: Nichtfunktionale Anforderungen

5.7 Nichtfunktionale Anforderungen


Nichtfunktionale Anforderungen repräsentieren Beschränkungen auf Systemebene. Ich
schreibe nichtfunktionale Anforderungen oft als User Stories (siehe Abbildung 5.11 links),
fühle mich aber nicht dazu verpflichtet – insbesondere dann nicht, wenn das seltsam wirkt
oder wenn es bequemer ist, sie in einem anderen Format aufzuschreiben (Abbildung 5.11
rechts).
Als Beschränkungen auf Systemebene sind nichtfunktionale Anforderungen wichtig, weil
sie das Design und das Testen der meisten oder aller Stories im Product Backlog beeinflus-
sen. So ist z.B. die nichtfunktionale Anforderung »Webbrowser-Unterstützung« (Abbil-

129
Kapitel 5
Anforderungen und User Stories

dung 5.11 rechts) bei jedem Website-Projekt üblich. Wenn das Team die Funktionen der
Website entwickelt, muss es dafür sorgen, dass diese mit allen angegebenen Browsern
funktionieren.
Außerdem muss das Team entscheiden, wann es all diese Browser testet. Alle nichtfunktio-
nalen Anforderungen müssen in die Definition von Fertig aufgenommen werden. Nimmt
das Team also die nichtfunktionale Anforderung »Webbrowser-Unterstützung« in seine
Definition von Fertig auf, muss es alle neuen Funktionen, die in dem Sprint entstanden
sind, mit allen aufgeführten Browsern testen. Funktioniert das nicht mit allen, ist die Story
nicht fertig.
Generell sollten die Teams so viele der nichtfunktionalen Anforderungen in ihre Definitio-
nen von Fertig aufnehmen wie möglich – werden sie nämlich erst in einer späten Phase
des Entwicklungsprozesses getestet, verzögert sich damit natürlich auch das Feedback zu
wichtigen Merkmalen der Systemleistung.

5.8 Stories zum Wissenserwerb


Manchmal müssen wir ein Product-Backlog-Element anlegen, das sich auf den Erwerb von
Wissen konzentriert. Möglicherweise haben wir nicht genügend verwertbare Erkenntnisse
über das Produkt oder den Prozess des Produktbaus, um weiterzumachen. Deshalb müs-
sen wir, wie ich bereits in Kapitel 3 ausgeführt habe, Erkundungen und Untersuchungen
anstellen. Dieser Vorgang hat viele Namen: Prototyp, Nachweis des Konzepts, Experiment,
Studie usw., im Prinzip sind das aber alles Erkundungsaktivitäten, bei denen man Informa-
tionen einholt.
Oft nutze ich eine User Story als Platzhalter für die Erkundungsarbeit (siehe Abbildung
5.12).
In diesem Beispiel möchte das Team zwei mögliche Architekturen für die neue Filter-
Engine beurteilen. Es schlägt vor, für beide Architekturen einen Prototypen zu fertigen und
dann Geschwindigkeits-, Skalierungs- und Typtests mit beiden Prototypen durchzuführen.
Das Ergebnis des Prototypings wird ein kurzes Memo sein, das die durchgeführten Experi-
mente sowie die erzielten Resultate beschreibt und die Empfehlung des Teams für das wei-
tere Vorgehen enthält.
Diese spezielle Story zum Wissenserwerb sieht wie eine technische Story aus. Und wie ich
bereits erwähnt habe, muss der Geschäftswert einer technischen Story für den Product
Owner gerechtfertigt sein. Da Product Owner in wirtschaftlichen Begriffen denken, muss
ihnen eine wirtschaftliche Rechtfertigung für diese Prototyp-Arbeit geliefert werden. Es
gibt mit Sicherheit ein überzeugendes technisches Argument für die Durchführung einer
Story zum Wissenserwerb, weil das Team normalerweise keine Fortschritte macht, bis ihm
die durch diese Story bereitgestellten Erkenntnisse zur Verfügung stehen. Das Scrum-
Team muss lediglich die Frage klären, ob der Wert der erworbenen Informationen höher ist
als die Kosten für ihre Beschaffung.
Und so könnte ein Scrum-Team vorgehen, um diese Frage zu beantworten: Zunächst ein-
mal müssen wir die Kosten für das Prototyping kennen. Kein guter Product Owner wird
eine unbegrenzte Erkundung zulassen. Das Team kann bestimmte Fragen möglicherweise
erst beantworten, wenn eine Entscheidung hinsichtlich der Architektur getroffen wurde. Es

130
5.8
Stories zum Wissenserwerb

muss allerdings in der Lage sein zu sagen, wie viel Aufwand es betreiben möchte, um die
Informationen zu beschaffen, die für diese architektonische Entscheidung nötig sind. Des-
halb bitten wir das Team, die Größe der Prototyping-Story einzuschätzen.
Nehmen wir einmal an, die Größenschätzung weist darauf hin, dass das komplette Team
einen ganzen Sprint lang an der Story arbeiten muss. Wir wissen, wer im Team ist und wie
lange der Sprint dauert, so dass wir auch die Kosten für den Erwerb der Informationen ken-
nen. (Es könnten z.B. 10.000 Dollar sein.) Nun müssen wir den Wert der Informationen
ermitteln.
Hier ist eine Möglichkeit, den Wert zu schätzen. Stellen Sie sich vor, ich würde eine Münze
werfen: Liegt Kopf oben, nehmen wir Architektur A, bei Zahl nehmen wir Architektur B.
Jetzt bitte ich das Team einzuschätzen, was es kostet, wenn es sich irrt. Was würde es z.B.
kosten, die schlechte Entscheidung rückgängig zu machen und alles auf Architektur B auf-
zubauen – immer vorausgesetzt, ich hatte Kopf geworfen und wir habe alles auf Architek-
tur A aufgebaut, was sich aber als die falsche Entscheidung herausgestellt hat? Nehmen wir
weiter an, das Team hätte die Kosten auf 500.000 Dollar geschätzt.

Filter-Engine Architekturbewertung Zufriedenheitsbedingungen


Als Entwickler möchte ich Alternativen Geschwind.test auf beiden Prototypen.
für die neue Filter-Engine (als Prototyp), Skalierungstest auf beiden Prototypen.
damit ich weiß, welches die langfristig Typtest auf beiden Prototypen.
bessere Wahl ist. Kurzes Memo: Experimente, Ergebnisse
und Empfehlungen beschreiben.

Abb. 5.12: Story zum Wissenserwerb

Nun haben wir genügend Informationen, um eine vernünftige wirtschaftliche Entschei-


dung treffen zu können. Sind wir gewillt, 10.000 Dollar für den Erwerb von Informationen
aufzuwenden, die einen erwarteten Wert von 250.000 Dollar besitzen (in 50% der Fälle
haben wir die Münze richtig geworfen)? Sicher, das sieht aus wie eine vernünftige geschäft-
liche Entscheidung. Jetzt kann der Product Owner rechtfertigen, wieso diese Story im Back-
log landet.
Um noch ein letztes Mal zu verdeutlichen, wie man mit wirtschaftlichen Argumenten Sto-
ries zum Wissenserwerb rechtfertigt, lassen Sie uns die Zahlen noch einmal ändern. Was
ist, wenn die Antwort des Teams auf die Frage »Was würde es kosten, wenn wir uns irren?«
15.000 Dollar lautet? In diesem Fall wäre es eine schlechte Entscheidung, die Prototyping-
Story durchzuführen. Wieso sollte man 10.000 Dollar aufwenden, um Informationen zu
kaufen, die einen erwarteten Wert von 7.500 Dollar haben? Wir wären besser dran, wenn
wir die Münze werfen (oder geschickt raten) und, falls wir uns irren, die Arbeit einfach mit
der anderen Architektur wiederholen. Angesichts der heutzutage immer höher entwickel-
ten Techniken ist dieses Szenario übrigens gar nicht so weit hergeholt, wie es klingen mag.
Es ist ein Beispiel für eine sogenannte Fail-Fast-Strategie (versuche etwas, bekomme
schnelles Feedback, untersuche das Ganze schnell und passe dein weiteres Vorgehen ent-
sprechend an).

131
Kapitel 5
Anforderungen und User Stories

5.9 Stories sammeln


Aber wie kommt man denn nun zu den User Stories? Traditionelle Ansätze zum Sammeln
der Anforderungen beinhalten das Befragen der Anwender nach ihren Wünschen. Ich bin
mit diesem Vorgehen allerdings noch nie so richtig erfolgreich gewesen. Meiner Erfahrung
nach sind Anwender bessere Kritiker und weniger gute Autoren.
Wenn Sie also einen Anwender fragen: »Was möchtest du eigentlich?«, kann er Ihnen viel-
leicht eine umfassende Antwort darauf geben, vielleicht kann er es aber auch nicht. Und
selbst wenn er die Frage nicht beantwortet und wir genau das bauen, worum er gebeten hat,
könnte er sagen: »Okay, du hast mir zwar genau das geliefert, worum ich gebeten hatte,
aber jetzt, nachdem ich es gesehen habe, möchte ich doch etwas anderes.« Sicher haben Sie
das auch schon mal erlebt.
Besser wäre es, die Anwender in das Team, das festlegt, was gebaut werden soll und den
Entwicklungsprozess anschließend ständig überwacht, mit einzubeziehen. Um dieses Maß
an aktiver Beteiligung zu fördern, nutzen manche Organisationen Workshops zum Schrei-
ben von User Stories als wichtigste Methode, um wenigstens die ersten Stories zu erhalten.
Manche greifen auch auf Story Maps zurück, um einen anwenderzentrierten Kontext für
ihre Stories zu erhalten. Ich werde beide Techniken nachfolgend kurz beschreiben.

5.9.1 Workshop zum Schreiben von User Stories


Das Ziel eines solchen Workshops besteht darin, gemeinsam nach Ideen für den
gewünschten Geschäftswert zu suchen und User-Story-Platzhalter für das anzulegen, was
das Produkt oder der Dienst leisten soll.
Der Workshop bezieht häufig den Product Owner, den ScrumMaster und das Entwick-
lungsteam sowie interne und externe Stakeholder ein. Die meisten Workshops dauern zwi-
schen einigen Stunden und einigen Tagen. Ich habe selten längere Workshops erlebt und
ich glaube auch nicht, dass sie länger sein sollten – es soll schließlich nicht im Voraus
schon ein kompletter und lückenloser Satz von User Stories entstehen (vergleichbar einer
vollständigen Anforderungsspezifikation in einem sequenziellen Entwicklungsprojekt).
Vielmehr hat der Workshop üblicherweise einen besonderen Fokus. Ich verbinde z.B. oft
schon die erste Release-Planung mit einem Workshop, um Story-Kandidaten für die kom-
mende Version zu generieren (mehr dazu in Kapitel 18).
Ist es der erste Workshop, analysiere ich zuerst die unterschiedlichen Benutzerrollen für
unsere User Stories (»Als <Benutzerrolle> möchte ich . . .«). Natürlich kann es sein, dass
die Mitarbeiter aus dem Marketing oder der Marktforschung bereits vor dem Workshop
eine gute Definition unserer Benutzer geschaffen haben.
Darüber hinaus könnten wir auch prototypische Personen einsetzen, die die Kernmerk-
male einer Rolle repräsentieren. So könnte z.B. »Lilly« mit der ihr zugeordneten Beschrei-
bung die Person sein, die der Rolle einer sieben- bis neunjährigen Spielerin eines
Videospiels für Mädchen entspricht. Sobald Lilly definiert ist, würden wir Stories schrei-
ben, in denen sie die Position der Benutzerrolle einnimmt, anstatt viel abstrakter über
»junge weibliche Spieler« zu schreiben, z.B.: »Als Lilly möchte ich zwischen vielen unter-
schiedlichen Kleidern wählen können, um meinen Avatar nach meinem Geschmack gestal-
ten zu können.«

132
5.9
Stories sammeln

Während des Workshops gibt es keine Standardmethode zum Generieren von User Stories.
Manche Teams bevorzugen es, sich von oben nach unten (Top-down) vorzuarbeiten, andere
gehen lieber von unten nach oben (Bottom-up) vor. Beim Top-down-Ansatz beginnt das
Team mit einer großen Geschichte (wie einem literarischen Epos) und konzentriert sich
dann darauf, aus diesem Epos eine vernünftige Sammlung kleinerer Stories zu erstellen.
Alternativ kann man sich aber auch von unten nach oben durcharbeiten und sofort damit
beginnen, sich Stories auszudenken, die mit der nächsten Version eines existierenden Sys-
tems zusammenhängen. Es gibt kein richtiges oder falsches Vorgehen. Nutzen Sie den
Ansatz, der für Sie gut funktioniert, oder wechseln Sie, um das Beste aus beiden Varianten
herauszuholen.

5.9.2 Story Mapping


Das Story Mapping ist eine von Jeff Patton (Patton 2009) vorgestellte Technik, die eine
anwenderzentrierte Perspektive zum Generieren eines Satzes von User Stories einnimmt.
Die zugrundeliegende Idee besteht darin, allgemeinere Benutzeraktivitäten in einen
Arbeitsablauf zu zerlegen, der dann weiter in eine Reihe detaillierter Aufgaben aufgeteilt
werden kann (siehe Abbildung 5.13).

Epic Epic
Kaufe ein Produkt

Arbeitsablauf oder Abfolge der Aufgaben (im Zeitverlauf)

Theme Theme Theme Theme Theme


Suche nach Organisiere
Produkt Einkaufswagen

Story Story Story Story Story


Suche nach Namen Zu Einkaufswagen
hinzufügen

Story Story Story Story


Priorität

Suche nach Farbe Aus Einkaufswagen


entfernen

Story Story
Suche nach Autor Wageninhalt
zusammenrechnen

Story
Suche nach ISBN

Abb. 5.13: Story Map

133
Kapitel 5
Anforderungen und User Stories

Patton benutzt Begriffe wie Aktivität, Aufgabe und Teilaufgabe, um die Hierarchie innerhalb
einer Story Map zu beschreiben. Um bei der bisher verwendeten Terminologie zu bleiben,
benutze ich hier auch weiterhin die Begriffe Epic, Theme und sprintfähige Story.
Auf der höchsten Ebene befinden sich die Epics, die die großen Aktivitäten von messbarem
wirtschaftlichem Wert für den Benutzer repräsentieren – z.B. das Epic »Kaufe ein Pro-
dukt«.
Als Nächstes denken wir über die Abfolge oder den normalen Arbeitsablauf der Benutzer-
aufgaben nach, aus denen das Epic besteht (repräsentiert durch Themes – sprich Samm-
lungen zusammenhängender Stories). Wir platzieren die Themes entlang einer Zeitlinie,
in der diejenigen, die frühzeitiger im Arbeitsablauf auftreten, links von denen postiert wer-
den, die erst später auftauchen. So würde z.B. das Theme »Suche nach Produkt« links vom
Theme »Organisiere Einkaufswagen« stehen.
Jedes Theme wird dann in eine Reihe umsetzbare Stories zerlegt, die vertikal in der Reihen-
folge ihrer Priorität angeordnet werden (eigentlich in der Reihenfolge ihrer Erwünschtheit,
da es unwahrscheinlich ist, dass die Stories schon geschätzt wurden und wir die endgültige
Priorität erst bestimmen können, wenn wir die Kosten kennen). Nicht alle Stories inner-
halb eines Themes müssen in dieselbe Version aufgenommen werden. So könnte die Story
»Suche nach Farbe« in der ersten Version fehlen, während »Suche nach Namen« vermut-
lich enthalten wäre.
Das Story Mapping kombiniert die Konzepte des anwenderzentrierten Designs mit der
Story-Zerlegung. Gute Story Maps zeigen einen Aktivitäts-Flow aus Sicht des Benutzers
und liefern einen Kontext zum Verständnis der einzelnen Stories und deren Relation zu
größeren Kundenwerteinheiten.
Selbst wenn Sie kein formales Story Mapping durchführen, finde ich die Idee von Arbeits-
abläufen in meinen Workshops immer ganz hilfreich. Sie fokussieren die Diskussion auf
das Schreiben von Stories, die dem Benutzer einen kompletten Arbeitsablauf liefern sollen,
der für ihn von Nutzen ist. Mit dem Kontext des Arbeitsablaufs ist es einfacher festzustel-
len, ob wir in diesem Zusammenhang irgendwelche wichtigen Stories vergessen haben.
Ein Unterschied zwischen den traditionellen Workshops zum Schreiben von Stories und
dem Story Mapping besteht darin, dass wir uns während des Workshops vorrangig darauf
konzentrieren, Stories zu generieren, und weniger darauf, sie zu priorisieren (das ist die
vertikale Position der umsetzbaren Stories in einer Story Map). Wir könnten das Story Map-
ping deshalb als ergänzende Technik zum Workshop nutzen, die uns hilft, die Prioritäten
der Stories zu visualisieren. Story Maps bieten eine zweidimensionale Darstellung eines
Product Backlogs – im Gegensatz zur traditionell linearen (eindimensionalen) Darstellung.

5.10 Abschließende Bemerkungen


In diesem Kapitel habe ich gezeigt, dass Anforderungen in einem Scrum-Projekt anders
gehandhabt werden als in einem traditionellen, sequenziellen Entwicklungsprojekt. In
einem Scrum-orientierten Entwicklungsprozess schaffen wir Platzhalter für die Anforde-
rungen, die als Product-Backlog-Elemente bezeichnet werden. Diese Elemente werden häu-
fig in Form von User Stories ausgedrückt und durchlaufen den Scrum-Prozess mit einem
deutlichen Fokus auf Gesprächen als methodischem Instrument, um die Details der Anfor-

134
5.10
Abschließende Bemerkungen

derungen genauer herauszuarbeiten. Wir nutzen außerdem eine Strategie der progressiven
Verfeinerung großer, weniger detaillierter Stories in kleinere, detailliertere Stories, und
zwar zum Zeitpunkt des Bedarfs an diesen Stories.
Außerdem habe ich den formalen Aufbau von User Stories im Kontext der Methode »Karte,
Gespräch und Bestätigung« (Card, Conversation und Confirmation) vorgestellt und aufge-
zeigt, wie man mit ihrer Hilfe den Geschäftswert auf unterschiedlichen Abstraktionsebe-
nen darstellt. Anschließend erklärte ich, wie man anhand der INVEST-Kriterien feststellen
kann, ob man gute User Stories hat und erläuterte die Methoden für den Umgang mit
nichtfunktionalen Anforderungen und Aktivitäten zum Wissenserwerb. Zum Schluss
folgte eine Diskussion über das Sammeln von User Stories. Dabei konzentrierte ich mich
auf Workshops zum Schreiben von Stories und auf das Story Mapping. Im nächsten Kapitel
befasse ich mich mit dem Product Backlog.

135
Kapitel 6

Das Product Backlog

In diesem Kapitel beschreibe ich die wichtige Rolle, die das Product Backlog in einem
Scrum-Entwicklungsprojekt einnimmt. Ich beginne mit der Beschreibung der unterschied-
lichen Arten von Elementen, die Sie normalerweise in einem Product Backlog finden.
Danach stelle ich vier Merkmale eines guten Product Backlogs vor und zeige auf, wie Sie
mit einer guten Backlog-Pflege (»Grooming«) sicherstellen, dass diese Merkmale erreicht
werden. Anschließend erläutere ich, weshalb das Product Backlog ein Schlüsselelement
beim Organisieren eines schnellen, flexiblen Workflows sowohl auf Versions- als auch auf
Sprint-Ebene ist. Und zum Schluss erfahren Sie, wie Sie feststellen können, welche und
wie viele Product Backlogs Sie haben sollten.

6.1 Überblick
Das Product Backlog ist eine priorisierte Liste der gewünschten Produktfunktionalität. Es
stellt eine zentralisierte und gemeinsame Vereinbarung dessen dar, was gebaut werden und
in welcher Reihenfolge dies erfolgen soll. Es ist ein deutlich sichtbares Artefakt im Herzen
des Scrum-Frameworks, das für alle Projektteilnehmer erreichbar ist (siehe Abbildung 6.1).

Daily Scrum

Sprint-Planung
Sprint Backlog

Product Backlog
Sprint-Ausführung

Pflege
Potenziell
auslieferungsfähiges
Produktinkrement

Sprint Review
Sprint-Retrospektive

Abb. 6.1: Das Product Backlog ist das Herzstück des Scrum-Frameworks

137
Kapitel 6
Das Product Backlog

Immer wenn ein Produkt oder System gebaut, erweitert oder unterstützt wird, gibt es auch
ein Product Backlog.

6.2 Product-Backlog-Elemente
Das Product Backlog besteht aus Product-Backlog-Elementen (Product Backlog Items), die
ich im Folgenden als PBIs, Backlog-Elemente oder einfach nur Elemente bezeichne (siehe
Abbildung 6.2).

Element Größe

Funktionen

Defekte

Product-Backlog-
Elemente (PBIs)
Technische Arbeit

Wissenserwerb

Abb. 6.2: Product-Backlog-Elemente

Die meisten PBIs sind Funktionen – Elemente mit einer Funktionalität, die einen greifba-
ren Wert für den Benutzer oder den Kunden haben. Oft werden sie als User Stories aufge-
schrieben (obwohl Scrum das Format der PBIs nicht vorgibt). Beispiele für Funktionen
sind etwas Brandneues (ein Login-Bildschirm für eine neue Website) oder eine Änderung
an einer vorhandenen Funktion (ein benutzerfreundlicherer Login-Bildschirm für eine vor-
handene Website). Andere PBIs sind unter anderem Defekte, die einer Reparatur bedürfen,
technische Verbesserungen, Arbeiten zum Wissenserwerb und alle anderen Tätigkeiten,
die der Product Owner für werthaltig erachtet. In Tabelle 6.1 finden Sie Beispiele für die
verschiedenen PBI-Typen.

138
6.3
Merkmale guter Product Backlogs

PBI-Typ Beispiel
Funktion Als Vertreter des Kundendienstes möchte ich ein Ticket für ein Kunden-
problem anlegen können, damit ich eine Support-Anfrage eines Kunden
aufzeichnen und organisieren kann.
Änderung Als Vertreter des Kundendienstes möchte ich, dass die Standardsortie-
rung der Suchergebnisse nach dem Nachnamen erfolgt und nicht nach
der Ticketnummer, damit es leichter ist, ein bestimmtes Support-Ticket
zu finden.
Defekt Behebe Defekt #256 im Fallbearbeitungs- bzw. Ticket-System, damit in
Suchbegriffen enthaltene Sonderzeichen die Kundensuchläufe nicht
zum Absturz bringen.
Technische Wechsle zur neuesten Version des Oracle DBMS.
Verbesserung
Wissenserwerb Schaffe einen Prototypen oder ein Konzept zweier Architekturen und
führe drei Tests durch, um festzustellen, welcher Ansatz für unser Pro-
dukt besser wäre.
Tabelle 6.1: Beispiele für Product-Backlog-Elemente

6.3 Merkmale guter Product Backlogs


Gute Product Backlogs besitzen ähnliche Merkmale. Roman Pichler (Pichler 2010) und
Mike Cohn schufen das Akronym DEEP, unter dem sie mehrere wichtige Merkmale von
guten Product Backlogs zusammenfassen: Detailed appropriately (ausreichend detailliert),
Emergent, Estimated (geschätzt) und Prioritized (priorisiert). So wie die INVEST-Kriterien
(siehe Kapitel 5) nützlich sind, um die Qualität einer User Story zu beurteilen, lässt sich mit
den DEEP-Kriterien feststellen, ob ein Product Backlog gut strukturiert ist.

6.3.1 Detailed appropriately (ausreichend detailliert)


Nicht alle Elemente in einem Product Backlog liegen gleichzeitig mit dem gleichen Detail-
lierungsgrad vor (siehe Abbildung 6.3).
PBIs, an denen wir bald zu arbeiten planen, sollten sich im Backlog oben befinden sowie
klein und sehr detailliert sein, so dass sie in einem der nächsten Sprints abgearbeitet wer-
den können. PBIs, deren Bearbeitung nicht unmittelbar bevorsteht, sollten unten im Back-
log liegen und können größer sowie weniger detailliert sein.
Wenn wir der Bearbeitung eines größeren PBI, wie etwa eines Epics, näher kommen, zerle-
gen wir diese Story in eine Sammlung kleinerer, sprintfähiger Stories. Das kann zu dem
Zeitpunkt geschehen, an dem dies erforderlich wird (just-in-time). Verfeinern wir zu früh,
dann wenden wir sehr viel Zeit auf, um die Details zu ermitteln und setzen die Story am
Ende vielleicht gar nicht um. Warten wir zu lange, behindern wir das Einfließen der PBIs in
den Sprint und bremsen das Team aus. Also müssen wir den richtigen Ausgleich zwischen
gerade rechtzeitig und noch genug Zeit finden.

139
Kapitel 6
Das Product Backlog

Product-Backlog-
Elemente
Kleine Größe Werden bald bearbeitet
Viele Details

Große Größe
Wenige Details Werden nicht so bald bearbeitet

Abb. 6.3: Product-Backlog-Elemente sind unterschiedlich groß

6.3.2 Emergent
Solange ein Produkt entwickelt oder gepflegt wird, ist das Product Backlog niemals voll-
ständig oder »auf Eis gelegt«. Vielmehr wird es auf der Grundlage eines kontinuierlichen
Flusses wirtschaftlich wertvoller Informationen ständig aktualisiert. So könnten sich z.B.
die Kundenwünsche ändern, Konkurrenten könnten einen unerwarteten waghalsigen Vor-
stoß unternehmen oder es könnten unvorhergesehene technische Probleme auftreten.
Und das Product Backlog muss sich stets an derartige Geschehnisse anpassen.
Die Struktur des Product Backlogs entwickelt sich somit im Laufe der Zeit immer weiter.
Wenn neue Elemente hinzugefügt oder vorhandene Elemente verfeinert werden, muss der
Product Owner das Product Backlog anhand der hinzugewonnenen Informationen neu
ausrichten und die Prioritäten der Elemente entsprechend anpassen.

6.3.3 Estimated (geschätzt)


Für jedes Product-Backlog-Element wird eine Größenschätzung vorgenommen, die den
Aufwand widerspiegelt, der nötig ist, um das Element zu entwickeln (siehe Abbildung 6.4).

140
6.3
Merkmale guter Product Backlogs

Element Größe
2
3 Jedes Element hat eine Größenschätzung
2
5 Die meisten Schätzungen erfolgen in Form von
13 Story-Punkten oder Idealtagen

13

20

20

40

L Sehr große Elemente im unteren Teil haben vermutlich


noch keine Größenschätzung oder eine Schätzung
in Form von T-Shirt-Größen
XL

Abb. 6.4: Product-Backlog-Elemente sind geschätzt

Diese Schätzungen dienen dem Product Owner als Ausgangswerte, um die Priorität (und
damit die Position) des PBI im Product Backlog zu ermitteln. Ein großes PBI mit hoher Pri-
orität (nahe der Spitze des Backlogs) signalisiert dem Product Owner, dass eine zusätzliche
Verfeinerung dieses Elements erforderlich ist, bevor es in einen der nächsten Sprints über-
führt werden kann.
Wie in Kapitel 7 noch genauer ausgeführt wird, werden die meisten PBIs entweder in
Story-Punkten oder in Idealtagen geschätzt. Diese Größenschätzungen müssen einigerma-
ßen akkurat, aber auch nicht übermäßig genau sein. Da Elemente nahe der Spitze des
Backlogs kleiner und detaillierter sind, fallen ihre Schätzungen ebenfalls kleiner und exak-
ter aus. Allerdings ist es in der Regel nicht möglich, numerisch akkurate Schätzungen für
größere Elemente (z.B. Epics) im unteren Teil des Backlogs vorzunehmen. Deshalb ziehen
es manche Teams vor, entweder überhaupt keine Schätzungen für diese Elemente vorzu-
nehmen oder sie in Form von T-Shirt-Maßen anzugeben (L, XL, XXL usw.). Bei der Zerle-
gung der größeren Elemente in kleinere Elementen werden sie dann aber natürlich
ebenfalls wieder mit Zahlenwerten geschätzt.

6.3.4 Prioritized (priorisiert)


Das Product Backlog repräsentiert zwar eine priorisierte PBI-Liste, dennoch ist es eher
unwahrscheinlich, dass alle Elemente im Backlog mit einer Priorität versehen sind (siehe
Abbildung 6.5).
Sinnvoller ist es, vor allem die kurzfristigen Elemente zu priorisieren, die für die nächsten
Sprints gedacht sind. Gegebenenfalls ist es auch hilfreich, das Backlog so weit zu priorisie-

141
Kapitel 6
Das Product Backlog

ren, wie man glaubt, in Release 1 zu kommen. Grundsätzlich lohnt es sich aber vermutlich
nicht, über diesen Punkt hinaus mehr als eine grobe Priorisierung vorzunehmen.

Elemente hoher Priorität Element

Elemente in diesem Bereich sind


Release 1 (zumeist) priorisiert

Je nach angestrebtem Release


Release 2 (Release 2 oder Release 3)
könnte man in diesem Bereich
Funktionen priorisieren

Hier wird kaum Arbeit in die


Release 3
Priorisierung der Elemente
künftiger Releases gesteckt
Elemente niedriger Priorität

Abb. 6.5: Product-Backlog-Elemente sind priorisiert

Wir könnten z.B. erklären, dass ein Element entsprechend unserer Produkt-Roadmap für
Release 2 oder Release 3 gedacht ist. Sollten wir jedoch noch in einer frühen Phase der
Funktionsentwicklung für Release 1 stecken, wäre unsere wertvolle Zeit nicht gut investiert,
wenn wir uns an dieser Stelle Gedanken über die Prioritäten von Funktionen für die Relea-
ses 2 oder 3 machen würden. Möglicherweise kommt es ja gar nicht zu Release 2 oder
Release 3 oder vielleicht ändern wir unser Konzept im Laufe der Entwicklung von Release 1
ganz grundlegend. Dann wäre die Zeit, die wir mit einer Priorisierung so weit entfernter
Elemente verbracht haben, schlicht und ergreifend vergeudet.
Sollten im Laufe einer Entwicklung neue Elemente auftauchen, ist natürlich der Product
Owner dafür verantwortlich, diese an der passenden Stelle in das Backlog einzufügen.

6.4 Pflege
Um ein gutes, den DEEP-Kriterien entsprechendes Product Backlog zu erhalten, müssen
wir es proaktiv organisieren, verwalten, administrieren und pflegen.

6.4.1 Was bedeutet Pflege?


Die Pflege (»Grooming«) betrifft vor allem drei wichtige Aktivitäten: das Erzeugen und Ver-
feinern (sprich die Ergänzung von Details) von PBIs, das Schätzen von PBIs und das Prio-
risieren von PBIs.

142
6.4
Pflege

Abbildung 6.6 veranschaulicht einige spezielle Pflegeaufgaben und zeigt, wie sie die Struk-
tur des Product Backlogs beeinflussen.

Element Größe
3 Schätzen
Element einfügen

Elemente neu priorisieren

Ursprüngliches großes Element Elemente verfeinern

Element löschen

Abb. 6.6: Die Pflege (»Grooming«) verändert die Form des Product Backlogs.

Damit ihre Reihenfolge im Backlog bestimmt und entschieden werden kann, ob eine wei-
tere Verfeinerung erforderlich ist, müssen alle PBIs zu gegebener Zeit geschätzt werden.
Ebenso müssen mit dem Bekanntwerden relevanter Informationen neue Elemente erzeugt
und in der richtigen Reihenfolge in das Backlog eingefügt werden. Und wenn sich Prioritä-
ten verschieben, zieht das natürlich eine entsprechende Anpassung der Elementeanord-
nung im Backlog nach sich. Sobald größere Elemente näher heranrücken, müssen wir
diese in eine Ansammlung kleinerer Elemente zerlegen. Wir könnten außerdem entschei-
den, dass ein bestimmtes Element im Product Backlog eigentlich nicht gebraucht wird – in
diesem Fall entfernen wir es.

6.4.2 Wer führt die Pflege durch?


Die Pflege des Product Backlogs ist eine fortlaufende Gemeinschaftsarbeit, die vom Pro-
duct Owner angeführt wird und eine maßgebliche Mitwirkung sowohl der internen und
externen Stakeholder als auch des ScrumMasters und des Entwicklungsteams verlangt
(siehe Abbildung 6.7).
Am Ende gibt es aber nur einen hauptsächlichen Entscheider bei der Pflege: den Product
Owner. Gute Product Owner sind sich bewusst, dass die gemeinsame Pflege den wichtigen
Dialog zwischen allen Teilnehmern fördert und von der kollektiven Intelligenz sowie Mei-
nungen einer mannigfaltigen Personengruppe profitiert. Auf diese Weise werden wichtige

143
Kapitel 6
Das Product Backlog

Informationen aufgedeckt, die ansonsten verloren gehen. Gute Product Owner wissen
außerdem, dass durch das Einbeziehen verschiedener Teammitglieder in die Pflege sicher-
gestellt wird, dass alle Beteiligten das Product Backlog besser verstehen und weniger Zeit
durch Missverständnisse vergeudet wird. Solche gemeinsamen Anstrengungen sind
zudem gut geeignet, um die seit Langem bestehende Lücke zwischen dem Management
und dem technischen Personal zu schließen.

Interne Stakeholder
(Unternehmenseigentümer, Manager,
Product Owner
Programmmanagement) ScrumMaster

Scrum-Team

Product Backlog

Priorisieren

Anlegen Schätzen
und Verfeinern

Externe Stakeholder Entwicklungsteam


(Kunden, Anwender, Partner,
Regulierungsbehörde)

Abb. 6.7: Die Pflege ist eine Gemeinschaftsarbeit.

Stakeholder sollten sich je nach Art der Organisation und des Projekts ausreichend Zeit für
die Pflege freihalten. Als Faustregel gilt, dass das Entwicklungsteam bis zu 10% seiner Zeit
in einem Sprint reservieren sollte, um dem Product Owner bei der Pflege des Backlogs zur
Hand zu gehen. Das Team nutzt diese Zeit, um beim Anlegen oder der Beurteilung neu
aufgekommener Backlog-Elemente sowie der progressiven Verfeinerung größerer Ele-
mente in kleinere zu helfen. Außerdem schätzt es die Größe der Product-Backlog-Elemente
ein und unterstützt den Product Owner dabei, diese auf der Grundlage der technischen
Abhängigkeiten und Ressourcenbeschränkungen zu priorisieren.

6.4.3 Wann findet die Pflege statt?


Das Scrum-Framework weist nur darauf hin, dass die Pflege durchgeführt werden muss –
es gibt jedoch nicht vor, wann das geschehen soll. Wann also findet die Pflege statt?
Bei einer sequenziellen Entwicklung versuchen wir, bereits im Voraus eine vollständige
und detaillierte Beschreibung der Anforderungen zu erhalten. Und nachdem diese dann
bestätigt wurden, findet deren Pflege – aus eben diesem Grund – kaum noch statt. In vie-
len Organisationen dürfen solche gleich zu Anfang eines Projekts festgelegten Anforde-
rungen ausschließlich im Rahmen eines separaten Änderungskontrollprozesses
modifiziert werden – und das wiederum unterbricht den primären Entwicklungsvorgang
(siehe Abbildung 6.8).

144
6.4
Pflege

Komplette Genehmigte
Anforderungen Grund-
Anforderungen Design Bau Test
genehmigen anforderungen
erfassen

Primärer Workflow

Änderungskontrollprozess
Änderung prüfen Anforderungen
außerhalb des primären Änderungs-
und genehmigen und Pläne
Workflows (ungeplante Arbeit) anfrage
aktualisieren

Zeit

Abb. 6.8: Pflege abseits des primären Workflows in sequenziellen Projekten

Daher ist die Pflege in einem sequenziellen Entwicklungsverfahren eher die Ausnahme –
eine ungeplante, außerhalb des primären Workflows stattfindende Aktivität, die wir nur
dann durchführen, wenn es unerlässlich ist, weil sie die zügige Auslieferung des Geschäfts-
wertes empfindlich stört.
Wenn wir Scrum einsetzen, gehen wir von einer unsicheren Umgebung aus und müssen
daher darauf vorbereitet sein, ständig zu prüfen und uns anzupassen. Wir erwarten, dass
sich das Product Backlog stetig weiterentwickelt und nicht schon früh feststeht – und auch
nur durch einen sekundären Prozess zum Behandeln von unerwünschten Ausnahmesitua-
tionen geändert werden kann. Aus diesem Grund müssen wir dafür sorgen, dass unsere
Pflegeaktivitäten ein wesentlicher, inhärenter Bestandteil unserer Arbeitsorganisation sind.
Abbildung 6.9 zeigt die unterschiedlichen Zeitpunkte, zu denen die Pflege stattfinden
könnte. Eine erste Pflege ist bereits Teil der Release-Planung (Näheres dazu in Kapitel 18).
Während der Produktentwicklung trifft sich der Product Owner mit den Stakeholdern. Wie
oft dies geschieht, hängt davon ab, wie sinnvoll es für eine vernünftige Pflege ist.
Beim Arbeiten mit dem Entwicklungsteam könnte der Product Owner entweder einen
wöchentlichen oder einen einmal pro Sprint stattfindenden Pflege-Workshop ansetzen.
Dadurch stellt er sicher, dass die Pflege regelmäßig durchgeführt wird. Das Team kann
diese Zeit bei der Sprint-Planung berücksichtigen. Es muss keine Zeit mehr damit ver-
schwendet werden, Ad-hoc-Treffen zu organisieren (um herauszufinden, wann die Leute
Zeit haben, wo ein Raum für das Treffen frei ist usw.).
Manchmal ziehen es Teams auch vor, die Pflege während des gesamten Sprints durchzu-
führen, anstatt einen vorher festgelegten Zeitraum dafür freizuhalten. Sie nehmen sich
nach ihrem Daily Scrum jeweils ein wenig Zeit für kleinere Pflegeaktivitäten, an denen
nicht alle Teammitglieder beteiligt sein müssen. So könnte der Product Owner z.B. nach

145
Kapitel 6
Das Product Backlog

dem Daily Scrum um Hilfe beim Verfeinern einer großen Story bitten und Teammitglieder,
die Bescheid wissen und interessiert sind, bleiben und helfen dem Product Owner. Und
beim nächsten Mal assistieren dann andere Teammitglieder.

Nach Daily Scrum

Workshop während Sprint


Ein wenig im Voraus, dann bei Bedarf
Daily Scrum
Sprint-Planung
Sprint Backlog
Product Backlog
Sprint-Ausführung

Pflege

Potenziell
auslieferungsfähiges
Produktinkrement

Sprint Review
Sprint-Retrospektive

Während Sprint Review

Abb. 6.9: Wann die Pflege stattfindet

Selbst wenn regelmäßige Workshops stattfinden oder sich das Team jeden Tag ein bisschen
Zeit nimmt, um sich das Backlog anzuschauen, werden die meisten Teams automatisch
auch während des Sprint Reviews ein wenig Pflege betreiben. Denn da alle Beteiligten ein
besseres Verständnis dafür entwickeln, wo das Produkt steht und wohin es sich entwickelt,
werden oft auch neue PBIs erzeugt oder vorhandene PBIs neu priorisiert oder entfernt,
falls sie nicht mehr notwendig sind.
Es ist nicht so wichtig, wann die Pflege stattfindet. Entscheidend ist, dass sie gut in die
Scrum-Entwicklungsabläufe integriert ist, damit eine flexible und schnelle Auslieferung
des Geschäftswertes gewährleistet ist.

6.5 Die Definition von Bereit


Die Pflege des Product Backlogs soll dafür sorgen, dass die Element an der Spitze des Back-
logs bereit sind, in einen Sprint überführt zu werden, damit das Entwicklungsteam sich
zuversichtlich dazu verpflichten und sie bis zum Ende des Sprints fertigstellen kann.
Manche Scrum-Teams formalisieren diese Idee, indem sie eine Definition von Bereit erar-
beiten. Stellen Sie sich die Definitionen von »Bereit« und von »Fertig« (siehe Kapitel 4) als

146
6.5
Die Definition von Bereit

zwei Zustände der Product-Backlog-Elemente während eines Sprint-Zyklus vor (siehe


Abbildung 6.10).

Bereit Fertig

Sprint-Ausführung Daily Scrum


Sprint-Planung
Sprint Backlog
Product Backlog

Pflege

Potenziell
auslieferungsfähiges
Produktinkrement

Sprint Review
Sprint-Retrospektive

Abb. 6.10: Die Definition von »Bereit«

Bei beiden Definitionen handelt es sich um Checklisten der Tätigkeiten, die abgeschlossen
werden müssen, bevor man davon sprechen kann, dass ein Product-Backlog-Element den
jeweiligen Zustand angenommen hat. Ein Beispiel für eine Checkliste der Definition von
Bereit sehen Sie in Tabelle 6.2.

Definition von Bereit


S Der Geschäftswert ist klar artikuliert.

S Das Entwicklungsteam hat die Einzelheiten richtig verstanden, so dass es in der Lage
ist, eine fundierte Entscheidung zu treffen, ob es das PBI abschließen kann.
S Abhängigkeiten wurden erkannt und es gibt keine externen Abhängigkeiten, die die
Fertigstellung des PBIs blockieren.
S Das Team hat ausreichend Leute, um das PBI abzuschließen.

S Das PBI ist geschätzt und klein genug, um es in einem Sprint fertigzustellen.

S Die Akzeptanzkriterien sind eindeutig und testbar.

S Die Leistungskriterien, falls es welche gibt, sind definiert und testbar.

S Das Scrum-Team versteht, wie es das PBI beim Sprint Review demonstrieren soll.

Tabelle 6.2: Beispielcheckliste für die Definition von Bereit

147
Kapitel 6
Das Product Backlog

Eine starke Definition von Bereit verbessert die Chance des Scrum-Teams, das Sprint-Ziel
erfolgreich zu erreichen, ganz beträchtlich.

6.6 Flow Management


Das Product Backlog ist ein sehr wichtiges Werkzeug, das es dem Scrum-Team erlaubt,
trotz aller Unsicherheit einen schnellen, flexiblen Werte-Flow zu erreichen. Unsicherheiten
lassen sich nicht vollständig aus der Produktentwicklung beseitigen. Wir müssen davon
ausgehen, dass kontinuierlich neue, wirtschaftlich wichtige Informationen eingehen und
wir die Arbeit (also das Product Backlog) so organisieren müssen, dass diese auf schnelle,
kosteneffektive Weise verarbeitet werden, während wir gleichzeitig einen guten Workflow
aufrechterhalten. Untersuchen wir doch einmal, welche Rolle das Product Backlog für die
Unterstützung eines guten Release und Sprint Flows spielt.

6.6.1 Release Flow Management


Das Product Backlog muss so gepflegt werden, dass es eine laufende Release-Planung
unterstützt (den Funktions-Flow innerhalb einer Version). Wie in Abbildung 6.5 dargestellt,
kann eine Version in Form einer Linie durch das Product Backlog visualisiert werden: Alle
PBIs oberhalb der Linie sollen in dieser Version enthalten sein, die Elemente unterhalb der
Linie nicht.
Ich finde es sinnvoll, das Product Backlog sogar mit zwei Linien für jede Version aufzutei-
len, wie in Abbildung 6.11 zu sehen.

Element

Must have

Nice to have

Won´t have

Abb. 6.11: Blick auf das Product Backlog aus Release-Sicht

148
6.6
Flow Management

Diese zwei Linien unterteilen das Backlog in drei Bereiche: muss man haben, wäre nett und
wird man nicht haben. Die Must-have-Funktionen sind die Elemente, die im kommenden
Release einfach vorhanden sein müssen, weil wir sonst keine brauchbare Kundenversion
bekommen. Die Nice-to-have-Funktionen repräsentieren Elemente, die wir für die nächste
Version anstreben und gern einbinden würden. Falls uns jedoch die Zeit oder andere Res-
sourcen ausgehen, könnten wir die Nice-to-have-Funktionen fallenlassen und hätten trotz-
dem ein brauchbares Produkt. Die Wird-man-nicht-haben-Funktionen sind Elemente, die
wir ausdrücklich nicht in die aktuelle Version aufnehmen werden. Die zweite Linie – also
diejenige, die die Wird-man-nicht-haben-Elemente von den anderen trennt – ist identisch
mit der Release-1-Linie aus Abbildung 6.5.
Ein auf diese Art geführtes Backlog hilft uns auch bei der laufenden Release-Planung, wie
ich in Kapitel 18 erläutern werde.

6.6.2 Sprint Flow Management


Die Pflege des Product Backlogs ist für eine effektive Sprint-Planung und den daraus resul-
tierenden Funktions-Flow in einen Sprint unerlässlich. Wenn das Product Backlog ange-
messen detailliert ist, sollten die Elemente an der Spitze des Backlogs deutlich beschrieben
und prüfbar sein.
Bei der Pflege für einen guten Sprint Flow hilft es, wenn man das Product Backlog als eine
Pipeline für die Anforderungen betrachtet, die in die Sprints einfließen, um vom Team ent-
worfen, gebaut und getestet zu werden (siehe Abbildung 6.12).
In dieser Abbildung sehen wir, dass größere, weniger gut verstandene Anforderungen in
die Pipeline überführt werden. Während sie die Pipeline durchlaufen und der Zeitpunkt
näher rückt, an dem sie in die Bearbeitung gelangen, werden sie durch die Pflegeaktivitäten
zunehmend verfeinert. Auf der rechten Seite der Pipeline befindet sich das Team. Wenn ein
Element aus der Pipeline hinausfließt, muss es bereit sein – so detailliert, dass das Team es
verstehen und bequem während eines Sprints fertigstellen und ausliefern kann.

Flow

Sprint-Planung
Bereit

Abb. 6.12: Das Product Backlog als eine Pipeline aus Anforderungen

149
Kapitel 6
Das Product Backlog

Falls zwischen dem Hinein- und dem Hinausfließen der Elemente jemals eine Unstimmig-
keit auftritt, haben wir ein Problem: Rücken die gepflegten, detaillierten und zur Umset-
zung bereiten Elemente zu langsam nach, trocknet die Pipeline irgendwann aus und das
Team kann den nächsten Sprint nicht mehr planen und ausführen (eine große Unterbre-
chung oder gar Verschwendung des Scrum-Workflows). Bringt man andererseits zu viele
Elemente zur Verfeinerung in die Pipeline, wird ein großer Bestand an detaillierten Anfor-
derungen geschaffen, den wir überarbeiten oder verwerfen müssen, wenn wir irgendwann
über weiterführende Informationen verfügen (ein großer Quell der Verschwendung). Die
ideale Situation besteht deshalb darin, gerade genügend Elemente im Product Backlog zu
haben, um einen gleichmäßigen Flow zu erzeugen, aber nicht so viele, dass etwas ver-
schwendet wird.
Scrum-Teams gehen deshalb unter anderem so vor, dass sie einen angemessenen Bestand
an gepflegten und zur Umsetzung bereiten Elementen im Backlog haben. Eine Heuristik,
die für viele Teams zu funktionieren scheint, ist, dass man Stories für etwa zwei bis drei
Sprints bereithält. Falls das Team z.B. etwa 5 PBIs pro Sprint erledigen kann, dann stellt es
sein Backlog bei der Pflege so ein, dass jederzeit 10 bis 15 PBIs bereit sind. Dieser zusätzli-
che Bestand stellt sicher, dass die Pipeline nicht leerläuft und bietet dem Team außerdem
die nötige Flexibilität, falls es aus Kapazitätsgründen oder anderen sprintspezifischen Ein-
schränkungen außer der Reihe PBIs auswählen muss (mehr dazu in Kapitel 19).

6.7 Welche und wie viele Product Backlogs?


Wenn ich darüber entscheide, welche und wie viele Product Backlogs gebildet werden müs-
sen, dann beginne ich immer mit einer einfachen Regel: »Ein Produkt, ein Product Back-
log« – das bedeutet, dass jedes Produkt sein eigenes Backlog haben sollte, das eine
produktweite Beschreibung und Priorisierung der notwendigen Arbeiten erlaubt.
Es gibt jedoch Situationen, in denen wir aufpassen müssen, wenn wir diese Regel anwen-
den, um sicherzustellen, dass wir eine praktische, funktionsfähige Product-Backlog-Struk-
tur erhalten. Manchmal ist z.B. nicht klar, was ein Produkt ausmacht. Manche Produkte
sind sehr groß, manchmal haben wir mehrere Teams, die nicht austauschbar sind – dann
wieder gibt es mehrere Produkte und nur ein Team. Schauen wir uns diese Sonderfälle ein-
mal genauer an, um herauszufinden, wie sie unsere Ein-Backlog-Regel beeinflussen.

6.7.1 Was ist ein Produkt?


Ein Problem bei der »Ein Produkt, ein Product Backlog«-Regel ist, dass nicht immer klar
ist, was genau ein Produkt ausmacht. Ist Microsoft Word das Produkt oder ist es einfach
nur eine Facette eines größeren Produkts namens Microsoft Office? Wie verhält sich das,
wenn wir nur die Produkt-Suite verkaufen? Haben wir ein Product Backlog für die Suite
oder haben wir ein Product Backlog für jede einzelne Anwendung in der Suite (siehe Abbil-
dung 6.13)?
Als ich bei IBM arbeitete, lautete die kundenbezogene Antwort auf die Frage »Was ist ein
Produkt?« grundsätzlich »Was auch immer eine eigene Produkt-ID-Nummer (PID)
besitzt«. Das Schöne an dieser Antwort war ihre Einfachheit. IBM verkaufte Produkte aus
einem Katalog. Wenn man also eine PID vergeben konnte, konnten die Verkäufer es auf ein
Bestellformular setzen und deshalb war es ein »Produkt«. Auch wenn die IBM-Antwort

150
6.7
Welche und wie viele Product Backlogs?

übermäßig vereinfacht erscheinen mag, wollen wir sie hier einmal als Ausgangspunkt
benutzen. Ein Produkt ist etwas von Wert, für das ein Kunde etwas bezahlen würde und das
wir einpacken und verkaufen würden.

Product Backlog pro Anwendung Product Backlog für die Suite

Word Office

Excel

Outlook

Abb. 6.13: Das Product Backlog ist mit dem Produkt verknüpft.

Die Anwendung dieser Regel wird komplizierter, wenn wir Komponententeams bilden,
deren Zweck es ist, eine Komponente eines größeren Produkts zu schaffen, das ein Kunde
kaufen würde (in Kapitel 12 finden Sie eine ausführlichere Diskussion zu den Komponen-
tenteams). Als ich z.B. mein portables GPS erwarb, kaufte ich nicht den Routenplaner-
Algorithmus, sondern ein portables Gerät, das mir akkurate grafische und auditive Rich-
tungsanweisungen geben würde. Die Routenplaner-»Komponente« war einfach eine von
vielen, die zusammen ein Gerät bildeten, das ein Kunde wie ich kaufen würde.
Gibt es ein Product Backlog für die Routenplaner-Komponente, falls der GPS-Hersteller ein
entsprechendes Team gebildet hat, um diese Komponente zu entwickeln? Oder gibt es nur
ein Product Backlog für das gesamte GPS, in das die Funktionen zur Routenplanung einge-
woben sind?
Noch interessanter ist die Fragestellung: Was wäre, wenn die Routenplaner-Komponente in
mehrere GPS-Produkte (jeweils mit einer eigenen PID) eingebunden werden könnte?
Wären wir eher geneigt, ein eigenes Product Backlog für eine Komponente zu schaffen,
wenn diese in mehreren Geräteprodukten eingesetzt werden könnte?

151
Kapitel 6
Das Product Backlog

Sie sehen: Wenn wir erst einmal anfangen, diese Fragen zu stellen, können wir immer tie-
fer graben. Um uns aus dieser Abwärtsspirale zu befreien, sollten wir daran denken, dass
es unser Ziel ist, die Anzahl der Komponententeams und damit den Bedarf für Komponen-
ten-Product-Backlogs zu minimieren. Konzentrieren Sie sich auf das, was Sie herstellen,
um es zu verpacken, auszuliefern und damit den Kunden zu erfreuen, und passen Sie Ihr
Product Backlog entsprechend an.

6.7.2 Große Produkte – hierarchische Backlogs


Ich bevorzuge nach Möglichkeit selbst für ein großes Produkt wie Microsoft Office nur ein
Product Backlog. Allerdings müssen wir praktisch sein, wenn wir diese Regel anwenden.
Wollten wir mit einer großen Produktentwicklung etwa ein Mobiltelefon herstellen, dann
hätten wir möglicherweise Dutzende oder Hunderte von Teams, deren Arbeit am Ende ein
marktfähiges Gerät ergeben soll. Es ist einfach nicht praktisch (oder notwendig) zu versu-
chen, die PBIs all dieser Teams in ein kontrollierbares Product Backlog zu legen.
Zunächst einmal arbeiten nicht alle diese Teams in verwandten Bereichen. So könnten wir
z.B. sieben Teams haben, die an dem audiovisuellen Player für das Telefon arbeiten, wäh-
rend weitere acht Teams an dem Webbrowser arbeiten. Jeder dieser Bereiche liefert einen
erkennbaren Wert für den Kunden und die Arbeit jedes Bereichs kann auf einem Detailni-
veau organisiert und priorisiert werden, das mehr oder weniger unabhängig von den ande-
ren Bereichen ist.
Aufgrund dieser Merkmale lösen die meisten Organisationen das Problem bei großen Pro-
dukten mit hierarchischen Backlogs (siehe Abbildung 6.14).

Bereichs-Backlogs Bereichsteams

Product Backlog

Abb. 6.14: Hierarchische Product Backlogs

152
6.7
Welche und wie viele Product Backlogs?

Ganz oben in der Hierarchie haben wir weiterhin das eine Product Backlog, das sehr grob
die Funktionalität (möglicherweise in Form eines Epics) des Produkts beschreibt. Auf die-
ser Ebene gäbe es dann auch den Chief Product Owner, wie ich in Kapitel 9 näher erläutern
werde. Alle zusammengehörenden Funktionsbereiche besitzen jeweils ein eigenes Back-
log. Der Audiovideo-Player-Bereich hat also ein Backlog, das die PBIs für die sieben Teams
enthält, die in diesem Bereich arbeiten. Die PBIs auf Funktionsebene sind wahrscheinlich
im Verhältnis kleiner (Funktions- oder Story-Größe) als die entsprechenden Elemente im
Product Backlog. In Kapitel 12 stelle ich das Release-Train-Konzept vor, das auf einem drei-
stufigen Unternehmens-Backlog-Modell beruht: Portfolio-Backlog (enthält Epics), Pro-
gramm-Backlog (enthält die Funktionen) und die Team-Backlogs (enthalten sprintfähige
User Stories).

6.7.3 Mehrere Teams – ein Product Backlog


Die »Ein Produkt, ein Product Backlog«-Regel soll allen Teams, die an dem Produkt arbei-
ten, gestatten, sich ein Product Backlog zu teilen. Indem wir alle Teams an einem einzigen
Backlog ausrichten, können wir unsere wirtschaftlichen Gegebenheiten auf Produktebene
optimieren. Das gelingt uns, weil wir alle Funktionen in ein Backlog legen und sie sozusa-
gen um die Priorität kämpfen lassen. Damit stellen wir sicher, dass die Funktionen, die aus
Sicht des Gesamtprodukts die höchste Priorität haben, erkannt und zuerst bearbeitet wer-
den.
Wenn all unsere Teams austauschbar sind, so dass jedes Team an einem beliebigen PBI im
gemeinsamen Backlog arbeiten kann, machen wir uns die Priorisierung zunutze, die durch
ein einziges Product Backlog ermöglicht wird. Was aber tun wir, wenn die Teams nicht aus-
tauschbar sind? So kann z.B. ein Team, das an der Layout-Engine von Microsoft Word
arbeitet, nicht einfach zur Arbeit an der Rechen-Engine von Microsoft Excel umgesetzt wer-
den. Manchmal sind Teams nicht in der Lage, an jedem Element im Product Backlog zu
arbeiten, auch wenn das für uns ideal wäre.
Aus diesem Grund müssen wir ermitteln, welche Elemente aus dem Product Backlog die
einzelnen Teams tatsächlich bearbeiten können. Konzeptionell brauchen wir also teamspe-
zifische Backlogs. In der Praxis legen wir jedoch auf der Teamebene natürlich keine Pro-
duct Backlogs an. Stattdessen haben wir teamspezifische Sichten des gemeinsamen
Backlogs.
Wie Abbildung 6.15 zeigt, gibt es allerdings ein Backlog, das so strukturiert ist, dass Teams
nur die Funktionen sehen und zum Bearbeiten auswählen können, für die ihre Fähigkeiten
relevant sind.
Beachten Sie in Abbildung 6.15 außerdem, dass das höchste Element im Team-C-Backlog
von einem Element abgeleitet ist, das im Backlog auf Produktebene keine besonders hohe
Priorität genießt. Wären die Teams austauschbar, würde das Backlog von Team C höher pri-
orisierten Elementen im Backlog auf Produktebene entsprechen. Dieser Mangel an Flexibi-
lität ist der Grund, weshalb viele Organisationen ein hohes Maß an Shared Code
Ownership (d.h., jeder kennt den gesamten Code und darf ihn ändern) und stärker aus-
tauschbare Teams anstreben: Sie wollen sich die Vorteile zunutze machen, die es mit sich
bringt, wenn man Teams hat, die an mehreren Bereichen des Produkts arbeiten können.

153
Kapitel 6
Das Product Backlog

Teamspezifische Sicht
des Product Backlogs Nicht austauschbare Teams
Team A

Product Backlog

Team B

Team C

Abb. 6.15: Teamspezifische Sicht des Product Backlogs

6.7.4 Ein Team – mehrere Produkte


Wenn eine Organisation mehrere Produkte hat, dann hat sie auch mehrere Product Back-
logs. Am besten kommt man mit mehreren Product Backlogs zurecht, wenn ein oder meh-
rere Teams ausschließlich an jeweils einem der Product Backlogs arbeiten (siehe Abbildung
6.16 links).
Manchmal bezieht ein Team seine Arbeit jedoch aus mehreren Product Backlogs (siehe
Abbildung 6.16 rechts). Wie ich in Kapitel 11 ausführen werde, sollte unser Ziel darin beste-
hen, die Anzahl der zu bearbeitenden Projekte für die Teams oder Teammitglieder zu mini-
mieren. Die erste und häufig auch beste Lösung ist hierbei, einem Team jeweils immer nur
ein einziges Produkt zuzuweisen, so dass es in jedem Sprint nur die Elemente aus einem
Product Backlog bearbeitet.
Sollten wir jedoch durch organisatorische Hürden gezwungen sein, das Team an mehreren
Produkten gleichzeitig arbeiten zu lassen, sollten wir die PBIs aller drei Produkte unter
Umständen in einem Product Backlog zusammenführen. Dies würde erfordern, dass sich
die Product Owner der drei Produkte treffen und eine einzige Priorisierung für alle Pro-
dukte aushandeln.

154
6.8
Abschließende Bemerkungen

Product Backlogs Produktteams Product Backlogs

Produkt A Produkt A

Ein Team

Produkt B Produkt B

Produkt C Produkt C

Abb. 6.16: Szenarien für mehrere Product Backlogs

Selbst wenn wir uns dafür entscheiden, drei getrennte Product Backlogs vorzuhalten, muss
in jedem Sprint jemand (vorzugsweise der Product Owner für das Team) eine priorisierte
PBI-Auswahl aus den drei Backlogs zusammenstellen (möglicherweise basierend auf der
Zeit, die das Team während des Sprints für die einzelnen Produkte aufwenden möchte)
und diese dem Team vorlegen, damit es darüber befinden kann.

6.8 Abschließende Bemerkungen


In diesem Kapitel diskutierte ich die entscheidende Rolle, die das Product Backlog ange-
sichts der Unsicherheit beim Erreichen einer schnellen, flexiblen Auslieferung von Werten
spielt. Dabei habe ich auf eine Reihe von strukturellen und prozessbezogenen Fragestellun-
gen hingewiesen, die im Zusammenhang mit dem Product Backlog auftreten: Was für Ele-
mente gibt es im Product Backlog, wie pflegt man das Product Backlog, um bestimmte
Eigenschaften des Product Backlogs zu erreichen usw. Abschließend wurde die Frage erör-
tert, welche und wie viele Product Backlogs man haben sollte. Im nächsten Kapitel geht es
darum, wie Product-Backlog-Elemente geschätzt werden und wie man diese Schätzungen
nutzt, um die Velocity, also die Entwicklungsgeschwindigkeit, zu messen.

155
Kapitel 7

Schätzung und Velocity

In diesem Kapitel beschreibe ich die Konzepte der Schätzung und der Velocity (Entwick-
lungsgeschwindigkeit). Ich beginne zunächst mit einem Überblick über den wichtigen
Stellenwert, den sie in der agilen Planung einnehmen, und erkläre dann, welche verschie-
denen Elemente wir schätzen sowie wann und wie wir das tun. Der Großteil dieses Kapitels
konzentriert sich darauf, wie sich Product-Backlog-Elemente schätzen lassen, wie man eine
geeignete Maßeinheit wählt und wie man den Planungspoker »spielt«. Im Anschluss daran
stelle ich das Konzept der Velocity vor und erläutere, welche Bedeutung ein Velocity-
Bereich für die Planung hat und wie neue Teams trotz fehlender historischer Daten die
Velocity vorhersagen können. Zum Schluss gehe ich außerdem auf einige Methoden zur
Beeinflussung der Velocity ein und zeige auf, welche Arten des Missbrauchs der Velocity es
gibt.

7.1 Überblick
Wenn wir die Entwicklung eines Produkts planen und organisieren, müssen wir wichtige
Fragen beantworten, wie etwa: »Wie viele Funktionen werden abgeschlossen?«, »Wann
werden wir fertig sein?« und »Wie viel wird das kosten?«. Um diese Fragen mithilfe von
Scrum zu beantworten, müssen wir die Größe des zu bauenden Produkts schätzen und die
Velocity oder Rate messen, in der wir die Arbeit fertigstellen können. Auf der Grundlage
dieser Informationen können wir dann die wahrscheinliche Dauer der Produktentwicklung
(und die entsprechenden Kosten) ableiten, indem wir die geschätzte Größe eines Funk-
tionssatzes durch die Velocity des Teams teilen.
Wie viel Zeit brauchen wir unter Zugrundelegung des Product Backlogs in Abbildung 7.1,
um die Features aus Release 1 zu erstellen? Um diese Frage zu beantworten, müssen wir
zuerst die Größe von Release 1 schätzen. Dazu addieren wir die einzelnen Größenschätzun-
gen für die jeweiligen PBIs, die für Release 1 vorgesehen sind. (In unserem Beispiel beträgt
die Summe der PBI-Schätzungen 200 Punkte.)
Sobald wir die ungefähre Größe der Version kennen, wenden wir unsere Aufmerksamkeit
der Velocity des Teams zu, also der Frage, wie viel Arbeit das Team typischerweise in einem
Sprint erledigen kann. Die Velocity, sprich die Entwicklungsgeschwindigkeit, lässt sich
leicht messen: Am Ende jedes Sprints addieren wir einfach die Größenschätzungen aller
Elemente, die während des Sprints abgeschlossen wurden. Wurde ein Element nicht been-
det, dann fließt es nicht in die Velocity ein. Die Summe der Größen aller abgeschlossenen
Product-Backlog-Elemente in einem Sprint gibt die Velocity des Teams für diesen Sprint
an. Das Diagramm in Abbildung 7.1 zeigt die Velocity-Daten des Teams für die vergange-
nen sieben Sprints. Die durchschnittliche Velocity liegt bei 20.

157
Kapitel 7
Schätzung und Velocity

Nachdem wir die Größe geschätzt und die Velocity gemessen haben, können wir die Dauer
berechnen bzw. ableiten. Dazu teilen wir die Größe durch die Velocity. Beträgt die Größe
von Release 1 200 Punkte und kann das Team im Durchschnitt pro Sprint 20 Punkte
abschließen, dann sollte es 10 Sprints dauern, bis das Team Release 1 beendet hat (in Kapi-
tel 18 finden Sie eine ausführlichere Beschreibung der Release-Planung). Ich werde später
in diesem Kapitel erklären, wieso ein Velocity-Bereich für diese Berechnungen genauer ist
als ein durchschnittlicher Velocity-Wert. Zur Illustration habe ich hier jedoch den Durch-
schnitt der Velocity verwendet.

Geschätzte Größe ÷ gemessene Velocity = (Anzahl der Sprints)


Element Größe
200 Punkte ÷ 20 Punkte/Sprint = 10 Sprints
Funktion A | 5
Funktion B | 3
Funktion C | 2
Funktion D | 8
Funktion E | 2 Durchschnittliche Velocity = 20
30
Funktion F | 5
= 200 Punkte 25
Funktion G |3 20
Funktion … | … 15

Funktion ZX | 5 10
5
Funktion ZY | 2
Release 1 0
1 2 3 4 5 6 7
Funktion ZZ | 1

Funktion … |…

Abb. 7.1: Die Beziehung zwischen Größe, Velocity und Dauer

Obwohl sich die grundlegende Beziehung zwischen Größe, Velocity und Dauer nicht
ändert, können einige Details variieren. Das hängt davon ab, an welcher Stelle in der Ent-
wicklung Sie stehen, was Sie zu messen versuchen und wie Sie die Daten einsetzen wollen.
Schauen wir uns die Schätzung und die Velocity einmal genauer an, um herauszufinden,
wie sich diese Faktoren in Abhängigkeit von Ihren Aktionen ändern.

7.2 Was und wann wir schätzen


In Abbildung 7.1 wurden Story-Punkte benutzt, um die PBI-Schätzungen zum Berechnen
der Release-Dauer auszudrücken. Wir müssen allerdings während der Entwicklung eines
Produkts mit unterschiedlich großer Genauigkeit schätzen und werden deshalb verschie-
dene Einheiten verwenden (siehe Abbildung 7.2).
Die meisten Organisationen nehmen Schätzungen zu Planungszwecken mit drei unter-
schiedlichen Genauigkeitsstufen vor. Diese Schätzungen schlagen sich im Portfolio-Back-

158
7.2
Was und wann wir schätzen

log, im Product Backlog und im Sprint Backlog nieder. Betrachten wir das einmal etwas
genauer.

Portfolio-Backlog Product Backlog Sprint-Backlog-Aufgaben


Funktion A l 5
Produkt A l M Funktion B l 5
Funktion C l 2 UI programmieren Tests automat.
Stunden = 5 Stunden = 8
Funktion D l 5
Produkt B l S
Funktion E l 8
DB-Schema anlegen Fehler-Logging
Produkt C l XL Stunden = 6 Stunden = 12

Produkt D l L
Icons anlegen Puffertest
Stunden = 8 Stunden = 2

Element Portfolio-Backlog Product Backlog Sprint-Backlog-Aufgaben

Einheit T-Shirt-Größen Story-Punkte/ Idealtage Idealstunden /Aufwandstunden

Wann Portfolio-Planung Product-Backlog-Pflege Sprint-Planung

Abb. 7.2: Was und wann wir schätzen

7.2.1 Schätzungen für Portfolio-Backlog-Elemente


Das Portfolio-Backlog ist zwar kein formaler Bestandteil von Scrum, dennoch halten viele
Organisationen ein solches Backlog vor. Es enthält eine priorisierte Liste aller Produkte
(oder Projekte), die gebaut werden müssen. Um die Priorität eines Portfolio-Backlog-Ele-
ments korrekt bestimmen zu können, müssen wir die ungefähren Kosten eines jeden Ele-
ments kennen. Wie ich in Kapitel 5 diskutiert habe, steht uns zu dem Zeitpunkt, an dem
der Kostenwert erstmals verlangt wird, kein kompletter, detaillierter Anforderungssatz zur
Verfügung. Wir können also nicht nach der Standardmethode vorgehen und jede einzelne,
detaillierte Anforderung schätzen sowie diese Schätzwerte dann summieren, um die
Gesamtkosten zu ermitteln.
Stattdessen schätzen viele Organisationen die Portfolio-Backlog-Elemente, indem sie rela-
tive Größenangaben verwenden, etwa wie bei T-Shirts (klein, mittel, groß, extragroß usw.).
Ich werde in Kapitel 16 näher auf die Verwendung von T-Shirt-Größen für die Portfoliopla-
nung eingehen.

7.2.2 Product-Backlog-Schätzungen
Sobald jedoch ein Produkt oder Projekt befürwortet wurde und wir beginnen, weitere
Details zu seinen Product-Backlog-Elementen hinzuzufügen, müssen wir anders schätzen.
Wenn PBIs eine höhere Priorität bekommen haben und mehr Details enthalten, vergeben
die meisten Teams numerische Größenschätzungen in Form von Story-Punkten oder Ideal-
tagen. Ich werde beide Ansätze später in diesem Kapitel erläutern.

159
Kapitel 7
Schätzung und Velocity

Das Schätzen von PBIs ist Teil der Pflege des Product Backlogs. Abbildung 6.9 zeigt, wann
diese Pflege normalerweise stattfindet. Typischerweise wird die Schätzung in »Schätzsit-
zungen« oder »Schätzklausuren« durchgeführt. Die erste dieser Sitzungen fällt vermutlich
mit der ersten Release-Planung zusammen. Darüber hinaus kann der Product Owner auch
während eines Sprints zusätzliche Schätzsitzungen einberufen, falls neue PBIs geschätzt
werden müssen.
Nicht alle Anwender von Scrum sind der Meinung, dass die Größenschätzung von PBIs
notwendig ist. Ihrer Erfahrung nach können Scrum-Teams auch so gut sein, dass sie es
schaffen, PBIs anzulegen, die klein und alle ungefähr gleich groß sind. Sie halten es für
überflüssig, kleine Elemente ähnlicher Größe zu schätzen. Stattdessen zählen sie die PBIs
einfach. Das Konzept der Velocity nutzen sie zwar, allerdings messen sie sie als die Anzahl
der PBIs, die in einem Sprint abgeschlossen werden, und nicht als die Summe der Größen
der PBIs, die in einem Sprint beendet werden.
Ich verstehe das »Wir brauchen keine Schätzungen«-Argument, ziehe es aber dennoch aus
mehreren Gründen vor, PBIs zu schätzen:
쐽 Wie ich in Kapitel 5 bereits erwähnt habe, werden nicht alle PBIs zum selben Zeitpunkt
die gleiche Größe haben, so dass es im Backlog ohnehin einige größere PBIs geben
wird, auch wenn wir an der Spitze des Backlogs eine Sammlung kleinerer Elemente
ähnlicher Größe haben.
쐽 Es kann einige Zeit dauern, bis Teams die Fähigkeit besitzen, PBIs in ungefähr dieselbe
Größe zu zerlegen.
쐽 Möglicherweise müssen Teams Stories an unnatürlichen Stellen teilen, um zu errei-
chen, dass sie dieselbe Größe bekommen.
쐽 Und schließlich – und das ist vermutlich am wichtigsten – findet durch die Schätzsit-
zungen auch ein Lernprozess statt. Nichts fördert eine gesunde Debatte so sehr wie die
Forderung, etwas mit Zahlen zu unterlegen. Dabei werden ganz zwangsläufig Unstim-
migkeiten und Hypothesen zutage gefördert. Würden wir auf die Schätzung verzichten,
müssten wir eine andere Methode finden, um diese gesunden Diskussionen anzure-
gen.

7.2.3 Aufgabenschätzungen
Auf der Ebene mit den meisten Details haben wir die Aufgaben, die sich im Sprint Backlog
befinden. Die meisten Teams nehmen die Einschätzung ihrer Aufgaben während der
Sprint-Planung vor, damit sie das Vertrauen gewinnen, dass die Verpflichtungen, die sie
eingehen wollen, auch vernünftig sind (mehr dazu in Kapitel 19).
Aufgaben werden in Idealstunden (auch als Personenstunden, früher: Mannstunden
bezeichnet) gemessen. In Abbildung 7.2 schätzt das Team, dass die Benutzerschnittstellen-
aufgabe fünf Personenstunden in Anspruch nehmen wird. Das bedeutet aber nicht, dass es
fünf Zeitstunden dauert. Eine Person könnte mehrere Tage brauchen, um die Benutzer-
schnittstelle zu programmieren, mehrere Personen, die zusammenarbeiten, brauchen viel-
leicht weniger als einen Tag. Die Schätzung sagt lediglich aus, wie viel Aufwand das Team
aufbringen muss, um die Aufgabe abzuschließen. Ich werde den Einsatz von Aufgaben-
schätzungen in Kapitel 19 näher beschreiben, wenn es um die Details der Sprint-Planung
geht.

160
7.3
Schätzkonzepte für Product-Backlog-Elemente

7.3 Schätzkonzepte für Product-Backlog-Elemente


Obwohl alle drei Detailbereiche wichtig sind, werden wir uns im Rest dieses Kapitels auf
die Schätzung auf Product-Backlog-Ebene konzentrieren. Es gibt mehrere bedeutsame
Konzepte, die Scrum-Teams nutzen, wenn sie PBIs schätzen (siehe Abbildung 7.3).
Nachfolgend werden wir uns die einzelnen Konzepte genauer anschauen.

7.3.1 Als Team schätzen


In vielen traditionellen Organisationen nimmt vermutlich der Projektmanager, der Pro-
duktmanager, der Architekt oder ein führender Entwickler die erste Größenschätzung vor.
Andere Teammitglieder bekommen erst zu einem späteren Zeitpunkt die Möglichkeit,
diese Schätzungen zu betrachten und zu kommentieren. In Scrum folgen wir dagegen
einer einfachen Regel: Die Personen, die die Arbeit machen, kümmern sich zusammen um
die Schätzung.
Übrigens: Wenn ich von den Personen spreche, die die Arbeit machen, dann meine ich im
Klartext das Entwicklungsteam, das auch tatsächlich den Entwurf, den Aufbau und das Tes-
ten der PBIs erledigt. Product Owner und ScrumMaster tragen keine Schätzungen bei:
Beide sind zwar bei der PBI-Schätzung zugegen, sie sind aber nicht aktiv daran beteiligt
(siehe Abbildung 7.4).
Die Rolle des Product Owners besteht darin, die PBIs zu beschreiben und klärende Fragen
zu beantworten, die das Team möglicherweise stellt. Er sollte das Team jedoch nicht
bewusst zu einer gewünschten Schätzung hinführen. Die Rolle des ScrumMasters besteht
hingegen darin, die Schätzaktivität unterstützend zu begleiten.
Ziel ist es, dass das Entwicklungsteam die Größe der einzelnen PBIs aus seiner kollektiven
Perspektive heraus ermittelt. Da jeder die Story entsprechend seiner Expertise von einem
anderen Standpunkt aus sieht, ist es wichtig, dass alle Mitglieder des Entwicklungsteams
an der Schätzung teilnehmen.

Als Team schätzen

Schätzungen sind keine Verpflichtungen

PBI-Schätzkonzepte

Auf Exaktheit konzentrieren, nicht auf Präzision

Relative Größen benutzen, keine absoluten

Abb. 7.3: Konzepte zum Schätzen von Product-Backlog-Elementen

161
Kapitel 7
Schätzung und Velocity

Beschreibt und erläutert Trainiert und moderiert

Product Backlog
Funktion A
Funktion B
Funktion C

Schätzen

Schätzen gemeinsam

Abb. 7.4: Das gesamte Scrum-Team nimmt an der Schätzung teil

7.3.2 Schätzungen sind keine Verpflichtungen


Schätzungen sind keine Verpflichtungen – und es ist wichtig, dass wir sie auch nicht als
solche behandeln. Diese Aussage betrifft üblicherweise die Manager. »Was meinen Sie
damit, dass wir das Team nicht verpflichten, sich an seine Schätzungen zu halten? Wie sol-
len wir präzise Schätzungen bekommen, wenn es das nicht tut?«
Wenn dieses Thema in meinen Kursen aufkommt, dann habe ich eine einfache visuelle
Demonstration parat, um meine Argumentation zu verdeutlichen. Ich halte einen Klebe-
zettel hoch und sage: »Stellen Sie sich vor, ich bitte Sie, diese Story zu schätzen, und Sie
sagen mir, sie sei so groß.« Dabei zeige ich mit meinen Händen die Größe der Story an, wie
in Abbildung 7.5 links dargestellt.

Ursprüngliche Größenschätzung Revidierte Schätzung,


basierend auf einer Verpflichtung

Abb. 7.5: Der Effekt der Verpflichtung auf die Einhaltung von Schätzwerten

162
7.3
Schätzkonzepte für Product-Backlog-Elemente

Anschließend sage ich so etwas wie: »Ach übrigens, ich vergaß zu erwähnen, dass Ihr
gesamter Bonus des nächsten Jahres davon abhängt, ob Ihre Schätzung korrekt ist. Also
gebe ich Ihnen jetzt die Gelegenheit, Ihre Schätzung zu revidieren.« An dieser Stelle führe
ich meine Hände immer weiter auseinander, um zunehmend größere Schätzwerte anzu-
deuten (wie in Abbildung 7.5 rechts). Und dann füge ich ergänzend noch etwa Folgendes
hinzu: »Sagen Sie mir, wann ich aufhören soll. Meine Arme sind ja nicht endlos lang, ich
bin schließlich kein Basketballspieler!«
Der springende Punkt dabei ist: Wenn ich die Leute bitte, die Größe einer Story zu schät-
zen, dann erwarte ich ein realistisches Ergebnis. Aber wenn ich darüber hinaus erwähne,
dass ihre Boni von der Korrektheit der Schätzung abhängen, dann wird jeder, auch ich
selbst, eine viel höhere Schätzung abgeben als die, die er anfangs für richtig gehalten hat.
Die Schätzwerte sollen ein realistisches Maß dafür darstellen, wie groß bzw. umfangreich
etwas ist. Wir wollen sie nicht künstlich aufblähen, nur weil wir von außen beeinflusst wer-
den – das würde lediglich zu überdimensionierten Zeitplänen und einem Hin und Her aus
übertriebenen Schätzungen der Teammitglieder auf der einen und Versuchen des Manage-
ments, diese Werte zu reduzieren, auf der anderen Seite führen. Und am Ende hätten wir
dann überhaupt keine realistischen Zahlen, weil sie viel zu oft von unterschiedlichen Leu-
ten manipuliert wurden.

7.3.3 Exaktheit versus Präzision


Unsere Schätzungen sollten exakt, aber nicht übermäßig präzise sein. Wir waren alle schon
an Produkten beteiligt, deren Schätzwerte ein geradezu lächerliches Maß an Präzision auf-
wiesen – Sie wissen schon, wenn die Schätzung bei 10.275 Personenstunden lag oder die
projektierten Kosten 132.865,87 Dollar betrugen.
Es ist sinnlos und verschwenderisch, solche falschen, übermäßig präzisen Schätzungen
abzugeben. Erstens ist der Aufwand für die Ermittlung der Werte überzogen – und der
kann beträchtlich sein. Und zweitens kommt es unweigerlich zu einer Verschwendung,
wenn wir uns einreden, dass wir etwas verstehen, obwohl wir das gar nicht wirklich tun,
und dann auf der Grundlage dieser Fehleinschätzung wichtige, falsche und teure geschäft-
liche Entscheidungen treffen.
Stattdessen sollten wir gerade ausreichend Mühe aufwenden, um eine grobe, ungefähr
richtige Schätzung zu ermitteln (siehe Abbildung 7.6).
Grundsätzlich gelangen wir bei den Schätzungen immer irgendwann an einen Punkt, an
dem die Werte nicht mehr in dem Maße exakter werden, in dem unsere Anstrengungen
zunehmen. Und wenn wir diesen Punkt überschreiten, dann verschwenden wir nur unsere
Zeit und beeinflussen die Genauigkeit der Schätzung außerdem möglicherweise sogar
negativ, weil wir eine immer größer werdende Menge an weniger wertvollen Daten berück-
sichtigen.

7.3.4 Relative Größenschätzung


Wir sollten Product-Backlog-Elemente mit relativen Größen schätzen, nicht mit absoluten.
Das heißt, wir vergleichen die einzelnen Elemente, um festzustellen, wie groß sie im Ver-
hältnis zu anderen sind.

163
Kapitel 7
Schätzung und Velocity

Wie Abbildung 7.7 zeigt, ist die Einschätzung des Größenverhältnisses der verschiedenen
Gläser zueinander noch recht einfach, allerdings könnte ich nicht mit Sicherheit sagen,
welche absolute Flüssigkeitsmenge die einzelnen Gläser tatsächlich enthalten.

100% Abnehmendes Ergebnis


Schädlich und
Gut genug
verschwenderisch
Genauigkeit

50%

0%
Aufwand

Abb. 7.6: Aufwand versus Genauigkeit beim Schätzen

1X 4X 9X
Abb. 7.7: Relative Größenschätzung

164
7.3
Schätzkonzepte für Product-Backlog-Elemente

Meinen eigenen Beobachtungen zufolge bin ich überzeugt, dass der Mensch bei relativen
Größenschätzungen generell deutlich besser abschneidet als bei absoluten Größenschät-
zungen. Abbildung 7.8 zeigt ein Beispiel, das ich in meinen Kursen nutze, um diese These
zu untermauern.

Wo befindet sich der Projektor


relativ zu den zwei Wänden?

Wie weit ist das


in Metern?

Abb. 7.8: Absolute versus relative Größenschätzung

Dazu gehe ich zur einen Seite des Raumes und wende mich der gegenüberliegenden Wand
zu. Dann bitte ich die Teilnehmer, in absoluten Größeneinheiten (z.B. Metern) aufzu-
schreiben, wie weit ich ihrer Meinung nach von der entgegengesetzten Wand entfernt bin.
(Die Leute, die nach oben schauen, um die Deckenplatten zu zählen, fordere ich auf, nicht
zu schummeln!)
In vielen Kursräumen ist ungefähr in der Mitte der Decke ein LCD-Projektor montiert. Des-
halb bitte ich sie außerdem aufzuschreiben, in welcher relativen Position sich der Projektor
zur entfernten Wand und zu mir befindet.
Dabei kommen fast immer die gleichen Ergebnisse zustande. Wenn ich in einem typischen
Kurs mit 30 Leuten frage: »In welcher absoluten Entfernung befinde ich mich zu der ande-
ren Wand?«, bekomme ich üblicherweise 27 unterschiedliche Antworten. Wenn ich dage-
gen frage: »In welcher relativen Position befindet sich der Projektor zwischen mir und der
entgegengesetzten Wand?«, dann antworten 29 von 30 Leuten: »Etwa auf der Hälfte«, wäh-
rend die dreißigste Person mich veralbern will und so etwas sagt wie »5/11 der Strecke!«.
Natürlich handelt es sich hierbei nicht um ein lupenreines wissenschaftliches Experiment,
dennoch stimmen mir die meisten Leute zu, dass sie tatsächlich besser darin sind, relative

165
Kapitel 7
Schätzung und Velocity

Größen zu beurteilen als absolute. Auch wenn es vorkommt, dass der Projektor ein Drittel
oder zwei Drittel der Raumlänge von mir entfernt ist, sind die Ergebnisse bei der relativen
Schätzung normalerweise korrekt.
Wenn wir also jemanden auffordern, etwas zu schätzen, sollten wir die dafür zu verwen-
dende Technik auf dem aufbauen, was die Leute gut können (relative Größenschätzung)
und nicht auf dem, was sie nicht gut können (absolute Größenschätzung).

7.4 Schätzeinheiten für Product-Backlog-Elemente


Es gibt keine Standardeinheit für PBI-Größenschätzungen. Am weitesten verbreitet sind
Story-Punkte und Idealtage. Keine dieser beiden Maßeinheiten ist richtiger oder falscher
als die andere. Ich denke, dass 70% der Organisationen, mit denen ich zusammenarbeite,
Story-Punkte verwenden, die übrigen 30% benutzen Idealtage. Schauen wir uns beides ein-
mal an.

7.4.1 Story-Punkte
Story-Punkte messen die Größe bzw. den Umfang eines Product-Backlog-Elements. Sie
können durch mehrere Faktoren wie Komplexität und physische Größe beeinflusst werden.
Es bedarf nicht unbedingt physischer Größe, damit etwas als groß bezeichnet werden kann.
So könnte die Story beispielsweise die Entwicklung eines komplexen Unternehmensalgo-
rithmus repräsentieren. Das Endergebnis muss dabei nicht unbedingt sehr groß ausfallen,
der Aufwand, der nötig ist, um sie zu entwickeln, könnte es aber durchaus sein. Anderer-
seits könnte eine Story zwar physisch sehr groß, aber nicht sehr komplex sein. Nehmen wir
an, wir müssten alle 60.000 Zellen in einer Kalkulationstabelle aktualisieren. Keine der
einzelnen Aktualisierungen ist schwierig, aber sie können nicht automatisiert werden. Wie
viel dieser Arbeit können wir in einem Sprint schaffen? Die Story ist also nicht komplex,
aber dennoch umfangreich und somit groß.
Story-Punkte kombinieren Faktoren wie Komplexität und physische Größe zu einem relati-
ven Größenmaß. Ziel ist es dabei, am Ende Stories vergleichen und Dinge sagen zu können
wie: »Na ja, wenn die Ticket-herstellen-Story eine 2 ist, dann ist die Nach-Ticket-suchen-
Story eine 8.« Es wird also implizit ausgesagt, dass die Such-Story etwa viermal größer ist
als die Herstellungs-Story.
In dem Beispiel am Anfang dieses Kapitels wurde der Ansatz verfolgt, die PBI-Größen zu
schätzen und dann die Dauer abzuleiten, indem die Summe der Größen durch die durch-
schnittliche Velocity dividiert wurde. Da Größenmaße genau wie Story-Punkte irgendwann
dazu benutzt werden, eine Zeit (Dauer) zu berechnen, müssen die Story-Punkte den Auf-
wand widerspiegeln, der aus Sicht des Entwicklungsteams mit der Story verbunden ist.

7.4.2 Idealtage
Einen alternativen Ansatz zum Schätzen von PBIs bieten Idealtage. Idealtage sind eine ver-
traute Einheit: Sie repräsentieren die Anzahl der Personentage, die benötigt werden, um
eine Story abzuschließen. Die Idealzeit ist nicht das Gleiche wie die verstrichene Zeit. So
besteht beispielsweise ein American-Football-Spiel im Idealfall aus vier Vierteln, die jeweils

166
7.5
Planungspoker

15 Minuten lang sind (das Spiel wird also in einer Idealstunde gespielt). Allerdings dauert
ein Spiel tatsächlich in der Regel eher drei bis dreieinhalb Stunden.
Ich sagte ja bereits, dass es keine richtige oder falsche Antwort gibt, wenn man sich zwi-
schen Story-Punkten und Idealtagen entscheidet. Ein wichtiges Argument gegen die Ideal-
zeit ist allerdings das Risiko der Fehlinterpretation.
Nehmen wir z.B. an, es wäre Dienstag, früher Nachmittag, und ich zeige Ihnen ein PBI
und frage: »Wie groß ist dieses PBI?« Sie antworten: »Zwei Tage.« Darauf sage ich: »Okay,
Sie können also Donnerstag am frühen Nachmittag fertig sein.« Sie entgegnen nun: »Nein,
ich bin heute Nachmittag und morgen [Mittwoch] noch mit einer Zwei-Tage-Aktivität
beschäftigt. Dafür brauche ich den ganzen Tag, also kann ich wahrscheinlich am Donners-
tag mit diesem Element anfangen. Da ich aber nicht den ganzen Tag für das PBI Zeit habe,
schätze ich, dass ich irgendwann am nächsten Montag fertig sein werde.« Ich sage darauf-
hin: »Das verstehe ich nicht. Sie haben doch von einem Zwei-Tage-PBI gesprochen, dann
müssten Sie doch am Donnerstag fertig sein.« Und schließlich erklären Sie: »Ich habe von
zwei Idealtagen gesprochen, nicht von Kalendertagen. Bilden Sie meine Idealtage bitte
nicht auf Kalendertage ab. Das funktioniert nicht.«
Die 30% der Organisationen, mit denen ich arbeite, die erfolgreich die Idealzeit einsetzen,
würden das folgendermaßen kommentieren: »Tja, aber wir haben das Problem mit der
Fehlinterpretation gar nicht. Wenn wir den Leuten sagen, dass es zwei Tage dauert, dann
wissen sie, dass es sich nicht um zwei Kalendertage handelt.«
Wenn in Ihrer Organisation lediglich ein geringes Risiko besteht, dass es bei derartigen
Zeitangaben zu Missverständnissen kommt, könnte die Idealzeit ganz gut funktionieren.
Sollten Sie jedoch glauben, dass sie fehlinterpretiert werden könnten, dann sollten Sie bes-
ser Story-Punkte verwenden.
Es gibt zwar noch weitere Unterschiede zwischen Story-Punkten und Idealzeit, die Fehlin-
terpretation stellt allerdings definitiv eins der größten Probleme dar. Eine meiner Kursteil-
nehmerinnen fasste ihre Meinung zu diesem Thema gegenüber ihren Kollegen einmal so
zusammen: »Wir haben die Idealzeit in den ganzen 15 Jahren benutzt, die ich hier arbeite,
und das hat nie funktioniert. Ehrlich, ich würde gern mal etwas anderes ausprobieren.«

7.5 Planungspoker
Der Planungspoker ist eine Technik zum Schätzen von Product-Backlog-Elementen, die
zuerst von James Grenning (Grenning 2002) beschrieben und dann von Mike Cohn (Cohn
2006) bekannt gemacht wurde. Diese Methode basiert auf einigen wichtigen Konzepten
(siehe Abbildung 7.9).
Beim Planungspoker handelt es sich um eine konsensbasierte Technik zur Aufwands-
schätzung. Sachkundige Leute (die Experten), die eingeteilt wurden, an einem Product-
Backlog-Element zu arbeiten, führen eine intensive Diskussion, um Hypothesen zu erar-
beiten, zu einem Konsens zu gelangen und die Größe der PBIs zu bestimmen. Der Pla-
nungspoker ergibt relative Größenschätzungen, indem Elemente ähnlicher Größe akkurat
gruppiert oder zusammengefasst werden. Und das Team macht sich dabei seine bereits
vorhandenen Erkenntnisse über die PBI-Schätzwerte zunutze, um die nächste Elemente-
gruppe zu schätzen.

167
Kapitel 7
Schätzung und Velocity

Konsensbasiert

Expertenmeinung

Intensive Diskussion
Planungspokerkonzepte
Relative Größenschätzungen

Akkurate Gruppierung/Zusammenfassung

Ausnutzen bereits vorhandener Schätzungen

Abb. 7.9: Planungspoker-Konzepte

7.5.1 Schätzskala
Um Planungspoker zu »spielen«, muss das Team entscheiden, welche Skala oder Abfolge
von Zahlen für die Zuweisung der Schätzwerte benutzt werden soll. Da wir genau, aber
nicht übermäßig präzise sein wollen, verwenden wir nicht alle Zahlen. Stattdessen bevor-
zugen wir eine Skala, die am unteren Ende des Bereichs mehr Zahlenwerte ausweist, wäh-
rend sie zum anderen Ende hin seltener werden und weiter auseinanderliegen.
Die am häufigsten verwendete Skala wurde von Mike Cohn vorgeschlagen und beruht zum
Teil auf einer abgewandelten Fibonacci-Folge: 1, 2, 3, 5, 8, 13, 20, 40 und 100. Eine alterna-
tive Skala, die manche Teams einsetzen, basiert auf Zweierpotenzen: 1, 2, 4, 8, 16, 32, ...
Wenn wir eine derartige Skala verwenden, fassen wir ähnlich große PBIs zusammen und
weisen ihnen dieselbe Zahl auf der Skala zu. Um dieses Konzept zu verdeutlichen, sollten
wir uns vorstellen, wir würden auf dem Postamt arbeiten und müssten Pakete ähnlicher
Größe in dieselbe Kiste legen (siehe Abbildung 7.10).
Wenn wir ein Paket erhalten, müssen wir entscheiden, in welche Kiste wir es legen. Nicht
alle Pakete in einer Kiste werden exakt dieselbe Form, Größe oder Gewicht haben. Deshalb
müssen wir die Pakete untersuchen, die sich momentan in der Kiste befinden, um die am
besten passende Kiste für das einzuordnende Paket zu finden, das wir gerade schätzen.
Sobald wir diese Kiste identifiziert haben, legen wir das Paket hinein und gehen dann zum
nächsten Paket über. und je mehr Pakete wir in die Kisten legen, umso einfacher wird es
natürlich auch, künftige Pakete zu gruppieren, weil wir immer mehr Vergleichspunkte
haben.
Um eine übermäßige Präzision zu vermeiden, haben wir keine »4-Kiste« (falls unsere
Skala auf der Fibonacci-Folge beruht). Wenn wir also zu einem Paket kommen, das unserer
Meinung nach größer als 2, aber kleiner als 8 ist, müssen wir es entweder in die »3-Kiste«
oder die »5-Kiste« legen.

168
7.5
Planungspoker

3 5
1 2

Abb. 7.10: Beim Planungspoker werden Bündelungen verwendet.

7.5.2 Wie man spielt


Am Planungspoker nimmt das gesamte Scrum-Team teil. Während der Sitzung präsentiert
und beschreibt der Product Owner die PBIs und beantwortet auch Fragen. Der ScrumMas-
ter leitet das Team an und unterstützt es beim »Pokern«. Außerdem achtet er stets auf
Beteiligte, deren Körpersprache oder Schweigen andeutet, dass sie nicht einverstanden
sind, und hilft ihnen, sich einzubringen. Das Entwicklungsteam generiert die Schätzwerte
gemeinsam.
Jedes Mitglied des Entwicklungsteams bekommt einen Satz Planungspokerkarten (siehe
Abbildung 7.11).

Abb. 7.11: Innolution-Planungspokerkarten

Eine allgemeine Interpretation dieser Karten ist in Tabelle 7.1 beschrieben.

169
Kapitel 7
Schätzung und Velocity

Karte Interpretation
0 Nicht in Abbildung 7.11 zu sehen, aber in manchen Spielen zu finden. Zeigt
an, dass das Element bereits abgeschlossen wurde oder so klein ist, dass es
sinnlos wäre, ihm einen Größenwert zuzuweisen.
1/2 Wird für winzig kleine Elemente benutzt.
1, 2, 3 Wird für kleine Elemente benutzt.
5, 8, 13 Wird für mittelgroße Elemente benutzt. Für viele Teams ist 13 der größte Wert,
den sie in einen Sprint eintakten würden. Elemente, die größer als 13 sind,
würden in kleinere Elemente zerlegt.
20, 40 Wird für große Elemente benutzt (Stories auf Funktions- oder Theme-Ebene).
100 Entweder eine sehr große Funktion oder ein Epic.
 (unend- Zeigt an, dass das Element so groß ist, dass es sinnlos wäre, ihm einen Wert
lich) zuzuweisen.
? (Frage- Zeigt an, dass ein Teammitglied das Element nicht versteht, so dass der Pro-
zeichen) duct Owner gefordert ist, für weitere Klärung zu sorgen. Manche Teammitglie-
der nutzen das Fragezeichen auch als eine Methode, um sich aus der
Schätzung des aktuellen Elements herauszuhalten – meist, weil die betref-
fende Person so wenig mit dem Element zu tun hat, dass sie keine Ahnung hat,
wie sie es schätzen soll. Es ist zwar, akzeptabel, nicht zu schätzen, nicht akzep-
tabel ist dagegen, sich gar nicht zu beteiligen! Nur weil sich jemand nicht wohl
dabei fühlt, eine Schätzung abzugeben, darf er sich dem Gespräch oder der
Verantwortung gegenüber dem Team, einen Konsens bei der Schätzung zu
erreichen, nicht gänzlich entziehen.
q (pi) In diesem Kontext bedeutet q nicht 3,1415926! Vielmehr wird die Pi-Karte
benutzt, wenn ein Teammitglied sagen möchte: »Ich bin müde und hungrig
und möchte Kuchen [pie] essen!« Bei manchen Planungspokerspielen gibt es
dafür eine Karte mit einer Kaffeetasse. In jedem Fall weist die Karte jedoch auf
einen wichtigen Punkt hin: Die Teammitglieder können sich nur eine
begrenzte Zeit in eine intensive Diskussion über die Schätzungen einbringen
(vielleicht eine oder zwei Stunden). Irgendwann brauchen sie eine Pause, sonst
besteht die Gefahr, dass der Enthusiasmus für die Diskussion in das Bestreben
umschlägt, die Schätzungen so schnell wie möglich hinter sich zu bringen –
egal, wie exakt sie sind oder was man daraus lernen könnte. Wenn die Pi-Karte
ausgespielt wird, braucht das Team eine Pause.
Tabelle 7.1: Allgemeine Interpretation der Planungspokerkarten

Beim Planungspoker gelten folgende Regeln:


1. Der Product Owner wählt ein zu schätzendes PBI aus und stellt dem Team das Element
vor.
2. Die Mitglieder des Entwicklungsteams diskutieren das Element und stellen dem Product
Owner klärende Fragen, die dieser beantwortet.
3. Jeder Schätzer wählt verdeckt eine Karte aus, die seine Schätzung wiedergibt.
4. Sobald alle Schätzer ihre Wahl getroffen haben, werden alle gewählten Schätzkarten
gleichzeitig aufgedeckt.

170
7.6
Was ist Velocity?

5. Wählen alle die gleiche Karte, herrscht Konsens. Diese Konsenszahl ist dann der PBI-
Schätzwert.
6. Sind die Schätzwerte nicht identisch, beginnen die Teammitglieder eine konzentrierte
Diskussion, um Hypothesen aufzustellen und Missverständnisse aufzudecken. Typi-
scherweise werden diejenigen mit sehr hohen und sehr niedrigen Schätzwerten gebe-
ten, ihre Entscheidungen zu erklären oder zu rechtfertigen.
7. Nach der Diskussion kehren wir zu Schritt 3 zurück und wiederholen ihn, bis ein Kon-
sens erreicht wird.
Beim Planungspoker ermitteln wir keine Durchschnittswerte oder benutzen Zahlen, die
nicht auf der Skala/den Karten stehen. Das Ziel ist es nicht, Kompromisse zu machen, son-
dern aus Sicht des Teams einen echten Konsens über die geschätzte Gesamtgröße (den
geschätzten Aufwand) der Story zu schaffen. Normalerweise erreicht man diesen Konsens
in zwei oder drei Abstimmrunden. Die konzentrierte Diskussion der Teammitglieder hilft
dabei, ein gemeinsames Verständnis von der Story zu entwickeln.

7.5.3 Vorteile
Der Planungspoker bringt die sehr unterschiedlichen Leute des Teams, das die Arbeit erle-
digen soll, zusammen und erlaubt es ihnen, einen Konsens über die genaue Schätzung zu
erreichen. Oft ist dieses Ergebnis viel besser als alles, was eine einzelne Person schaffen
könnte.
Wie ich bereits erwähnte, gibt es in der agilen Gemeinde Leute, die glauben, dass sich das
Schätzen von PBIs nicht lohnt. Die intensive Diskussion der PBIs, die durch den Planungs-
poker gefördert wird, ist jedoch unglaublich wertvoll. Meiner Erfahrung nach motivieren
Sie die Leute wirklich, über die Details der Product-Backlog-Elemente nachzudenken und
alle Annahmen und Hypothesen auf den Tisch zu legen, wenn Sie sie auffordern, sie mit
Zahlen zu unterlegen.
Der größte Nutzen, den man mit dem Planungspoker verbindet, liegt in der Diskussion
und dem besseren Verständnis, das die Teammitglieder in Bezug auf die PBIs entwickeln.
Ich hoffe natürlich auch immer auf gute Schätzwerte, wünsche mir aber noch mehr, dass
sie etwas über die PBIs lernen. Wenn sie das tun, werden die Bemühungen des Teams
irgendwann reiche Früchte tragen.

7.6 Was ist Velocity?


Die Velocity gibt die Menge der Arbeit an, die in jedem Sprint abgeschlossen wird, also
quasi die Entwicklungsgeschwindigkeit. Sie wird gemessen, indem die Größen der Pro-
duct-Backlog-Elemente, die am Ende des Sprints fertiggestellt sind, addiert werden. Ein
PBI ist entweder fertig oder es ist nicht fertig. Der Product Owner zieht aus unfertigen Ele-
menten keinen Wert und dementsprechend werden die Größen der teilweise abgeschlosse-
nen PBIs auch nicht in der Velocity berücksichtigt.
Sie misst den Ertrag (die Größe dessen, was geliefert wurde), nicht das Ergebnis (den Wert
dessen, was geliefert wurde). Wir nehmen an, dass ein PBI einen Wert für den Product
Owner haben muss, wenn er zugestimmt hat, dass das Team an diesem Element arbeiten
soll. Allerdings liefert die Fertigstellung eines PBIs der Größe 8 nicht unbedingt mehr

171
Kapitel 7
Schätzung und Velocity

geschäftlichen Wert als die Fertigstellung eines PBIs der Größe 3. Möglicherweise hat das
PBI der Größe 3 einen hohen Wert, weshalb wir früh daran arbeiten (wegen seines hohen
Wertes und seiner niedrigen Kosten), während wir mit der Arbeit an einem PBI der Größe
8 erst später beginnen (weil es einen niedrigeren Wert und dafür höhere Kosten besitzt).
Die Velocity erfüllt zwei wichtige Zwecke: Erstens stellt sie ein wesentliches Konzept für die
Scrum-Planung dar. Für die Planung auf Release-Ebene, wie in Abbildung 7.1 gezeigt, tei-
len wir die Größe des Release durch die durchschnittliche Velocity des Teams, um die
Anzahl der Sprints zu berechnen, die nötig sind, um das Release fertigzustellen. Bei der
Sprint-Planung wird die Velocity eines Teams außerdem als Eingabewert benutzt, um seine
Kapazität für den kommenden Sprint zu ermitteln (mehr dazu in Kapitel 19).
Und zweitens liefert die Velocity einen diagnostischen Maßstab, anhand dessen das Team
seinen Einsatz von Scrum zur Lieferung von Kundenwerten beurteilen und verbessern
kann. Indem das Team seine Velocity über die Zeit beobachtet, kann es sich einen Über-
blick darüber verschaffen, wie bestimmte Prozessänderungen die Lieferung eines messba-
ren Kundenwerts beeinflussen.

7.7 Einen Velocity-Bereich berechnen


Für Planungszwecke erweist es sich als sinnvoll, die Velocity in Form eines Bereichs auszu-
drücken, also etwa: »Das Team ist üblicherweise in der Lage, zwischen 25 und 30 Punkten
pro Sprint abzuschließen.« Ein Bereich hilft uns, genau zu sein, ohne übermäßig präzise
zu werden.

Release 1 braucht 10 bis 12 Sprints zur Fertigstellung


200 Punkte ÷ 20 Punkte/Sprint = 10 Sprints
Element Größe
200 Punkte ÷ 17 Punkte/Sprint = 12 Sprints
Funktion A | 5
Funktion B | 3
Funktion C | 2
Funktion D | 8 Niedrige Velocity = 17
Funktion E | 2 Hohe Velocity = 20
30
Funktion F | 5
∑ = 200 Punkte 25
Funktion G |3 20
Funktion … |… 15

Funktion ZX | 5 10
5
Funktion ZY | 2
Release 1 0
1 2 3 4 5 6 7
Funktion ZZ | 1

Funktion … |…

Abb. 7.12: Einen Velocity-Bereich berechnen und nutzen

172
7.8
Die Velocity vorhersagen

Mit einem Velocity-Bereich können wir genauere Antworten auf Fragen liefern wie: »Wann
werden wir fertig sein?«, »Wie viele Elemente können wir abschließen?« oder »Wie viel
wird das alles kosten?« Da die meisten dieser Fragen bereits frühzeitig in einer Produktent-
wicklung aufkommen werden, also wenn wir die wenigsten Informationen über das Pro-
dukt besitzen, ist es unmöglich, eine sehr präzise Antwort zu geben. Mithilfe eines
Bereichs können wir diese Unsicherheit ausdrücken (siehe Abbildung 7.12).
In diesem Beispiel (einer Revision von Abbildung 7.1) wird nicht der genaue Sprint
bestimmt, in dem alle Elemente in dieser Version abgeschlossen sein werden (was wir ver-
mutlich nur raten könnten), sondern ein Bereich angegeben, um die Frage zu beantworten.
Um diesen Bereich zu berechnen, brauchen wir für unser Team zwei Velocity-Werte. Teilen
wir die Release-Größe durch die schnellere Velocity des Teams, erhalten wir die kleinstmög-
liche Anzahl an erforderlichen Sprints. Und wenn wir die Release-Größe durch die langsa-
mere Velocity teilen, erhalten wir die maximale Anzahl an Sprints.
Mittels einfacher Mathematik (wie hohe und niedrige Durchschnitte, 90%-Konfidenzinter-
valle usw.) können wir aus den historischen Velocity-Daten unseres Teams ganz leicht zwei
Velocity-Zahlen ermitteln (in diesem Beispiel 17 und 20). In Kapitel 18 erkläre ich näher,
wie Sie diese Berechnungen ausführen, um Fragen über das Wann und Wie Viel zu beant-
worten.

7.8 Die Velocity vorhersagen


In den vorherigen Beispielen bin ich davon ausgegangen, dass das Team historische Velo-
city-Daten besaß, die wir benutzen konnten, um die künftige Velocity vorherzusagen. Einer
der Vorteile lange bestehender Teams liegt sicher darin, dass man solche nützlichen Daten
sammeln kann (Kapitel 11 geht ausführlicher auf die Vorteile langlebiger Teams ein). Was
aber machen wir, wenn wir ein neues Team haben, dessen Teammitglieder noch nie
zusammengearbeitet haben und für das es daher keine historischen Daten gibt? Wir müs-
sen sie vorhersagen.
Eine gebräuchliche Methode zum Vorhersagen der Velocity ist es, das Team die Sprint-Pla-
nung durchführen zu lassen, um festzustellen, wie viele PBIs es während eines Sprints lie-
fern könnte. Wenn die Verpflichtung vernünftig erscheint, würden wir einfach die Größen
der zugesagten PBIs addieren und diese Zahl als vorhergesagte Velocity des Teams nutzen.
Weil wir aber eigentlich einen Velocity-Bereich haben wollen, könnten wir das Team
auch zwei Sprints planen lassen und dann den einen geschätzten Velocity-Wert als obere
und den anderen als untere Grenze des Bereichs verwenden (da sich beide Schätzungen
vermutlich voneinander unterscheiden würden). Alternativ könnten wir anhand der his-
torischen Daten anderer Teams einige intuitive Anpassungen an einer geschätzten Velo-
city vornehmen und damit eine Schätzung in einen Bereich aus zwei Schätzwerten
umwandeln.
Sobald das Team einen Sprint durchgeführt hat und wir einen wirklichen Velocity-Wert
haben, sollten wir die Vorhersage vergessen und diesen Wert benutzen. Und mit allen wei-
teren verfügbaren Daten, die danach hinzukommen, berechnen wir dann später Durch-
schnittswerte oder wenden andere Statistiken an, um einen Velocity-Bereich festzulegen.
(Siehe Cohn 2009 für weitere Beispiele.)

173
Kapitel 7
Schätzung und Velocity

7.9 Die Velocity beeinflussen


Sind Sie der Meinung, dass sich die Velocity eines Teams mit der Zeit immer mehr vergrö-
ßern sollte? Ein Manager sagte mal zu mir: »Letztes Jahr lag die Velocity meines Teams bei
durchschnittlich 30 Punkten pro Sprint. Dieses Jahr erwarte ich, dass es 35 Punkte pro
Sprint erreicht.« Dieser Manager glaubte, dass die Velocity seines Teams Trend 1 in Abbil-
dung 7.13 entsprechen sollte.
Velocity

Trend 1
Trend 2

Zeit
Abb. 7.13: Die Velocity eines Teams im Zeitverlauf

Er argumentierte, dass die Velocity des Teams doch immer besser werden müsse, weil es
sein Vorgehen doch stets untersuchte und anpasste (und damit verbesserte).
Ich würde bei einem Team, das aggressiv versucht, sich zu verbessern und sich darauf kon-
zentriert, Funktionen entsprechend einer robusten Definition von Fertig und mit geringen
technischen Schulden (siehe Kapitel 8) zu liefern, durchaus erwarten, dass sich seine Velo-
city immer weiter steigert. Oder zumindest würde ich eine Steigerung bis zu einem
bestimmten Punkt erwarten, an dem die Velocity mit hoher Wahrscheinlichkeit abflacht
(vergleichbar Trend 2 in Abbildung 7.13).
Nur weil sich die Velocity eines Teams auf einem bestimmten Niveau eingepegelt hat, heißt
das noch lange nicht, dass das Potenzial nach oben ausgeschöpft ist. Es gibt eine Reihe von
Maßnahmen, mit denen das Scrum-Team und die Manager die Velocity auf die nächste
Ebene hieven können. So haben z.B. die Einführung neuer Tools oder weitere Schulungen
und Trainings einen positiven Effekt auf die Velocity. Die Manager könnten auch die strate-
gische Zusammensetzung des Teams ändern, in der Hoffnung, dass diese Umstrukturie-
rung zu einer größeren Gesamt-Velocity führt. Allerdings müssen diese Manager dabei
natürlich vorsichtig vorgehen, weil die willkürliche Umbesetzung von Teammitgliedern
auch zu einem Abfall der Velocity führen könnte (und vermutlich auch wird).
Diese ganzen Aktionen können zwar einen positiven Effekt auf die Velocity haben, norma-
lerweise führen sie aber zunächst einmal zu einem Einbruch der Velocity, während das

174
7.10
Missbrauch der Velocity

Team diese Änderungen annimmt und verarbeitet (siehe Abbildung 7.13, Trend 2). Nach
dem Absinken kommt es dann wahrscheinlich wieder zu einem Anstieg bis zu dem Punkt,
an dem ein neues Niveau erreicht ist. Und dieses Niveau wird anschließend gehalten, bis
andere Änderungen eine weitere Verbesserung erreichbar erscheinen lassen.
Natürlich gibt es eine offensichtliche Maßnahme, die wir ausprobieren könnten, um die
Velocity zu steigern: Wir könnten länger arbeiten. Viele Überstunden könnten zunächst tat-
sächlich zu einer Verbesserung der Velocity führen (siehe »Überstunden« in Abbildung
7.14).

1. Überstunden

2. Überstunden enden
Velocity

4. Zurück zu Grundwert

3. Team erholt sich

Zeit
Abb. 7.14: Die Auswirkung von Überstunden auf die Velocity (basierend auf einer Abbildung aus
Cook 2008)

Diesem Anstieg folgt dann allerdings mit hoher Wahrscheinlichkeit ein rasanter Abfall der
Velocity, gepaart mit einem gleichzeitigen Nachlassen der Qualität. Außerdem braucht das
Team auch nach Beendigung der Überstundenperiode erst einmal Zeit, um sich zu erho-
len, bevor es wieder zu einer vernünftigen Grund-Velocity zurückfindet. Ich habe Beispiele
gesehen, bei denen die Senke (Bereich der verringerten Velocity) während der Erholungs-
phase größer war als der Scheitel (Bereich der erhöhten Velocity) während der Überstun-
denphase.
Am Ende ist es so, dass viele Überstunden zwar kurzfristig Vorteile mit sich bringen, diese
aber oft durch die langfristigen Konsequenzen aufgefressen werden.

7.10 Missbrauch der Velocity


Die Velocity wird als Planungswerkzeug und als Maßstab für die Diagnose des Teams
benutzt. Sie dient nicht als Leistungsmaß, mit dem man versucht, die Produktivität des
Teams zu beurteilen. Wenn sie auf diese Weise missbraucht wird, kann die Velocity zu
einem verheerenden und gefährlichen Verhalten anregen.

175
Kapitel 7
Schätzung und Velocity

Nehmen wir z.B. an, ich hätte beschlossen, dem Team mit der höchsten Velocity den größ-
ten Bonus zu geben. Oberflächlich betrachtet scheint diese Idee vernünftig zu sein: Das
Team mit der höchsten Velocity schafft während der einzelnen Sprints immerhin ganz
offensichtlich die meiste Arbeit, oder? Warum sollte man dieses Verhalten nicht belohnen?
Nun, falls ich Teams vergleiche, die ihre PBIs nicht anhand eines gemeinsamen Maßstabs
schätzen (was vermutlich der Fall sein wird), wäre ein Vergleich der Zahlen ziemlich sinn-
los. Nehmen wir an, Team A weist einem PBI einen Wert von 5 zu, während Team B dem-
selben PBI einen Wert von 50 beimisst. In diesem Fall möchte Team A eigentlich nicht,
dass ich seine Velocity mit der von Team B vergleiche – denn die Velocity von Team B wäre
zehnmal höher als die von Team A, selbst wenn beide Teams in den Sprints genauso viel
Arbeit abschließen.
Sobald Team A das Problem erkennt, werden seine Mitglieder beginnen, das System auszu-
tricksen, um dafür zu sorgen, dass ihre Velocity-Werte höher sind. Am einfachsten wäre es,
die Skala zu ändern, mit der das Team die PBIs schätzt. Team A schätzt nun also dasselbe
Element (das ursprünglich eine Größe von 5 besaß) mit 500 ein. Ich bezeichne dieses Ver-
halten als Punkteinflation, denn es dient keinem weiteren Zweck als dem, das Verhalten
eines Teams an ein fehlgeleitetes Messsystem anzupassen. Machen Sie das nicht.
Selbst wenn Teams im Sinne konsistenter PBI-Schätzungen die gleichen Einheiten verwen-
den, bekomme ich, wenn ich ein System zur Belohnung größerer Zahlen einrichte, auch
nichts anderes präsentiert – eben größere Zahlen (Punkteinflation).
Noch schlimmer als eine Punkteinflation ist es, wenn das Team beginnt, die Kurven zu
schneiden, um mehr »fertig« zu bekommen, damit es höhere, erstrebenswertere Velocity-
Werte erreicht. Das führt dann zu zunehmend steigenden technischen Schulden.
Am Ende sollten wir die Velocity danach beurteilen, wie gut sie uns bei unserer genauen
Planung unterstützt und wie sehr sie einem Team dabei hilft, sich intern zu verbessern.
Alle anderen Anwendungsfälle werden wahrscheinlich nur das falsche Verhalten fördern.

7.11 Abschließende Bemerkungen


In diesem Kapitel habe ich diskutiert, wie Größen geschätzt werden, die Velocity gemessen
und die Dauer berechnet wird. Ich habe aufgezeigt, wie die Schätzung auf Elemente auf
Portfolio-Ebene, auf Product-Backlog-Elemente und Aufgaben angewandt wird. Anschlie-
ßend konzentrierte ich mich besonders auf PBIs, indem ich wichtige Konzepte hinsichtlich
der Schätzung von PBIs diskutierte, darunter Story-Punkte und Idealtage. Als Nächstes
beschrieb ich eine Technik namens Planungspoker, die allgemein angewendet wird, um
PBIs zu schätzen.
Von der Schätzung ging ich dann zu einer Diskussion der Velocity über und erläuterte, wie
diese eingesetzt werden sollte. Dabei betonte ich, dass die Velocity am hilfreichsten ist,
wenn man sie als Wertebereich und nicht als einzelne Zahl ausdrückt. Außerdem stellte ich
kurz einige Methoden vor, mit denen wir die Velocity für ein neues Team vorhersagen
könnten. Und zum Schluss ging ich darauf ein, wie die Velocity missbraucht werden kann
und häufig auch missbraucht wird. Im nächsten Kapitel werde ich mich auf das Konzept
der technischen Schulden konzentrieren und zeigen, wie wir damit umgehen, wenn wir
Scrum benutzen.

176
Kapitel 8

Technische Schulden

In diesem Kapitel erläutere ich das Konzept der technischen Schulden. Ich beginne mit
einer ausführlicheren Definition, die auch die drei Variationen »naive Schulden«, »unver-
meidliche Schulden« und »strategische Schulden« umfasst. Danach untersuche ich einige
allgemeine Ursachen für die Entstehung technischer Schulden und zeige auf, welche Fol-
gen es hat, wenn man sie in hohem Maße anhäuft. Anschließend beschreibe ich drei Akti-
vitäten, die in unmittelbarem Zusammenhang mit dieser Problematik stehen: die
organisatorische Handhabung, das Sichtbarmachen und den Abbau angehäufter techni-
scher Schulden. Hier gehe ich insbesondere darauf ein, wie sich diese Aktivitäten unter
Anwendung des Scrum-Entwicklungsverfahrens durchführen lassen.

8.1 Überblick
Ward Cunningham war der Erste, der über das Konzept der technischen Schulden
geschrieben hat (Cunningham 1992). Er definierte es folgendermaßen:
Wenn man das erste Mal Code ausliefert, dann ist das, als würde man sich verschulden. Ein
paar kleine Schulden beschleunigen die Entwicklung, solange sie pünktlich mit einer Überar-
beitung zurückgezahlt werden. . . . Gefährlich wird es, wenn man die Schulden nicht zurück-
zahlt. Jede Minute, die man an nicht ganz richtigem Code verbringt, zählt als Zins auf diese
Schulden. Ganze Entwicklungsorganisationen können unter der Schuldenlast einer ungeeig-
neten Implementierung zum Stillstand gebracht werden. . . .
Cunningham nutzte die Metapher der technischen Schulden, um seinen Managern zu
erklären, wieso es von großem Vorteil ist, Software schnell herzustellen und zügig entspre-
chendes Feedback zu bekommen. Dabei betonte er vor allem zwei maßgebliche Punkte:
Das Team und die Organisation müssen stets auf die Begleichung der Schulden achten,
während ihr Verständnis hinsichtlich des betreffenden Geschäftsbereichs wächst, und das
Design und die Implementierung des Systems müssen sich weiterentwickeln, um diesem
neu hinzugewonnenen Verständnis besser gerecht zu werden.
Seit der Einführung dieses Konzepts Anfang der 1990er Jahre wurde Cunninghams
ursprüngliche Definition in der Softwarebranche allerdings immer freizügiger interpre-
tiert. Heutzutage bezieht sich der Begriff »technische Schulden« sowohl auf die Abstriche,
die wir innerhalb des Entwicklungsprozesses bewusst herbeiführen und in Kauf nehmen,
als auch auf die vielen Defizite und Mängel, die Softwaresysteme plagen. Dazu gehören:
쐽 Unpassendes (schlechtes) Design – Ein Design, das irgendwann einmal sinnvoll er-
schien, es jetzt aber angesichts bedeutender Veränderungen in Bezug auf den Ge-
schäftsbereich oder die verwendeten Technologien nicht mehr ist.
쐽 Defekte – Bekannte Probleme in der Software, die wir bisher noch nicht entfernt haben.

177
Kapitel 8
Technische Schulden

쐽 Unzureichende Testabdeckung – Bereiche, von denen wir wissen, dass wir in ihnen
mehr testen sollten, es aber noch nicht getan haben.
쐽 Übermäßiges manuelles Testen – Händisches Testen, obwohl wir eigentlich automati-
sierte Tests haben sollten.
쐽 Schlechtes Integrations- und Release-Management – Durchführen dieser Aktivitäten
auf eine Weise, die zeitraubend und fehleranfällig ist.
쐽 Mangelnde Plattformerfahrung – Wir haben z.B. Mainframe-Anwendungen in COBOL
geschrieben, haben aber nicht mehr viele erfahrene COBOL-Programmierer.
쐽 Und vieles mehr, weil der Begriff der »technischen Schulden« heutzutage oft als Indika-
tor für ein mehrdimensionales Problem gilt
Nach Cunninghams ursprünglicher Definition war der Begriff »technische Schulden«
eigentlich nicht als Synonym für die Unzulänglichkeiten von Teammitgliedern, Branchen-
bedingungen oder auch Prozessen gedacht, die zu nachlässigem Design, schlechten Ent-
wicklungspraktiken und einem Mangel an Tests führen. Diese Art von Schulden kann
durch anständiges Training, ein gutes Verständnis der technischen Praktiken und fundierte
geschäftliche Entscheidungsvorgänge eliminiert werden. Da solche Schulden oft ohne Sinn
für die Verantwortung und häufig auch versehentlich entstehen, bezeichne ich sie als naive
technische Schulden. Sie sind auch unter anderen Namen bekannt: waghalsige Schulden
(Fowler 2009), ungewollte Schulden (McConnell 2007) und Schlamperei (Martin 2008).
Ebenso gibt es unvermeidliche technische Schulden, die normalerweise unvorhersehbar
sind und nicht abgewendet werden können. So entsteht z.B. unser Verständnis für das, was
ein gutes Design ausmacht, aus der eigentlichen Designarbeit und der Erstellung der für
den Anwender wertvollen Funktionen auf der Grundlage dieser Arbeit. Wir können im Vor-
hinein nicht mit absoluter Sicherheit wissen, wie sich unser Produkt und sein Design im
Laufe der Zeit entwickeln müssen. Design- und Implementierungsentscheidungen, die wir
sehr früh treffen, müssen sich also möglicherweise ändern, wenn wir wichtige Lernschlei-
fen schließen und validiertes Wissen ansammeln. Und solche Änderungen, die in den
betroffenen Bereichen erforderlich sind, sind unvermeidliche technische Schulden.
Nehmen wir in einem anderen Beispiel an, dass wir eine Komponente eines Drittanbieters
lizenziert haben, um sie in unserem Produkt einzusetzen. Im Laufe der Zeit entwickeln
sich die Schnittstellen zu dieser Komponente weiter. Dadurch häuft unser Produkt, das ein-
mal sehr gut mit besagter Drittanbieterkomponente funktioniert hat, ohne jedes Versäum-
nis oder Fehlverhalten unsererseits technische Schulden an. Eine solche Situation mag
zwar vorhersehbar sein (es ist nicht ungewöhnlich, dass der Hersteller seine Komponen-
tenschnittstelle irgendwann einmal ändert), sie ist aber nicht vermeidbar, weil wir nicht
vorhersagen können, wie die Komponentenentwickler die Komponente in der Zukunft wei-
terentwickeln.
Die letzte Variation der technischen Schulden sind die strategischen technischen Schulden.
Sie sind ein Werkzeug, das Organisationen helfen kann, die wirtschaftlichen Aspekte wich-
tiger, oft zeitgebundener Entscheidungen besser zu quantifizieren und auszunutzen. So
könnte eine Organisation z.B. absichtlich die strategische Entscheidung treffen, in der Pro-
duktentwicklung Abstriche zu machen, um ein wichtiges kurzfristiges Ziel zu erreichen –
etwa ein termingebundenes Produkt auf den Markt zu bringen. Auch wenn die Gefahr
besteht, dass einer Organisation das Geld ausgeht, bevor das Produkt fertig ist, ist die Auf-
nahme technischer Schulden möglicherweise die einzige Möglichkeit, einen vollständigen

178
8.2
Die Folgen technischer Schulden

Zusammenbruch zu vermeiden – es bringt ein Produkt bei verringerten Entwicklungskos-


ten auf den Markt, generiert in der Folge Einnahmen, die ihm helfen, die Entwicklung fort-
zusetzen, um das Produkt fertig zu entwickeln und die technischen Schulden abzutragen.
Aber ganz egal, wie sie angesammelt wurden: Der Begriff »technische Schulden« ist in
jedem Fall eine starke Metapher, weil er auf ein wichtiges Problem hinweist. Und er erzeugt
vor allem bei Geschäftsleuten ein nachhaltiges Echo, weil diese sich in aller Regel recht gut
mit finanziellen Schulden auskennen. Wenn sie also den Begriff »technische Schulden«
hören, wissen sie die Parallelen zu schätzen und einzuordnen – vor allem die Tatsache,
dass für technische Schulden genau wie für finanzielle Schulden Sollzinsen anfallen, die
sich in Form eines zusätzlichen künftigen Entwicklungsaufwands äußern. Wir können also
entscheiden, weiterhin Zinsen zu bezahlen (indem wir um die Probleme herumlavieren),
oder wir können die Schulden begleichen (indem wir z.B. den Code überarbeiten, um ihn
sauberer und leichter zu modifizieren gestalten).

8.2 Die Folgen technischer Schulden


Je höher die technischen Schulden ansteigen, umso ernster die Folgen. Lassen Sie uns
einige der wesentlicheren Konsequenzen hoher technischer Schulden betrachten (zusam-
mengefasst in Abbildung 8.1).

Unvorhersehbarer Wendepunkt

Zunehmend verzögerte Auslieferung

Beträchtliche Anzahl an Defekten

Steigende Entwicklungs- und Support-Kosten

Folgen technischer Schulden

Das Produkt verkümmert

Schwindende Vorhersehbarkeit

Leistungseinbruch

Allgemeiner Frust

Sinkende Kundenzufriedenheit

Abb. 8.1: Die Folgen technischer Schulden

179
Kapitel 8
Technische Schulden

8.2.1 Unvorhersehbarer Wendepunkt


Ein wichtiges Merkmal technischer Schulden ist die Tatsache, dass sie in unvorhersehbarer,
nicht linearer Weise ansteigen. Haben sich bereits einige technische Schulden angehäuft,
kann jede noch so geringe zusätzliche »Krediterhöhung« deutlich mehr Schaden anrich-
ten, als das Ausmaß dieser neuen Schulden allein vermuten ließe. Und irgendwann wach-
sen die technischen Schulden dann zu einer Art »kritischen Masse« an, so dass das
Produkt an einem Wendepunkt ankommt, an dem es unbeherrschbar bzw. chaotisch wird.
In dieser Situation stellen selbst kleine Modifikationen an dem Produkt massive Unsicher-
heitsfaktoren dar. Die hier beschriebene Nichtlinearität stellt ein bedeutendes Geschäftsri-
siko dar, denn wir wissen schließlich nicht, ob nicht schon der nächste Tropfen das Fass
endgültig zum Überlaufen bringt – doch wenn er es tut, dann werden die Folgen nun deut-
lich schlimmer sein als zuvor.

8.2.2 Zunehmend verzögerte Auslieferung


Die Aufnahme technischer Schulden bedeutet, dass wir ein Darlehen aus der Zeit aufneh-
men, die uns künftig zur Verfügung steht. Je größer die Schulden heute sind, umso langsa-
mer wird morgen die Velocity (Entwicklungsgeschwindigkeit). Und ein Abfall der Velocity
bedeutet, dass es länger dauert, neue Funktionen und Produkt-Fixes an die Kunden auszu-
liefern. Sind also hohe technische Schulden vorhanden, vergrößert sich auch die Zeit-
spanne zwischen den Lieferungen, statt zu sinken. In den heiß umkämpften Märkten
arbeiten technische Schulden daher aktiv gegen unsere besten Interessen.

8.2.3 Beträchtliche Anzahl an Defekten


Produkte mit beträchtlichen technischen Schulden werden komplexer, was es erschwert,
Dinge richtig zu machen. In Summe können die Defekte dazu führen, dass immer öfter
Fehler am Produkt auftreten. Und diese Fehler unterbrechen die Entwicklungsarbeit, die
eigentlich dazu dienen soll, das Produkt wertvoller zu machen (statt es einfach nur zu repa-
rieren). Die zusätzliche Arbeit für die Organisation der Schadensbehebung frisst die Zeit
auf, die uns zum Entwickeln neuer Funktionen zur Verfügung steht. Irgendwann beginnen
wir zu ertrinken, sind aber so damit beschäftigt, das schadensgefüllte Wasser zu treten,
dass wir nicht mehr wissen, wie wir uns aus dem Schlamassel befreien sollen.

8.2.4 Steigende Entwicklungs- und Support-Kosten


Mit zunehmenden technischen Schulden steigen auch die Kosten für Entwicklung und
Support. Was einmal einfach und billig war, ist nun kompliziert und teuer. Selbst kleine
Änderungen werden sehr kostspielig.
Wenn die Schuldenkurve in Abbildung 8.2 ihren aggressiven Anstieg beginnt, steigen die
technischen Schulden zu einer kritischen Masse an und erreichen den Wendepunkt.
Steigende Kosten wirken sich natürlich auch auf die Beantwortung der Frage aus, ob es
ökonomisch sinnvoll ist, mit einer Funktion oder der Behebung der Defekte weiterzuma-
chen. Eine Funktion (oder ein zu reparierender Defekt), die bei niedrigen technischen
Schulden mit nur geringen Kosten gebaut werden könnte, ist angesichts hoher technischer
Schulden möglicherweise zu teuer. Damit lassen sich unsere Produkte aufgrund der stei-

180
8.2
Die Folgen technischer Schulden

genden Kosten also nicht mehr so einfach an die sich weiterentwickelnde Umgebung
anpassen, in der sie existieren müssen.

Niedrige technische Schulden


Änderungskosten

Hohe technische Schulden

Zeit

Abb. 8.2: Die Änderungskostenkurve wird durch technische Schulden beeinflusst.

8.2.5 Das Produkt verkümmert


Wenn wir jedoch aufhören, Funktionen zu ergänzen oder Defekte zu reparieren, die unser
alterndes Produkt verjüngen bzw. modernisieren könnten, wird das Produkt sowohl für
gegenwärtige als auch für potenzielle zukünftige Kunden immer unattraktiver. In der Kon-
sequenz beginnt das Produkt zu verkümmern und stellt dann für die meisten Kunden ein-
fach keine brauchbare Option mehr dar. Und diejenigen, die bei dem Produkt bleiben,
können meist nicht anders – sobald sich jedoch die Gelegenheit bietet, zu einem anderen
Produkt zu wechseln, werden sie diese vermutlich ergreifen!

8.2.6 Schwindende Vorhersehbarkeit


Es ist nahezu unmöglich, für ein Produkt mit sehr hohen technischen Schulden irgendeine
Art von Vorhersage zu treffen. Selbst die erfahrensten Teammitglieder können in dieser
Situation kaum mehr sinnvolle Schätzungen vornehmen, weil sich einfach nicht mit
Sicherheit sagen lässt, wie lange ein Arbeitsvorgang bei einem schuldengeplagten Produkt
dauern könnte. Folgerichtig sind wir somit auch kaum noch in der Lage, Verpflichtungen
einzugehen und diese sinnvoll zu erfüllen. Die Organisation verliert das Vertrauen in die
Aussagen des Entwicklungsteams und die Kunden verlieren das Vertrauen in die Organisa-
tion!

8.2.7 Leistungseinbruch
Leider schrauben alle Beteiligten bei einer wachsenden technischen Schuldenlast auch ihre
Erwartungen an die Entwicklungsleistungen zurück – also an das, was möglich ist. Und
diese gesenkten Erwartungen setzen sich automatisch durch die gesamte Wertekette hin-
durch fort und führen letztendlich zu einem organisationsweiten Leistungseinbruch.

181
Kapitel 8
Technische Schulden

8.2.8 Allgemeiner Frust


Die unglückliche menschliche Konsequenz aus der Anhäufung hoher technischer Schul-
den ist ebenfalls ein spürbarer Anstieg des Frustrationspegels aller Beteiligten in der Wer-
tekette. Die Häufung all dieser kleinen, aber nervenden Abstriche macht die Arbeit an dem
Produkt zu einer Plackerei. Irgendwann ist alle Freude an der Entwicklung komplett ver-
pufft und wird stattdessen durch den tagtäglichen Kampf mit den Problemen ersetzt, die
niemand haben möchte (oder sollte). Die Leute brennen schlicht aus und die fähigsten Mit-
glieder des Entwicklungsteams verlassen das Team und wenden sich dankbareren sich bie-
tenden Gelegenheiten zu. Da sie aber diejenigen waren, die effektiv etwas an der
Schuldensituation hätten ändern können, wird für die Zurückgebliebenen alles nur noch
schlimmer – und die Moral verschlechtert sich immer schneller.
Technische Schulden nehmen nicht nur dem technischen Personal die Freude, auch auf
das Management wirkt sie sich verheerend aus. Wie lange wollen wir unternehmerische
Verpflichtungen eingehen, die nicht erfüllt werden können? Und was ist mit unseren
armen Kunden, die versuchen, mit unserem schuldengebeutelten Produkt ihre Geschäfte
zu führen? Auch sie werden der wiederholten Produktausfälle und unserer Unfähigkeit,
unsere Versprechen zu halten, schnell müde. Das Vertrauen, das einst in der gesamten
Wertekette existierte, wird durch Frust und Ablehnung ersetzt.

8.2.9 Sinkende Kundenzufriedenheit


Die Kundenzufriedenheit sinkt in dem Maße, in dem der Frust der Kunden zunimmt. Das
Ausmaß des Schadens, der durch die technischen Schulden verursacht wurde, ist also nicht
nur auf das Entwicklungsteam oder vielleicht noch die Entwicklungsorganisation als Gan-
zes beschränkt. Die Konsequenzen der technischen Schulden können unsere Kunden und
deren Wahrnehmung unserer Organisation ganz ebenfalls beträchtlich beeinflussen.

8.3 Ursachen der technischen Schulden


Rufen Sie sich in Erinnerung, dass technische Schulden in drei Hauptvarianten auftreten,
die jeweils eine andere Ursache haben: Unvermeidliche technische Schulden häufen sich
ungeachtet aller unserer Vorsichtsmaßnahmen an. Naive technische Schulden resultieren
aus den Unzulänglichkeiten unserer Teammitglieder, unserer Organisation oder unserer
Prozesse. Und strategische Schulden sind etwas, zu dem wir uns bewusst entschließen,
wenn ihre Vorteile die Kosten der Schulden deutlich übersteigen.

8.3.1 Druck hinsichtlich des Erreichens einer Deadline


Sowohl strategische als auch naive technische Schulden werden jedoch oft durch den unter-
nehmerischen Druck getrieben, eine wichtige Deadline zu erreichen (siehe Abbildung 8.3).
Die senkrechte Achse repräsentiert die Menge der Arbeit, die wir zu einem gewünschten
Freigabetermin (gezeigt auf der waagerechten Achse) erreichen wollen. Die Linie zwischen
der Menge an Arbeit und dem gewünschten Freigabetermin entspricht der konstanten,
geplanten Velocity, mit der die Arbeit verrichtet werden muss, um den Termin halten zu
können. Indem wir mit der geplanten Velocity arbeiten, wollen wir hochwertige Funktio-

182
8.3
Ursachen der technischen Schulden

nen fristgerecht fertigstellen und gleichzeitig so wenig wie möglich technische Schulden
anhäufen.

Tatsächliche Velocity–Rate,
mit der hochwertige Arbeit
Menge der Arbeit

abgeschlossen wird

Geplante
Velocity

Zeit
Gewünschter Wahr-
Freigabe- scheinlicher
termin Freigabe-
termin

Abb. 8.3: Der Druck hinsichtlich des Erreichens einer Deadline kann zu technischen Schulden
führen.

Nachdem wir jedoch mit der Arbeit begonnen haben, stellt sich heraus, dass die tatsächli-
che Velocity bei der Herstellung hochwertiger Ergebnisse niedriger ist als die geplante Velo-
city. Falls wir also mit der gegenwärtigen Velocity weiterarbeiten, verpassen wir den
gewünschten Freigabetermin und beenden die Arbeit stattdessen am wahrscheinlichen
Freigabetermin.

8.3.2 Erfolglose Versuche der Velocity-Beschleunigung


An dieser Stelle müssen wir eine geschäftliche Entscheidung treffen: Wollen wir unser Ziel
zurückstecken, um das gewünschte Freigabedatum einzuhalten oder wollen wir uns mehr
Zeit nehmen, so dass die Auslieferung am wahrscheinlichen Freigabetermin erfolgt? Leider
lehnt die Organisation in vielen Fällen beide Möglichkeiten ab und entscheidet, dass das
Team den gewünschten Freigabetermin mit allen Funktionen einhält. In dieser Situation
wird das Team, das die Arbeit verrichtet, angewiesen, seine Velocity zu beschleunigen, um
den Wunschtermin zu halten (siehe Abbildung 8.4).
Wenn das Team nun mit zunehmender Velocity arbeitet, muss es sich bewusst dafür ent-
scheiden, technische Schulden aufzunehmen (das bedeutet, es muss Abstriche machen,
um schnell genug für den Wunschtermin zu sein). Vielleicht wird das Design nicht so gut,
wie es sein könnte oder bestimmte Tests (wie etwa Belastungstests) werden abgekürzt oder
weggelassen. In der Folge häufen wir technische Schulden an, wie der dreieckige Bereich
in Abbildung 8.4 zeigt. Dieser Bereich stellt alle Arbeiten dar, die wir ausgeführt haben soll-
ten, aber nicht geschafft haben.

183
Kapitel 8
Technische Schulden

Beschleunigte Velocity – Velocity, die


Menge der Arbeit

gebraucht wird, um alle Funktionen zum


gewünschten Termin abzuschließen

Geplante
Dieser Bereich verkörpert die
Velocity
angehäuften technischen Schulden

Zeit
Gewünschter Wahr-
Freigabe- scheinlicher
termin Freigabe-
termin

Abb. 8.4: Anhäufung technischer Schulden, um ein unvernünftig festgelegtes Ziel und einen
unrealistischen Termin zu schaffen

8.3.3 Gerücht: Weniger Testen kann die Velocity beschleunigen


Ein hartnäckiges Gerücht besagt, dass Tests zusätzlicher Ballast sind und man die Velocity
beschleunigen kann, indem man die Tests reduziert (siehe Abbildung 8.5).

Gerücht Zunehmende
Schulden
Testen reduzieren
Es geht schneller

Realität Zunehmende
Schulden
Schneller, schneller! Testen reduzieren
Es geht langsamer

Gute Praxis
Niedrigere Schulden
Nutze gute technische
Praktiken (wie TTD)
Es geht schneller

Abb. 8.5: Wie Tests die Velocity beeinflussen – Gerücht, Realität und bewährte Praxis

184
8.3
Ursachen der technischen Schulden

Die Realität sieht so aus, dass eine Verringerung der Tests sowohl die Schulden erhöht als
auch dafür sorgt, dass wir noch langsamer werden, weil Probleme erst später entdeckt wer-
den, wenn es viel mehr Zeit kostet, sie zu beheben. Erfahrene Teams liefern Ergebnisse
guter Qualität schneller und mit geringeren technischen Schulden aus, wenn das Testen
grundlegend im Entwicklungsprozess verankert ist. Diese Teams nutzen gute technische
Praktiken wie etwa eine testgetriebene Entwicklung (Test-Driven Development; TDD) – bei
der der Entwickler einen kleinen Unit Test schreibt und automatisiert, bevor er den Code
schreibt, der den Test besteht (Crispin und Gregory 2009).

8.3.4 Schulden bauen auf Schulden auf


Künftige technische Schulden bauen sich schnell auf bereits vorhandenen Schulden auf.
Und gleichzeitig machen sich wirtschaftlich schädliche Konsequenzen bemerkbar. Abbil-
dung 8.6 verdeutlicht, welche Folgen es hat, wenn Release 2 auf den technischen Schulden
aus Release 1 gebaut wird.
In Abbildung 8.6 ist die tatsächliche Velocity während Release 2 langsamer als in Release 1.
Es ist klar, dass wir bei dieser Geschwindigkeit den angestrebten Freigabetermin wieder
nicht erreichen werden. Und wieder besteht die Organisation darauf, dass das Team das
gewünschte Freigabedatum unter Beibehaltung aller Funktionen einhält. Daraufhin häu-
fen wir noch mehr technische Schulden an.

Tatsächliche Velocity von Release 2


ist wegen der technischen Schulden
aus Release 1 viel langsamer
Menge der Arbeit

Dieser Bereich verkörpert


zusätzlich angehäufte
technische Schulden
Beschleunigte
Velocity von Velocity
Release 1

Zeit
Release 1 Release 2

Abb. 8.6: Wenn die technischen Schulden zunehmen, sinkt die Velocity.

Wenn sich dieses Muster fortsetzt, verläuft die Velocity-Linie schließlich waagerecht. In die-
sem Zustand wären die technischen Schulden im System so hoch, dass die effektive Velo-
city bei Null läge. Das Ergebnis wäre die Art von Produkt, bei der wir uns davor fürchten,
irgendwelche Änderungen vorzunehmen, weil eine kleine Änderung in einem Bereich
dafür sorgen könnte, dass 18 andere Dinge in scheinbar völlig unzusammenhängenden
Bereichen des Produkts ausfallen. Was aber noch viel schlimmer ist: Wir haben keine Mög-
lichkeit vorherzusagen, ob diese 18 Dinge kaputtgehen. Und natürlich haben wir auch kein

185
Kapitel 8
Technische Schulden

nennenswertes Test-Framework, das uns helfen könnte festzustellen, wann sie kaputtge-
hen – aber keine Panik, unsere Kunden werden uns das schon wissen lassen!
Wenn wir uns erst einmal in einer Situation mit hohen technischen Schulden wiederfin-
den, sind alle Entscheidungen übel:
쐽 Wir machen nichts und das Problem verschlimmert sich.
쐽 Wir investieren immer mehr in die Reduzierung der technischen Schulden, die unsere
wertvollen Produktentwicklungsressourcen zunehmend auffressen.
쐽 Wir erklären den technischen Bankrott, tilgen die technischen Schulden und ersetzen
das schuldengeplagte Produkt durch ein neues Produkt mit all den Kosten und Risiken,
die die Entwicklung eines neuen Produkts mit sich bringt.
Wenn uns solche Entscheidungen drohen, ist es entscheidend, dass wir unsere technischen
Schulden richtig organisieren, bevor wir vollends die Kontrolle verlieren.

8.4 Technische Schulden müssen organisiert werden


Technische Schulden müssen ebenso wie finanzielle Schulden organisiert und verwaltet
werden. Wir müssen uns damit abfinden, dass kein Produkt schuldenfrei sein wird, des-
halb empfehle ich Ihnen auch nicht, eine Schuldenfreiheit anzustreben. Selbst wenn es
möglich wäre, sind die damit verbundenen wirtschaftlichen Aspekte vermutlich einfach
nicht zu rechtfertigen. Wir sollten jedoch die technischen Schulden so niedrig halten, dass
sie die künftige Produktentwicklung nicht signifikant beeinträchtigen.
Der Umgang mit den technischen Schulden erfordert eine ausgewogene Diskussion auf
technischer und unternehmerischer Ebene, die sowohl die Entwickler als auch das Manage-
ment mit einbeziehen muss. Das ist einer der Gründe, weshalb jedes Scrum-Team einen
Product Owner hat. Eine ausgewogene Diskussion der unternehmerischen und techni-
schen Ansichten führt zu guten ökonomischen Kompromissen. Wie ich in Kapitel 9
beschreibe, ist es deshalb ausgesprochen wichtig, einen Product Owner zu wählen, der den
richtigen ökonomischen Scharfsinn besitzt, um sich in diese Diskussionen einbringen zu
können.
Bei der Handhabung technischer Schulden sind in erster Linie drei Aktivitäten gefragt, die
ich in den folgenden Abschnitten vorstellen werde (siehe Abbildung 8.7).

Die Zunahme technischer Schulden verwalten

Technische Schulden verwalten Technische Schulden sichtbar machen

Technische Schulden bedienen (zurückzahlen)

Abb. 8.7: Aktivitäten zur Handhabung technischer Schulden

186
8.5
Die Zunahme technischer Schulden überwachen

8.5 Die Zunahme technischer Schulden überwachen


Ein kritischer Aspekt im Umgang mit technischen Schulden ist die Überwachung des
Schuldenanstiegs. Wie ich eingangs bereits erwähnt habe, können wir nur eine begrenzte
Menge technischer Schulden aufnehmen, bevor sie zu einer kritischen Masse anwachsen.
Im Prinzip ist es so, als würden wir ständig neue Hypotheken auf unser Haus aufnehmen:
Irgendwann müssen wir dem Einhalt gebieten und sagen: »Nicht noch mehr!«, weil die
Konsequenzen sonst zu weitreichend wären.
Als Erstes müssen wir aufhören, unsere Produkte mit naiven Schulden zu belasten. (Im
Klartext heißt das: Wir dürfen nicht mehr so waghalsig und schlampig sein). Außerdem
müssen wir uns klarmachen, dass auch die Menge der strategischen oder unvermeidlichen
Schulden, die wir ohne Rückzahlung aufnehmen können, bevor wir den Wendepunkt
erreichen, endlich ist. Wie das geht, werde ich gleich noch erläutern. Nicht erläutern werde
ich dagegen, wie sich der Zuwachs an unvermeidbaren Schulden verwalten lässt, da diese
Art von Schuldenanhäufung naturgemäß nicht zu verhindern ist (wir können sie aber den-
noch sichtbar machen und entsprechend bedienen, nachdem wir sie entdeckt haben).

8.5.1 Bewährte technische Praktiken anwenden


Der erste Ansatz im Umgang mit wachsenden technischen Schulden besteht darin, die nai-
ven Schulden auf unsere Produkte zu stoppen. Ein ausgezeichneter Ausgangspunkt hierfür
ist, sich bewährte technische Praktiken zu eigen zu machen. Diese Praktiken sind zwar
nicht formal in Scrum definiert, allerdings werden sie von allen erfolgreichen Scrum-
Teams, die ich bisher erlebt habe, in Form eines einfachen Designs, testgetriebener Ent-
wicklungsansätze, kontinuierlicher Integration, automatisiertem Testen, Refactoring usw.
nutzbringend eingesetzt (mehr dazu siehe auch Kapitel 20). Wenn Teams diese Maßnah-
men verstehen und proaktiv einsetzen, gelingt es ihnen in der Regel auch, einen weiteren
Anstieg der naiven Schulden, die auf ihren Produkten lasten, zu stoppen.
Im Bezug auf die bereits aufgelaufenen technischen Schulden ist das Refactoring des
Codes eine gute Methode, um mit dem Abbau zu beginnen. Hierbei handelt es sich um
eine disziplinierte Technik, um den vorhandenen Code neu aufzubauen und seine interne
Struktur zu ändern, ohne sein externes Verhalten zu beeinflussen (Fowler et al. 1999). Mit
anderen Worten: Wir räumen hinter den Kulissen auf, aus Sicht des Kunden bleibt das Pro-
dukt aber unverändert. Ziel des Refactorings ist es, die Komplexität des Codes zu reduzie-
ren und gleichzeitig die Wartbarkeit und Erweiterbarkeit zu verbessern. In der Folge wird
uns die Arbeit erleichtert (das gleicht im Prinzip einer Art Umschuldung auf einen geringe-
ren Zinssatz).
Cunningham (2011) erläutert die Vorteile des Refactorings anhand eines Beispiels:
... Kunde ist bereit, für eine neue Funktion zu bezahlen. Funktion passt nicht. Code wird so
umgebaut, dass sie passt. Jetzt lässt sich die Funktion leicht implementieren. Man könnte dies
als Just-in-time-Refactoring bezeichnen. Ich würde es dem Management folgendermaßen
erklären: Wir hoffen, jede neue Anforderung in unserer Software berücksichtigen zu können.
Manchmal lässt sich eine Funktion aber nicht mehr unterbringen, so dass wir erst Platz schaf-
fen müssen, um die Funktion zu implementieren. ...

187
Kapitel 8
Technische Schulden

8.5.2 Eine starke Definition von Fertig benutzen


Arbeiten, die wir eigentlich schon bei der Erstellung einer Funktion hätten abschließen sol-
len, aber auf einen späteren Zeitpunkt verschoben haben, sind eine wichtige Ursache für
technische Schulden. Bei der Anwendung des Scrum-Entwicklungsverfahrens brauchen
wir eine starke Definition von Fertig (siehe Kapitel 4), damit das Team am Ende des Sprints
zu einer Lösung kommen kann, die wenige oder keine Schulden nach sich zieht.
Je mehr technische Aspekte in unserer Fertig-Checkliste berücksichtigt werden, umso
geringer ist die Wahrscheinlichkeit, dass wir technische Schulden anhäufen. Und wie ich
in Kapitel 4 ausgeführt habe, sind die Kosten für den Abbau technischer Schulden, die auf-
grund einer schwachen Definition von Fertig entstehen, oft deutlich höher, als wenn wir
diesen Aspekt bereits während des Sprints nicht aus dem Auge verlieren. Ohne eine starke
Definition von Fertig öffnen wir technischen Schulden praktisch Tür und Tor.

8.5.3 Die wirtschaftlichen Aspekte technischer Schulden richtig verste-


hen
Um technische Schulden strategisch und zu unserem Vorteil einzusetzen, müssen wir uns
zunächst einmal eingehend mit der Frage beschäftigen, wie sie die wirtschaftliche Seite
unserer Entscheidungen beeinflussen. Traurigerweise verstehen die meisten Organisatio-
nen die Implikationen technischer Schulden nicht gut genug, um korrekt quantifizieren zu
können, wie viel sie sie am Ende tatsächlich kosten werden. Schauen wir uns dazu ein Bei-
spiel an (siehe Abbildung 8.8).
Menge der Arbeit

100.000 $ zusätzliche Kosten


für die künftige Rückzahlung
dieser Schulden Durch diese
Geplante
Velocity Verzögerung gehen im Verkauf
450.000 $ verloren

Zeit in Monaten
13 Monate bis zum erreichbaren
Freigabetermin (keine spürbaren
technischen Schulden)
10 Monate bis zum gewünschten Freigabetermin
(die Einhaltung dieses Termins
erfordert technische Schulden)

Abb. 8.8: Beispiel einer ökonomischen Analyse technischer Schulden

188
8.5
Die Zunahme technischer Schulden überwachen

Nehmen wir einmal Folgendes an:


쐽 Unsere Entwicklungskosten belaufen sich jeden Monat auf 100.000 Dollar.
쐽 Realistisch betrachtet, können wir das angestrebte Auslieferungsdatum (nach 10 Mona-
ten) mit allen gewünschten und unverzichtbaren Funktionen nicht einhalten.
쐽 Einzelne Funktionen wegzulassen, ist keine Option.

Lassen Sie uns zwei mögliche Alternativen in Betracht ziehen. Erstens: Verschieben des
Auslieferungstermins um drei Monate, so dass wir die Arbeit an den geforderten Funktio-
nen mit minimalen technischen Schulden nach 13 Monaten sinnvoll und professionell
abschließen können. Die gesamten Entwicklungskosten würden dann bei 1,3 Millionen
Dollar liegen. In Gesprächen mit Verkauf und Marketing stellen wir außerdem klar, dass
bei einer dreimonatigen Verzögerung mit einem Verlust von 450.000 Dollar an Verkaufs-
erträgen zu rechnen ist.
Zweitens: Beschleunigen der Entwicklung, indem Abstriche gemacht werden, um den
ursprünglichen Auslieferungstermin nach 10 Monaten zu schaffen. Um die wirtschaftliche
Seite dieser Möglichkeit korrekt quantifizieren zu können, müssen wir wissen, wie viel es
kostet, die technischen Schulden aufzunehmen.
Und das ist genau die Stelle, an der es schwierig wird. Angenommen, wir fragen das Ent-
wicklungsteam: »Wenn ihr heute Kompromisse hinsichtlich des Designs und der Imple-
mentierung machen müsstet, um die unverzichtbaren Funktionen zum ursprünglichen
Auslieferungstermin fertig zu bekommen, wie viel würde es zusätzlich kosten, die Schul-
den nach der ersten Freigabe wieder abzubauen?«
Nehmen wir an, das Team diskutiert die Frage und glaubt, dass es vier Monate brauchen
würde, um das System aufzuräumen. Dann würde das bedeuten, dass es einen Monat län-
ger als die drei Monate braucht, die es ursprünglich durch die eingegangenen Kompro-
misse »gespart« hat. Außerdem kommen noch 100.000 Dollar mehr an
Entwicklungskosten hinzu (insgesamt also 1,4 Millionen Dollar statt der 1,3 Millionen Dol-
lar für die erste Option). Das sind 100.000 Dollar, die die Organisation nicht aufbringen
müsste, wenn wir die Arbeit gleich richtig gemacht und nicht erst technische Schulden auf
das Produkt aufgenommen hätten.
Oberflächlich betrachtet, scheint die korrekte ökonomische Entscheidung klar zu sein: Sol-
len wir technische Schulden in Höhe von 100.000 Dollar aufnehmen, um einen Ertragszu-
wachs in Höhe von 450.000 Dollar zu generieren? Sicher, wer würde das nicht tun? Und
das wäre gegebenenfalls auch die richtige Antwort, wenn wir glauben, dass wir alle (oder
zumindest die meisten) wichtigen Kostenfaktoren berücksichtigt haben, die mit den tech-
nischen Schulden verbunden sind.
Hier wurden jedoch mindestens zwei von vermutlich vielen weiteren Faktoren nicht
bedacht:
쐽 Was ist mit den Verzögerungskosten für die Rückzahlung der technischen Schulden?
Die 100.000 Dollar decken die Kosten ab, die das Team für die Reduzierung der techni-
schen Schulden in der Zukunft braucht. Was aber ist mit den Kosten für die Zeit, die
nötig ist, um den Schuldenabbau zu realisieren? Zeit, die damit zugebracht wird, Schul-
den zu tilgen, verursacht wiederum Verzögerungskosten für irgendein anderes Produkt
oder die nächste Version desselben Produkts. Was kostet diese Verzögerung? Wenn das

189
Kapitel 8
Technische Schulden

Team einen Monat extra braucht, um die Schulden zurückzuzahlen, wird wahrschein-
lich die Freigabe eines anderen Produkts um einen Monat verschoben. Die Kosten für
eine verpasste Gelegenheit haben also echte wirtschaftliche Auswirkungen, die man be-
achten muss.
쐽 Die meisten Organisationen gehen nicht besonders gut mit der Rückzahlung techni-
scher Schulden um. Wenn es hart auf hart kommt, zieht es das Management häufig vor,
neue Funktionen zu entwickeln, statt Funktionen zu überarbeiten, die bereits existie-
ren. In Wirklichkeit bauen wir unsere Schulden also unter Umständen gar nicht ganz
oder teilweise ab, sondern häufen obendrein höchstwahrscheinlich sogar noch »Soll-
zinsen« an. Das muss ebenfalls bedacht werden.
Tabelle 8.1 fasst die Zahlen aus diesem Beispiel zusammen.

Schulden vermeiden Schulden aufnehmen


Monatliche Entwicklungs- 100.000 Dollar 100.000 Dollar
kosten
Entwicklungsmonate gesamt 13 10
Entwicklungskosten gesamt 1,3 Mill. Dollar 1 Mill. Dollar
Verzögerung in Monaten 3 0
(bis zur Freigabe des Pro-
dukts)
Monatliche Verzögerungs- 150.000 Dollar 150.000 Dollar
kosten
Verzögerungskosten gesamt 450.000 Dollar 0
Monate bis zum Schulden- 0 4
abbau
Kosten des Schuldenabbaus 0 Dollar 400.000 Dollar
Gesamtkosten in Lifecycle 1,75 Mill. Dollar 1,4 Mill. Dollar
Profits
Verzögerungskosten der 0 Dollar X
zusätzlichen Zeit für den
Schuldenabbau
Gesamtzinszahlung auf 0 Dollar Y
technische Schulden
Andere schuldenbedingte 0 Dollar Z
Kosten
Reale Kosten in Lifecycle 1,75 Mill. Dollar 1,4 Mill. Dollar + X + Y + Z
Profits

Tabelle 8.1: Beispielrechnung: Vermeidung technischer Schulden versus Aufnahme technischer


Schulden

190
8.6
Technische Schulden sichtbar machen

Die Tentakel technischer Schulden reichen somit ganz offensichtlich an viele unterschied-
liche Aspekte der gesamten wirtschaftlichen Berechnung heran. Und wenn man es unter-
lässt, wenigstens die wichtigsten dieser Aspekte in Betracht zu ziehen, wird man es nicht
schaffen, die ökonomischen Gegebenheiten, mit denen man rechnen muss, wenn man
technische Schulden aufnimmt, korrekt zu quantifizieren.
Sollten natürlich die Zahlen dafür sprechen, die Schulden aufzunehmen – weil z.B. unsere
Organisation ruiniert wäre, wenn wir die Schulden nicht aufnehmen und das Produkt mit
allen unverzichtbaren Funktionen auf den Markt bringen würden, oder wir es nicht schaf-
fen, die ersten am Markt zu sein und damit den Löwenanteil unserer Gewinne verlieren –,
müssen wir nicht erst über die weniger wichtigen Faktoren nachgrübeln, weil wir ja schon
wissen, dass es ökonomisch sinnvoll ist, die Schulden aufzunehmen.
Oft ist die Entscheidung allerdings nicht ganz so klar. Die Beantwortung der Frage, ob man
nun Schulden aufnehmen sollte oder nicht, erfordert normalerweise eine detaillierte Ana-
lyse, um die beste Option zu ermitteln. Wenn Sie sich nicht ganz sicher sind, dann nehmen
Sie die Schulden lieber nicht auf. Meiner Erfahrung nach unterschätzen die meisten Orga-
nisationen die wahren Kosten, die bei der Aufnahme technischer Schulden entstehen, ganz
erheblich und sind zudem in Bezug auf deren Abbau auch nicht annähernd so eifrig, wie
sie glauben.

8.6 Technische Schulden sichtbar machen


Einer der Hauptvorteile der Metapher der technischen Schulden ist, dass sie es dem Ent-
wicklungsteam und dem Management erlaubt, die notwendige Diskussion zu diesem
Thema in einem gemeinsamen Kontext zu führen. Für diese Gespräche muss beiden Grup-
pen der Stellenwert des Produkts in Bezug auf die technischen Schulden klar sein – und
zwar in einer für alle Beteiligten verständlichen Weise.

8.6.1 Technische Schulden auf geschäftlicher Ebene sichtbar machen


Das Problem vieler Organisationen besteht darin, dass zwar das Entwicklungsteam eine
Vorstellung von dem Stellenwert des Produkts in Bezug auf die technischen Schulden hat,
das Management aber üblicherweise nicht. Fragen Sie jemanden vom technischen Perso-
nal, der ein Produkt kennt, an welcher Stelle die größte Konzentration an technischen
Schulden in dem Projekt zu finden ist – er wird Ihnen die Frage mit hoher Wahrscheinlich-
keit fundiert beantworten. Ein Manager, dem Sie dieselbe Frage stellen, hat dagegen ver-
mutlich keine Ahnung, wie viele technische Schulden existieren oder von welcher Art sie
sind.
Bei finanziellen Schulden wäre das nicht der Fall: Fragen Sie einen der Manager nach dem
Schuldenstand der Organisation und er wird Ihnen eine sehr akkurate Antwort geben.
Aus diesem Grund ist es wichtig, dem Management ebenso einen Einblick in den Stand der
technischen Schulden des Produkts zu ermöglichen. Wenn ich technische Schulden zah-
lenmäßig abbilden könnte – und zurzeit wird intensiv danach geforscht, wie sie sich quan-
tifizieren lassen könnten (SEI 2011) –, dann würde ich gleich neben die finanziellen
Schulden in der Bilanz die kurzfristigen und langfristigen technischen Schulden eintragen

191
Kapitel 8
Technische Schulden

(siehe Tabelle 8.2).

Güter Belastungen
Bargeld 600.000 Dollar Aktuelle Belastungen
Außenstände 450.000 Dollar Wechselverbindlichkeiten 100.000 Dollar
Abrechnungsverbindlichkeiten 75.000 Dollar
Kurzfristige technische Schul- 90.000 Dollar
den
Werkzeuge und 250.000 Dollar Langfristige Belastungen
Ausrüstungen
Verbindlichkeiten 300.000 Dollar
Langfristige technische 650.000 Dollar
Schulden
... ... ... ...
Tabelle 8.2: Technische Schulden in der Bilanzaufstellung der Organisation

Ich kenne eigentlich keine Organisation, die ihre kurzfristigen und langfristigen Schulden
in ihrer Bilanz mit aufführt (obwohl ich das für eine gute Idee halten würde). Dieses Bei-
spiel soll daher lediglich verdeutlichen, dass jede Organisation eine Methode finden muss,
das Ausmaß der technischen Schulden eines Produkts auf eine Art zu kommunizieren, die
auch das Management versteht – ansonsten bekommt die Organisation keinen richtigen
Eindruck vom wahren Zustand des Produkts und kann keine sinnvollen wirtschaftlichen
Entscheidungen treffen.
Manche Organisationen machen die Folgen der technischen Schulden sichtbar, indem sie
die Velocity, also die Entwicklungsgeschwindigkeit, über die Zeit verfolgen. Abbildung 8.6
zeigt, wie eine Zunahme an technischen Schulden zu einem Abfall der Entwicklungsge-
schwindigkeit führt. Dieser Abfall kann in finanziellen Begriffen erklärt werden. Nehmen
wir z.B. an, wir hätten ein Scrum-Team mit Fixkosten in Höhe von 20.000 Dollar pro
Sprint und einer Entwicklungsgeschwindigkeit von 20 Punkten pro Sprint. Mithilfe dieser
Zahlen können wir ausrechnen, dass die Kosten pro Punkt 1.000 Dollar betragen. Wenn
die Anhäufung technischer Schulden dafür sorgen würde, dass die Entwicklungsgeschwin-
digkeit des Teams auf 10 Punkte pro Sprint sinkt, würden die Kosten pro Punkt auf 2.000
Dollar ansteigen. Müsste das Team nun etwa 200 Punkte abschließen und würde die Ent-
wicklungsgeschwindigkeit auf die Hälfte sinken, dann würde Arbeit, die eigentlich
200.000 Dollar kostet, nun 400.000 Dollar kosten. Die Entwicklungsgeschwindigkeit hilft
uns also dabei, die finanziellen Auswirkungen der Zinszahlungen auf die angehäuften
technischen Schulden zu erkennen.

8.6.2 Technische Schulden auf der technischen Ebene sichtbar machen


Techniker wissen oft schon von sich aus, an welcher Stelle des Produkts zumindest die
größten technischen Schulden zu erwarten sind. Allerdings ist dieses Verständnis oft nicht
auf eine Weise sichtbar, die sich analysieren, diskutieren und in geeignete Maßnahmen

192
8.6
Technische Schulden sichtbar machen

umsetzen lässt. Abbildung 8.9 zeigt drei Methoden, mit denen man technische Schulden
auf der technischen Ebene sichtbar machen kann.
Erstens sollten technische Schulden genau wie Defekte in einem vorhandenen Fallbearbei-
tungs- bzw. Ticket-System aufgezeichnet werden (Abbildung 8.9 links). Das hat den Vorteil,
dass man die Schulden mit bekannten Tools und Techniken an einer vertrauten Stelle fest-
hält. Wenn die Informationen über die Schulden neben den Informationen über die
Defekte stehen, ist es wichtig, dass man die Schulden mit einem Etikett versieht, das das
Wiederfinden erleichtert, weil das Team beschließen könnte, die Schulden anders zu bedie-
nen als die Defekte (wie ich in Kürze diskutieren werden).

Technische Schulden im Technische Schulden im


Fallbearbeitungssystem Product Backlog Technische-Schulden-Backlog
Funktion A
Funktion B
Funktion C
Defekt 23
Techn. Schulden
Refact. X
Funktion D
Funktion E
Funktion F

Abb. 8.9: Möglichkeiten, technische Schulden auf der technischen Ebene sichtbar zu machen

Man kann auch so vorgehen, dass man Product-Backlog-Elemente anlegt, die die techni-
schen Schulden repräsentieren (Abbildung 8.9 Mitte). Damit verleiht man den wichtigen
technischen Schulden eine Sichtbarkeit, die mit der der neuen Funktionen im Product
Backlog gleichauf ist. Teams nutzen diesen Ansatz typischerweise, wenn die Kosten für den
Abbau der technischen Schulden relativ hoch sind und der Product Owner in die Entschei-
dung einbezogen werden muss, wie diese Arbeit im Verhältnis zu der Arbeit an den neuen
Funktionen im Product Backlog eingeordnet werden soll.
Ein dritter Ansatz sieht vor, ein spezielles Backlog für die technischen Schulden anzulegen,
das die einzelnen Schuldenobjekte sichtbar macht (Abbildung 8.9 rechts). Immer wenn
neue technische Schulden entdeckt oder in das Produkt eingeführt werden, kann ein Mit-
glied des Entwicklungsteams einen neuen Eintrag im Technische-Schulden-Backlog vor-
nehmen. Dadurch sieht das Entwicklungsteam nicht nur den Stellenwert der einzelnen
technischen Schulden, sondern kann auch proaktiv festlegen, wann es diese jeweils bedie-
nen möchte.
Für Teams, die am selben Ort arbeiten, ist es am einfachsten, an irgendeiner Wand eine
Tafel für die technischen Schulden zu installieren und die einzelnen Schuldenobjekte mit
Klebezetteln oder Karten darzustellen. Normalerweise platziert man die Schuldentafel

193
Kapitel 8
Technische Schulden

direkt neben dem Sprint Backlog, damit das Team die Schulden während der Sprint-Pla-
nung sieht und in Betracht ziehen kann, sie im nächsten Sprint abzubauen (auf diesen
Ansatz komme ich im nächsten Abschnitt).
Die meisten Teams behandeln das Schulden-Backlog relativ formlos, indem sie einfach
die Karten mit den technischen Schulden an die Wand hängen. Man könnte sich aber
auch die Zeit nehmen, es etwas aufwendiger zu pflegen, indem man die Karten sortiert
oder wenigstens grob beschreibt, welcher Aufwand nötig wäre, um die jeweiligen Schul-
den abzuarbeiten.

8.7 Technische Schulden abbauen


Die letzte Aktivität bei der Handhabung der technischen Schulden ist das Abbauen bzw.
Zurückzahlen der Schulden. Wenn ich vom Abbau der Schulden rede, dann finde ich es
immer hilfreich, die folgenden Statuskategorien zu benutzen:
쐽 Zufällig entdeckte technische Schulden – Schulden, derer sich das Entwicklungsteam
nicht bewusst war, bis sie während der normalen Arbeit an dem Produkt aufgedeckt
wurden. Z.B. fügt das Team eine neue Funktion zu dem Produkt hinzu und merkt da-
bei, dass vor Jahren jemand, der schon lange nicht mehr im Team ist, eine Notlösung in
den Code eingebaut hat.
쐽 Bekannte technische Schulden – Schulden, die dem Entwicklungsteam bekannt sind
und mithilfe eines der zuvor diskutierten Ansätze sichtbar gemacht wurden.
쐽 Gezielt gewählte technische Schulden – Schulden, die bekannt sind und vom Entwick-
lungsteam ausgewählt wurden, um abgebaut zu werden.
Auf der Grundlage dieser Kategorien sollten Sie beim Abbau technischer Schulden im All-
gemeinen nach folgendem Algorithmus vorgehen:
1. Stellen Sie zunächst fest, ob die jeweiligen technischen Schulden tatsächlich getilgt
werden sollen (wie ich gleich noch erläutern werden, sollten nicht alle Schulden abge-
baut werden). Wenn ja, dann fahren Sie mit Schritt 2 fort.
2. Sofern Sie selbst an dem Code mitarbeiten und zufällig technische Schulden auffinden,
dann entfernen Sie diese (säubern Sie den Code). Übersteigt die Menge der zufällig auf-
gefundenen technischen Schulden einen vernünftigen Schwellenwert, dann säubern Sie
den Code, bis Sie den Schwellenwert erreichen. Stufen Sie die nicht abgetragenen, zufäl-
lig aufgefundenen Schulden anschließend als bekannte technische Schulden ein (indem
Sie z.B. entsprechende Einträge im Schulden-Backlog vornehmen).
3. Wählen Sie in jedem Sprint einige der bekannten technischen Schulden zum Abbau
während des aktuellen Sprints aus. Bevorzugen Sie dabei bekannte Schulden mit einem
hohen Zinssatz, bei deren Tilgung auch gleich noch für den Kunden werthaltige Arbeit
erledigt wird.
Die Ansätze, die in Abbildung 8.10 dargestellt sind, bauen auf diesem Algorithmus auf.
Im Folgenden werde ich die einzelnen Ansätze beschreiben und aufzeigen, wie man sie im
Rahmen des Scrum-Entwicklungsverfahrens einsetzt.

194
8.7
Technische Schulden abbauen

Nicht alle technischen Schulden sollten zurückgezahlt werden

Wenden Sie die Pfadfinderregel an


(bauen Sie die Schulden ab, wenn sie Ihnen begegnen)

Ansätze zum Abbau Zahlen Sie die technischen Schulden mit


technischer Schulden den höchsten Zinsen zuerst zurück

Zahlen Sie technische Schulden schrittweise zurück

Zahlen Sie technische Schulden zurück, während Sie


für den Kunden werthaltige Arbeit verrichten

Abb. 8.10: Ansätze zum Abbau technischer Schulden

8.7.1 Nicht alle technischen Schulden sollten abgebaut werden


Manchmal sollten technische Schulden nicht getilgt werden – und damit sind wir im einzi-
gen Bereich angelangt, in dem die Analogie zu den finanziellen Schulden nicht so richtig
funktioniert. Üblicherweise erwartet man, dass alle finanziellen Schulden irgendwann ein-
mal zurückgezahlt werden – auch wenn wir natürlich wissen, dass das nicht immer auch
tatsächlich passiert!
Es gibt eine Reihe von Szenarien, in denen technische Schulden offen bleiben sollten. Ich
werde hier drei davon vorstellen: Das Produkt nähert sich seinem Lebensende, es handelt
sich um einen Wegwerf-Prototyp und das Produkt ist nur kurzlebig.

Das Produkt nähert sich seinem Lebensende


Wenn ein Produkt beträchtliche technische Schulden angehäuft hat und sich seinem
Lebensende nähert, dann wäre es finanziell unverantwortlich, wenn man noch viel in den
Abbau der Schulden investiert. Besitzt das Produkt einen geringen Wert, dann würden wir
es (und damit auch die Schulden) wahrscheinlich stilllegen und unsere Ressourcen höher-
wertigen Produkten widmen. Handelt es sich um ein Produkt mit hohem Wert und hohen
technischen Schulden, dessen Lebensende naht, dann erscheint es sinnvoller, die hohen
Risiken und die hohen Kosten einer neuen Produktentwicklung auf sich zu nehmen, als
die technischen Schulden an dem alten Produkt zu begleichen.

Wegwerf-Prototyp
Manchmal ist es wirtschaftlich am sinnvollsten, technische Schulden, die man absichtlich
aufgenommen hat, niemals zurückzuzahlen. Ein Beispiel dafür ist die Entwicklung eines
Wegwerf-Prototypen, den man nur geschaffen hat, um etwas daraus zu lernen (Goldberg
und Rubin 1995). Der Wert des Prototyps besteht nicht im Code, sondern in dem validier-

195
Kapitel 8
Technische Schulden

ten Wissen, das wir erworben haben (Ries 2011). Da der Prototyp nicht für ein Leben im
Markt entwickelt wurde, lasten vermutlich große technische Schulden auf ihm. Weil es sich
aber um einen Wegwerf-Prototypen handelt, gibt es keinen Grund, die Schulden zu beglei-
chen. Falls wir natürlich einen Wegwerf-Prototypen herstellen und dann beschließen, ihn
doch nicht wegzuwerfen, sondern wie einen evolutionären Prototypen zu behandeln,
beginnen wir die ganze Sache schon mit einer Grundlage, die tief in technischen Schulden
steckt.

Das Produkt ist nur kurzlebig


Falls wir ein Produkt nur für ein kurzes Produktionsleben bauen, diktiert die Ökonomie,
dass technische Schulden nicht beglichen werden sollten. Ich verdeutliche dieses Szenario
anhand eines interessanten Beispiels, das mir in den späten 1980er Jahren begegnet ist.
Damals arbeitete ich für ParcPlace Systems, dem frühen Marktführer in objektorientierten
Umgebungen. In diesen Tagen half ich mehreren bedeutenden Banken an der Wall Street,
Smalltalk als Entwicklungsplattform zu übernehmen. In einem speziellen Fall wurde ich
hinzugezogen, um ein Team anzuleiten, dessen Mitglieder die objektorientierte Technolo-
gie und den effektiven Einsatz der Smalltalk-Entwicklungsumgebung besser verstehen ler-
nen sollten. Dieses Team hatte gerade eins der ersten Systeme für den Derivatehandel
hergestellt. Als ich hinzukam, fragte ich den Vizepräsidenten der Gruppe mit als Erstes, ob
ich einen Blick auf das Design und die Implementierung des Produkts werfen dürfe, das
das Team gerade gebaut hatte – es war noch nicht in Betrieb, sollte dies aber laut Plan bald
sein.
Nachdem ich mir einen Tag lang die Architektur und den Code angeschaut hatte, traf ich
mich mit dem Vizepräsidenten und sagte ihm, dass dieses System die vermutlich am häss-
lichsten aussehende Smalltalk-Implementierung sei, die ich jemals gesehen hatte. Ich
erklärte ihm, dass die Implementierung enorme Probleme hätte, die man sofort lösen
müsse, da das System (und auch das Unternehmen) ansonsten in ernsthafte Schwierigkei-
ten geraten würde.
Daraufhin sagte der Vizepräsident (wörtlich) zu mir: »Junge, wenn du auch nur einen Gro-
schen zum Aufräumen dieses Systems ausgibst, nehme ich dich persönlich mit nach drau-
ßen und erschieße dich.« Ich war, gelinde gesagt, wie vom Donner gerührt. Dann
antwortete ich: »Sie müssen mir hier vertrauen. Das Design des Systems ist mies und
außerdem furchtbar implementiert und Sie werden langfristig Probleme damit haben.« Er
erwiderte: »Sie verstehen mein Geschäft nicht. Wenn wir in diesem Markt mit einem
neuen Finanzinstrument herauskommen, dann machen wir den Löwenanteil am Gewinn
in den ersten drei Monaten. Ungefähr so lange dauert es, bis meine Konkurrenten mit ver-
gleichbaren Produkten nachziehen. Für mich ist es dann besser, diesen Markt zu verlassen
und ein neues Produkt zu entwickeln. Dieses neue System muss nur drei Monate lang hal-
ten. Es ist mir egal, ob Sie es mit Kaugummi und Rödeldraht zusammenhalten. Verzögern
Sie nur nicht die Einnahmephase, so dass meine Konkurrenten Gelegenheit haben, mich
aus dem Markt zu werfen. Wir legen jetzt los.«
Und genau das haben sie gemacht. In der ersten Betriebsstunde generierten die Händler, die
es benutzten, einen Profit von 14 Millionen Dollar. Ich persönlich war der Meinung, dass
sie ein hohes Risiko eingingen, wenn sie das System in seinem fragilen Zustand einschal-
teten, aber aus Sicht des Profits lag ich falsch.

196
8.7
Technische Schulden abbauen

Normalerweise bauen Organisationen keine Produkte, die nur eine Lebensdauer von drei
Monaten haben. Meist soll ein Produkt länger am Markt bestehen.

8.7.2 Wenden Sie die Pfadfinderregel an (Bauen Sie die Schulden ab,
sobald sie Ihnen begegnen)
Bei den Pfadfindern gibt es eine Regel: »Verlasse den Lagerplatz immer sauberer, als du ihn
vorgefunden hast.« Wenn es unordentlich ist, räumen sie es auf, ganz egal, wer die Unord-
nung verursacht hat. Sie verbessern bewusst die Umgebung für die nächste Gruppe Cam-
per. Bob Martin (und andere) hat ganz gut erklärt, wieso diese Regel auch für die
Produktentwicklung und technische Schulden gilt (Martin 2008).
Indem wir uns an diesen Grundsatz halten, versuchen wir, unser Produktdesign und die
Implementierung mit jedem Mal, wenn wir beides anfassen, ein bisschen besser zu
machen. Arbeitet ein Mitglied des Entwicklungsteams an einem Bereich des Produkts und
findet ein Problem (zufällig gefundene technische Schulden), dann wird es behoben. Und
zwar nicht etwa, weil es nur für dieses Teammitglied vorteilhaft wäre (obwohl es das zwei-
fellos ist), sondern weil es gut für das gesamte Entwicklungsteam und die Organisation ist.
Gemäß dem oben angegebenen Algorithmus bauen wir die zufällig entdeckten Schulden
bis zu einem vernünftigen Schwellenwert ab. Wir können das Team nicht einfach anwei-
sen, die gesamten zufälligen Schulden zu tilgen, sobald es sie entdeckt, denn das könnte
einen beträchtlichen Aufwand verursachen – und das Team befindet sich ja immerhin mit-
ten im Sprint und hat eigentlich andere Dinge zu tun. Und wenn es doch versucht, die
gesamten Schulden abzutragen, ist es möglicherweise nicht in der Lage, das ursprüngliche
Sprint-Ziel zu erreichen.
Deshalb könnte das Team einen gewissen Prozentsatz seiner Zeit für den Abbau zufällig
entdeckter Schulden reservieren, falls welche auftauchen. Dazu könnte man einerseits die
geschätzte Größe der einzelnen PBIs erhöhen, um zusätzlich anfallenden Schuldenabbau
zu ermöglichen. Alternativ könnte das Team bei der Sprint-Planung auch einen Teil seiner
Kapazität für zufällige Schulden reservieren, so habe ich in der Vergangenheit beispiels-
weise Teams erlebt, die sich zu diesem Zweck zwischen 5% und 33% der Sprint-Kapazität
vorbehalten haben. Falls Sie diesen Ansatz wählen, sollten Sie sich von Ihren speziellen
Umständen leiten lassen.
Nicht getilgte zufällige Schulden sollten nach ihrer Entdeckung als bekannte Schulden
klassifiziert und mit der von Ihrem Team verwendeten Visualisierungstechnik sichtbar
gemacht werden.

8.7.3 Bauen Sie technische Schulden schrittweise ab


Bei manchen Produkten häufen sich die technischen Schulden unter Umständen derart
an, dass die Teams, die daran arbeiten, am Ende oft gezwungen sind, riesige Schlussraten-
zahlungen vorzunehmen, um ihre Schuldenlast zu verringern. Bedeutend sinnvoller wäre
es jedoch, wenn sie laufend mehrere kleine, schrittweise Rückzahlungen für ihre bekann-
ten Schulden tätigen würden, als zu einem späten Zeitpunkt einen einzigen riesigen Betrag
auf einmal zu tilgen. Solche häufigeren kleineren Zahlungen sind in etwa mit monatlichen
Raten vergleichbar: Statt eines großen Betrags am Ende der Laufzeit wird jeden Monat ein
kleiner Teil der Schulden getilgt.

197
Kapitel 8
Technische Schulden

Ich mache mir immer Sorgen, wenn ich Teams über »Technische-Schulden-Sprints« oder
»Refactoring Sprints« diskutieren höre. Dabei handelt es sich um Sprints, deren einziges
Ziel darin besteht, die technischen Schulden zu reduzieren. Für mich klingt das nach
Schlussratenzahlung. Solche Sprints vermitteln den Eindruck, dass die Schulden
ursprünglich angehäuft wurden, ohne dass sich jemand Gedanken um die Rückzahlung
gemacht hat – bis es schließlich so weit gekommen ist, dass das Team im nächsten Sprint
keinen Kundenwert liefern kann, sondern sich stattdessen nun mit diesem Problem befas-
sen muss, dessen es sich eigentlich in jedem Sprint zumindest ein bisschen hätte anneh-
men sollen. Wenn das Schuldenmaß jedoch bereits sehr stark angewachsen ist und die
Rückzahlung tatsächlich noch so gut wie gar nicht in Angriff genommen wurde, ist es
manchmal allerdings unumgänglich, das ganze Team einen vollen Sprint lang an dem
Abbau der technischen Schulden arbeiten zu lassen. In der Regel sollte man solche Sprints
aber nach Möglichkeit vermeiden. Stattdessen sollte die Rückzahlung schrittweise erfolgen.
Bei diesem Ansatz nehmen wir uns eine bestimmte Menge an bekannten technischen
Schulden vor und erklären die Tilgung dieser Schulden zum Ziel unseres nächsten Sprints.
Wie viele Schulden in jedem Sprint abgetragen werden, kann das Sprint-Team während der
Sprint-Planung festlegen.

8.7.4 Bauen Sie die technischen Schulden mit den


höchsten Zinsen zuerst ab
Es mag zwar bequem sein, alle möglichen Arten von Abstrichen und Defiziten am Produkt
unter der Bezeichnung technische Schulden zusammenzufassen, allerdings sollten Sie
sich darüber im Klaren sein, dass nicht alle Arten von technischen Schulden die gleiche
Bedeutung haben. Ein Beispiel für eine wichtige Form dieser Schulden ist ein häufig geän-
dertes Modul, von dem eine Menge anderer Code abhängt und das dringend restrukturiert
werden muss, weil es sich nur noch unter zunehmend größeren Schwierigkeiten anpassen
lässt. Auf solche Schulden zahlen wir ständig Zinsen – und diese Zinsen nehmen kontinu-
ierlich zu, je mehr Änderungen wir vornehmen.
Andererseits könnten sich technische Schulden (bekannte Design- oder Implementie-
rungsprobleme) auch in einem Teil des Produkts ansammeln, der nur selten benutzt und
fast nie geändert wird. Bei dieser Art von Schulden entsteht kein oder lediglich ein gering-
fügiger tagtäglicher Zinszuwachs, weil sie durchaus vernachlässigbar sind, solange kein
übermäßiges Risiko besteht, dass dieser Teil des Produkts ausfällt und der Ausfall dann
schwerwiegende Auswirkungen hat.
Wenn wir technische Schulden tilgen, sollten wir deshalb zuerst die Schulden mit den
höchsten Zinsen auswählen und abbauen. Jeder vernünftige Manager würde mit finanziel-
len Schulden dasselbe machen. So würden wir z.B. mit Sicherheit einen Kredit mit 18%
Zinsen eher zurückzahlen wollen als einen Kredit mit 6% Zinsen – es sei denn, es gibt
einen triftigen Grund, dies nicht zu tun.
Manche Organisationen haben so hohe technische Schulden angehäuft, dass sie nahezu
handlungsunfähig werden, weil sie nicht wissen, wie bzw. wo sie mit dem Abbau anfangen
sollen. Und auch wenn ihnen die hohe Schuldzinslast durchaus klar ist, lassen sie sich
möglicherweise allein von dem schieren Ausmaß abschrecken. Um also überhaupt erst ein-
mal in Gang zu kommen, könnten Sie zunächst eine kleine Schuld begleichen. Auf diese
Weise gewöhnen Sie sich an den Prozess der Rückzahlung. Ich bin immer dafür, alles zu

198
8.7
Technische Schulden abbauen

unternehmen, um Organisationen den nötigen Anstoß zur Abwicklung ihrer Schulden zu


geben. Wie ich als Nächstes beschreiben werde, können wir uns aber natürlich auch wäh-
rend der Verrichtung unserer für den Kunden werthaltigen Arbeit schon auf eine kleine
Schuldenmenge konzentrieren, deren Rückzahlung sich lohnt.

8.7.5 Technische Schulden abbauen, während man für den Kunden


werthaltige Arbeit erledigt
Eine ausgezeichnete Methode zum schrittweisen Zurückzahlen bekannter technischer
Schulden, wobei man sich auf Schulden mit hohen Zinsen konzentriert und deren Abbau
am wertezentrierten Ansatz von Scrum ausrichtet, besteht darin, die Schuldenrückzahlun-
gen während der Wertschöpfung zu erledigen. Vermeiden Sie es also nach Möglichkeit, der
Schuldenreduzierung einen kompletten Sprint zu widmen oder Product-Backlog-Elemente
zu definieren, die allein der Schuldenreduzierung dienen. Stattdessen sollten diejenigen
technischen Schulden getilgt werden, die zur Entwicklung der Funktionen im Product
Backlog passen.
Nehmen wir einmal an, dass wir uns für jedes Product-Backlog-Element mit Kundenwert,
an dem wir arbeiten, noch einige zusätzliche Dinge vornehmen. Erstens verpflichten wir
uns, hochwertige Arbeit abzuliefern, damit wir bei der Erstellung der Kundenfunktion
nicht noch weitere naive technische Schulden hinzufügen. Zweitens wenden wir die Pfad-
finderregel an und beseitigen sämtliche zufälligen Schulden, die wir während unserer
Arbeit an einer Funktion entdecken und in einem vernünftigen Rahmen bewerkstelligen
können. Und drittens (das wesentliche Attribut dieses Ansatzes) zahlen wir speziell solche
technischen Schulden zurück, die sich in dem gegenwärtig bearbeiteten Bereich befinden.
Dieses Vorgehen hat einige Vorteile:
쐽 Es richtet die Schuldenreduzierung an der Wertschöpfungsarbeit aus, deren korrekte
Priorität der Product Owner festlegt.
쐽 Es macht allen Mitgliedern des Entwicklungsteams klar, dass die Reduzierung techni-
scher Schulden eine gemeinsame Verantwortung ist und nicht etwas, das man ver-
schiebt und an jemand anderen oder gar ein anderes Team delegiert.
쐽 Es verstärkt die Fähigkeiten zur Vermeidung und Beseitigung technischer Schulden,
weil sich alle ständig darin üben.
쐽 Es hilft uns, die Bereiche mit hohen Zinsen zu erkennen, auf die wir uns beim Abbau
technischer Schulden konzentrieren sollten. Zumindest wissen wir, dass der Code (oder
ein anderes Entwicklungsartefakt), den wir anfassen, noch wichtig ist, weil wir ihn be-
nutzen, um die neue Funktion zu erstellen.
쐽 Es verhindert, dass wir verschwenderisch sind und technische Schulden in Bereichen
zurückzahlen, in denen das wirklich nicht nötig ist.
Ich erwähnte bereits einen Ansatz, der den Scrum-Teams bei der Ausrichtung von Aktivitä-
ten zur Reduzierung bekannter Schulden an den Product-Backlog-Elementen hilft und den
ich auch selbst schon bei mehreren Teams in der praktischen Anwendung erlebt habe
(siehe Abbildung 8.11).
Bei diesem Vorgehen werden bekannte technische Schulden in ein Technisches-Schulden-
Backlog aufgenommen, das während der Sprint-Planung neben dem Sprint Backlog an der
Wand hängt (oder in einem Tool untergebracht ist, das eine ähnliche Funktion erfüllt).

199
Kapitel 8
Technische Schulden

Wenn Teammitglieder während der Sprint-Planung zusammen mit dem Product Owner
für den Kunden werthaltige Elemente aus dem Product Backlog auswählen, die im nächs-
ten Sprint bearbeitet werden sollen, schauen sie sich auch die Karten im Schulden-Backlog
an. Auf diese Weise stellen sie fest, ob die geplante Arbeit von sich aus in einen Bereich hin-
einspielt, der auf einer der Schuldenkarten steht. Ist das der Fall, nimmt jemand die Karte
von der Schuldentafel und platziert sie als Aufgabe für diesen Sprint im Sprint Backlog.
Und somit kümmern sich die Teammitglieder beim Erledigen der Arbeit für das Product-
Backlog-Element gleichzeitig um die Aufgaben, die mit den technischen Schulden zu tun
haben.

Sprint Backlog Technische Schulden

Abb. 8.11: Eine Technik zur Handhabung der technischen Schulden in Scrum

Das ist eine sehr einfache und elegante Methode, um den Abbau technischer Schulden an
der Erschaffung von Kundenwerten auszurichten.

8.8 Abschließende Bemerkungen


Ich erläuterte in diesem Kapitel das Konzept der technischen Schulden, die sich anhäufen,
wenn wir heute auf Kosten der Arbeit von morgen Abstriche in Kauf nehmen. Dabei unter-
schied ich zwischen naiven, unvermeidbaren und strategischen technischen Schulden.
Danach erklärte ich die Folgen, die ein unzureichender Umgang mit den technischen
Schulden nach sich zieht. Abschließend stellte ich drei Aktivitäten vor, die mit dem Kontrol-
lieren der technischen Schulden verbunden sind: die organisatorische Handhabung der
Zunahme technischer Schulden, das Sichtbarmachen und den Abbau der technischen
Schulden.
Mit diesem Kapitel endet Teil I dieses Buches. Im nächsten Kapitel beginne ich mit der Vor-
stellung der verschiedenen Rollen in einer Scrum-Entwicklung. Dabei werden wir uns als
Erstes mit der Rolle des Product Owners befassen.

200
Teil II
Rollen

In diesem Teil:
쐽 Kapitel 9
Der Product Owner . . . . . . . . . . . . . . . . . . . . . . . . . 203

쐽 Kapitel 10
ScrumMaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

쐽 Kapitel 11
Das Entwicklungsteam . . . . . . . . . . . . . . . . . . . . . . 235

쐽 Kapitel 12
Die Strukturen des Scrum-Teams. . . . . . . . . . . . . . 253

쐽 Kapitel 13
Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

201
Kapitel 9

Der Product Owner

In diesem Kapitel gehe ich genauer auf die Rolle des Product Owners ein und zeige
zunächst auf, in welchem Zusammenhang sie mit den anderen Scrum-Rollen steht.
Danach beschreibe ich die Hauptaufgaben und Eigenschaften des Product Owners und
skizziere seinen »Alltag« über einen Zeitraum von mehreren Wochen hinweg. Außerdem
erläutere ich, wer für die verschiedenen Arten der Produktentwicklung als Product Owner
infrage kommt. Und schließlich beschreibe ich auch, inwiefern sich die Rolle des Product
Owners mit anderen Rollen kombinieren und zu einem Product-Owner-Team erweitern
lässt.

9.1 Überblick
Der Product Owner ist die zentrale Anlaufstelle für alle Belange der Produktentwicklung
und repräsentiert eine der drei gemeinsam agierenden Rollen, aus denen jedes Scrum-
Team besteht (die anderen beiden Rollen werden vom ScrumMaster und dem Entwick-
lungsteam wahrgenommen).
Er muss sich stets in wenigstens zwei Richtungen gleichzeitig orientieren (siehe Abbil-
dung 9.1).

Stakeholder Scrum-Team
Interne Stakeholder

Product Owner ScrumMaster

Kunden/Anwender Entwicklungsteam

Abb. 9.1: Der Product Owner orientiert sich stets in mindestens zwei Richtungen gleichzeitig

203
Kapitel 9
Der Product Owner

Einerseits muss der Product Owner die Bedürfnisse und Prioritäten nicht nur der Stakehol-
der der Organisation, sondern auch der Kunden und der Anwender gut genug verstehen,
um in deren Sinne handeln zu können. In dieser Beziehung fungiert er als Produktmana-
ger, der dafür sorgt, dass die richtige Lösung entwickelt wird.
Und andererseits muss er dem Entwicklungsteam vermitteln, was gebaut werden muss
und in welcher Reihenfolge dies geschehen soll. Außerdem muss der Product Owner
gewährleisten, dass die Akzeptanzkriterien für die Funktionen festgelegt und später auch
die entsprechenden Tests durchgeführt werden, die diese Kriterien verifizieren, damit die
vollständige Fertigstellung der Funktionen sichergestellt ist. Er selbst schreibt zwar keine
detailorientierten Tests, er sorgt aber dafür, dass für das Team anhand der Akzeptanztests,
auch High-Level Tests genannt, erkennbar wird, wann der Product Owner die Funktion als
fertiggestellt akzeptiert. In dieser Hinsicht ist der Product Owner also teils Wirtschaftsana-
lyst, teils Tester.

9.2 Hauptaufgaben
Abbildung 9.2 zeigt die Hauptaufgaben des Product Owners.
Hier ist unschwer zu erkennen, dass es sich bei dieser Rolle um eine Vollzeitbeschäftigung
mit wichtigen Verantwortungsbereichen handelt. Die Lektüre dieses Abschnitts könnte
durchaus Zweifel daran wecken, ob derartig viel Verantwortung tatsächlich nur einer einzi-
gen Person aufgebürdet werden sollte bzw. ob überhaupt jemand alle erforderlichen Eigen-
schaften in sich vereint, die notwendig sind, um dieser Rolle gerecht zu werden. In den
meisten Fällen wird und sollte die Rolle des Product Owners allerdings tatsächlich nur von
einer einzigen Person wahrgenommen werden – wenngleich es unter bestimmten
Umständen sicher auch nicht verkehrt ist, Product-Owner-Teams oder -Stellvertreter einzu-
setzen. Diese beiden Konzepte werde ich später noch genauer erläutern.

Organisieren der wirtschaftlichen Belange

An der Planung teilnehmen

Das Product Backlog pflegen


Aufgaben des
Product Owners
Akzeptanzkriterien definieren und verifizieren, dass sie eingehalten werden

Mit dem Entwicklungsteam zusammenarbeiten

Mit den Stakeholdern zusammenarbeiten

Abb. 9.2: Hauptaufgaben des Product Owners

204
9.2
Hauptaufgaben

9.2.1 Organisation der wirtschaftlichen Belange


Der Product Owner ist dafür verantwortlich, auf Release-, Sprint- und Product-Backlog-
Ebene permanent kluge wirtschaftliche Entscheidungen zu treffen (siehe Abbildung 9.3).

Wirtschaftliche Aspekte auf Sprint-Ebene werden


Steter Fokus auf den
am Anfang jedes Sprints betrachtet
wirtschaftlichen Aspekten
des Product Backlogs

Wirtschaftliche Aspekte auf Release-Ebene werden


am Ende jedes Sprints neu bewertet
Dieses Release
besteht aus vier Sprints

Abb. 9.3: Der Product Owner organisiert die wirtschaftlichen Aspekte

Wirtschaftliche Aspekte auf Release-Ebene


Auf Release-Ebene ist der Product Owner ständig gefordert, Kompromisse in Bezug auf
den Umfang, die Terminplanung, das Budget und die Qualität der Produktentwicklung ein-
zugehen – weil die zum Zeitpunkt der Arbeitsaufnahme getroffenen Entscheidungen
durch die im weiteren Verlauf des Entwicklungsprozesses neu hinzugewonnenen, ökono-
misch relevanten Informationen möglicherweise hinfällig werden bzw. Nachbesserungen
erfordern.
Was wäre z.B., wenn wir mehrere Wochen nach Beginn eines auf die Dauer von sechs
Monaten ausgelegten Entwicklungsprojekts mit einem festen Endtermin plötzlich die
Chance hätten, den Gewinn um 50% zu erhöhen? Dazu müssten wir uns allerdings eine
zusätzliche Woche Zeit nehmen (was einer 4%-igen Verzögerung des Zeitplans entspräche)
und eine neue Funktion in die aktuelle Version implementieren. Sollten wir die genannten
Ressourcen investieren, um einen höheren Gewinn zu erzielen? Diese Entscheidung liegt
beim Product Owner. In der Regel kann er sie allein treffen, in manchen Fällen holt er sich
vorher aber auch die Meinungen der übrigen Beteiligten ein (und sichert sich gegebenen-
falls deren Zustimmung), um die endgültige Entscheidung umzusetzen.
Am Ende jedes Sprints ist der Product Owner außerdem für die Entscheidung zuständig,
ob der nächste Sprint finanziert werden soll oder nicht. Wenn im Hinblick auf das Release-
Ziel gute Fortschritte gemacht wurden oder der nächste Sprint wirtschaftlich gerechtfertigt
ist, werden die finanziellen Mittel bereitgestellt. Wurde hingegen nur wenig erreicht oder
erlauben die ökonomischen Umstände keine weiteren Aufwendungen, dann können die
Arbeiten auch gestoppt werden.
Ein zufriedener Product Owner könnte allerdings ebenso zu der Entscheidung gelangen,
dass die Entwicklungsarbeit am Ende eines Sprints nicht weiter finanziert wird, weil das

205
Kapitel 9
Der Product Owner

Produkt inzwischen auslieferungsreif ist und zusätzliche Ausgaben daher nicht gerechtfer-
tigt sind. Nehmen wir z.B. an, wir hätten ein über die Dauer von zehn Sprints zu entwi-
ckelndes Release geplant. Nach dem siebten Sprint schaut sich der Product Owner die
verbleibenden Product-Backlog-Elemente an und kommt zu dem Schluss, dass die Kosten
für die Herstellung dieser Elemente höher sind als der Wert, den sie erbringen. In diesem
Fall könnte er den Standpunkt vertreten, dass eine frühere Auslieferung des Produkts öko-
nomisch vernünftiger wäre als eine Fortsetzung der Arbeiten bis zum Ende der ursprüng-
lich geplanten zehn Sprints. Diese Flexibilität wird insbesondere auch dadurch unterstützt,
dass sich Elemente mit höherem Wert an der Spitze des Product Backlogs befinden und
somit zuerst bearbeitet werden und das Team bei seiner Arbeit eine starke Definition von
Fertig verfolgt.
Und natürlich könnte der Product Owner auch verfügen, die Finanzierung am Ende eines
Sprints einzustellen, wenn sich wichtige wirtschaftliche Faktoren geändert haben. Stellen
Sie sich z.B. vor, wir würden ein landesspezifisches Produkt herstellen und eine Regulie-
rungsbehörde in diesem Land ändert die Gesetze, so dass es unprofitabel oder vielleicht
sogar illegal wäre, das betreffende Produkt zu verkaufen. Auch in einem solchen Fall
könnte ein Product Owner die Entwicklung abbrechen, obwohl sie ansonsten ganz gut
läuft.

Wirtschaftliche Aspekte auf Sprint-Ebene


Nicht nur auf Release-Ebene, sondern auch in Bezug auf die Sprints ist der Product Owner
für die wirtschaftlichen Aspekte zuständig und muss dafür sorgen, dass jeder einzelne
Sprint eine gute Rendite (Return on Investment; ROI) liefert. Gute Product Owner behan-
deln das Kapital ihrer Organisation wie ihr eigenes. In den meisten Fällen wissen sie über
die Kosten des nächsten Sprints Bescheid (die Dauer und die Teamzusammensetzung des
Sprints sind bekannt) – und vor diesem Hintergrund sollte sich der Product Owner bei der
Sprint-Planung fragen: »Würde ich mir selbst das Geld von meinem eigenen Konto geneh-
migen, um die Funktionen zu bekommen, die wir in diesem Sprint bauen wollen?« Wenn
die Antwort auf diese Frage »Nein« lautet, würde ein guter Product Owner ebenso wenig
das Geld seiner Organisation dafür aufwenden wie sein eigenes.

Wirtschaftliche Aspekte auf Product-Backlog-Ebene


Wie bereits in Kapitel 6 erwähnt, fällt die Priorisierung des Product Backlogs ebenfalls in
den Verantwortungsbereich des Product Owners. Und wenn sich die wirtschaftlichen
Bedingungen ändern, dann ändern sich mit hoher Wahrscheinlichkeit auch die Prioritäten
im Product Backlog.
Nehmen wir z.B. an, dass der Product Owner zu Beginn eines Entwicklungsprojekts der
Meinung ist, eine Funktion wäre für einen hohen Prozentsatz der Zielgruppe von Wert,
und das Team glaubt, es sei nur ein moderater Aufwand für die Erstellung dieser Funktion
nötig. Nach einigen Sprints stellt das Team jedoch fest, dass die Funktion sogar sehr auf-
wendig ist und überdies auch nur für einen Bruchteil der angepeilten Zielgruppe von Wert
sein wird. Da sich das Kosten-Nutzen-Verhältnis der betreffenden Funktion damit drastisch
geändert hat, sollte der Product Owner die Prioritäten im Product Backlog entsprechend
anpassen – indem er beispielsweise die Product-Backlog-Elemente, die mit dieser Funktion
verbunden sind, verwirft.

206
9.2
Hauptaufgaben

9.2.2 Mitwirkung an der Planung


Neben einigen anderen Mitentscheidern ist der Product Owner ebenso maßgeblich an den
Portfolio-, Produkt-, Release- und Sprint-Planungsaktivitäten beteiligt. Während der Portfo-
lio-Planung (siehe Kapitel 16) bestimmt er in Zusammenarbeit mit den internen Stakehol-
dern (möglicherweise einer Genehmigungskommission oder einem Aufsichtsgremium)
die korrekte Positionierung des Produkts im Portfolio-Backlog und legt fest, wann die Pro-
duktentwicklung beginnen und wann sie enden soll. Im Rahmen der anschließenden Pro-
duktplanung (siehe Kapitel 17) arbeitet er, wiederum gemeinsam mit den Stakeholdern, die
Visualisierung des Produkts aus. Für die Release-Planung (siehe Kapitel 18) setzen sich
Product Owner, Stakeholder und Team zusammen, um den Inhalt der nächsten Version zu
definieren. Und bei der Sprint-Planung (siehe Kapitel 19) legt der Product Owner gemein-
sam mit dem Entwicklungsteam die Sprint-Ziele fest. Außerdem liefert er wertvolle Hin-
weise und Informationen, die es dem Entwicklungsteam erlauben, diejenigen Product-
Backlog-Elemente auszuwählen, die es realistischerweise bis zum Ende des Sprints fertig-
stellen kann.

9.2.3 Pflege des Product Backlogs


Des Weiteren ist der Product Owner auch für die Pflege des Product Backlogs zuständig.
Dazu gehören das Anlegen und Verfeinern sowie das Schätzen und Priorisieren der Pro-
duct-Backlog-Elemente (siehe Kapitel 6). Allerdings führt er nicht alle Pflegearbeiten per-
sönlich durch, indem er beispielsweise sämtliche Product-Backlog-Elemente selbst
schreibt, sondern berücksichtigt dabei auch die Beiträge anderer Projektbeteiligter. Ebenso
wenig schätzt er die Elemente selbst (das macht das Entwicklungsteam), er steht aber wäh-
rend der Schätzung für Fragen und weiterführende Erläuterungen zur Verfügung. Letztlich
ist jedoch der Product Owner dafür verantwortlich, dass die Pflegeaktivitäten auf eine
Weise ausgeführt werden, die einen störungsfreien Flow der gelieferten Werte garantiert.

9.2.4 Definition und Verifikation der Akzeptanzkriterien


Auch die Definition der Akzeptanzkriterien für die einzelnen Product-Backlog-Elemente,
die berücksichtigt werden müssen, damit er die funktionalen und nicht funktionalen
Anforderungen als erfüllt werten kann, fällt in den Verantwortungsbereich des Product
Owners. Alternativ könnte er unter Zugrundelegung dieser Kriterien oder mithilfe von
Fachexperten (Subject Matter Experts; SMEs) oder Mitgliedern des Entwicklungsteams
auch gleich entsprechende Akzeptanztests schreiben. In jedem Fall muss der Product
Owner aber dafür sorgen, dass die Akzeptanzkriterien (und oft auch spezielle Akzeptanz-
tests) festgelegt werden, bevor ein Element in einem Sprint-Planungstreffen überhaupt in
Erwägung gezogen wird – denn ohne sie hätte das Team zu wenig Hintergrundinformatio-
nen über das betreffende Element, um es in einen Sprint aufnehmen zu können. Aus die-
sem Grund integrieren viele Scrum-Teams die Definition klarer Akzeptanzkriterien auch in
ihre Bereit-Checkliste (siehe Kapitel 6).
Und schließlich trägt der Product Owner am Ende auch die Verantwortung dafür, sicherzu-
stellen, dass die Akzeptanzkriterien eingehalten werden. Auch hier gilt, dass er die Akzep-
tanztests entweder selbst durchführen oder Experten zu Rate ziehen kann, um
sicherzustellen, dass die Elemente den Anforderungen in vollem Umfang genügen. Ebenso

207
Kapitel 9
Der Product Owner

kann das Team den Product Owner aktiv dabei unterstützen, eine Testinfrastruktur aufzu-
bauen, die es ihm bzw. den Fachexperten erlaubt, diese Tests effizienter durchzuführen –
die abschließende Beurteilung, ob ein Element die Erwartungen erfüllt, obliegt am Ende
aber allein dem Product Owner.
Wichtig dabei ist, dass er die Akzeptanzkriterien bereits während der Sprint-Durchführung
verifiziert und nicht bis zum Sprint Review damit wartet. So hat er die Möglichkeit, Fehler
und Missverständnisse früh genug aufzudecken, damit das Team sie noch rechtzeitig vor
dem Sprint Review ausräumen kann. Die Akzeptanztests sind auch deshalb vor dem
Review nötig, weil das Team im Review ausschließlich abgeschlossene Funktionen
demonstrieren darf – und ohne die Tests wüsste es gar nicht, welche Funktionen tatsäch-
lich der Definition von Fertig entsprechen.

9.2.5 Zusammenarbeit mit dem Entwicklungsteam


Der Product Owner muss oft und eng mit dem Entwicklungsteam zusammenarbeiten und
ist für die tagtäglichen Arbeitsabläufe unabdingbar. Viele Organisationen, die das Scrum-
Entwicklungsverfahren gerade erst eingeführt haben, tun sich allerdings schwer, eine
adäquate Zusammenarbeit zwischen dem Product Owner und dem Entwicklungsteam zu
etablieren – und das führt in der Konsequenz dazu, dass wichtige Feedbacks mit größerer
Verzögerung eintreffen und dann nicht mehr so werthaltig für das Projekt sind.
Das gilt auch, wenn ein frisch ernannter Product Owner davon ausgeht, dass das Ausmaß
seiner Beteiligung an einem Scrum-basierten Entwicklungsprojekt dem einer phasenba-
sierten Entwicklung entspricht. Abbildung 9.4 zeigt eine Gegenüberstellung des traditio-
nellen kunden- bzw. unternehmensseitigen Engagements im Rahmen einer traditionellen,
sequenziellen Entwicklung und dem im Scrum-Entwicklungsverfahren von einem Product
Owner erwarteten Engagement.
Bei einer traditionellen, phasenbasierten Entwicklung verläuft die Kurve des kunden- bzw.
unternehmensseitigen Engagement in einer U-Form: Zu Beginn des Projekts sind die Kun-
den in ganz beträchtlichem Umfang beteiligt, um bei der Definition aller Anforderungen
zu helfen. Sobald dann jedoch die technische Phase beginnt (Design, Kodierung,
bestimmte Tests usw.), werden die Kunden vorerst »nicht mehr gebraucht«, so dass ihre
Beteiligung in dieser Zeit relativ gering bis gar nicht mehr erforderlich ist. Genau genom-
men treten die Kunden bei einer traditionellen Entwicklung erst kurz vor dem Ende des
Entwicklungsprojekts wieder in den Prozess ein, wenn sie Anwenderakzeptanztests durch-
führen müssen. Dies ist der Zeitpunkt, an dem sie üblicherweise feststellen, dass das, was
gebaut wurde, nicht unbedingt ihren Vorstellungen entspricht – und meist ist es dann zu
spät oder zu kostenaufwendig, zumindest in der aktuellen Version noch Änderungen vor-
zunehmen. Diejenigen Kunden, die sich in dieser Hinsicht mehr erhofft hatten, sind dann
natürlich überrascht, frustriert und enttäuscht, was in der Folge häufig unweigerlich in
gegenseitigen Anschuldigungen resultiert. Die Kunden behaupten: »Wenn ihr unsere
Anforderungsdokumente genauer gelesen hättet, dann wäre gleich das dabei herausge-
kommen, was wollten!«, und das Entwicklungsteam kontert: »Wenn eure Dokumentation
unmissverständlicher geschrieben gewesen wäre, dann hätten wir einiges ganz anders
gemacht. Aber so haben wir nur das gebaut, was ihr laut eurer Dokumentation haben woll-
tet!«

208
9.2
Hauptaufgaben

Kunden- bzw. Unternehmensengagement

Scrum
Traditionell

Zeit

Abb. 9.4: Vergleich des Kunden- bzw. Unternehmensengagements im Zeitverlauf

In Scrum kommt statt eines phasenbasierten Ansatzes eine inkrementelle Entwicklungs-


methode zum Einsatz. Das bedeutet, dass alle für die Erstellung einer bestimmten Funk-
tion (Design, Kodierung, Integration, Test) benötigten Aktivitäten in einem einzigen Sprint
durchgeführt werden. Deshalb ist es entscheidend, dass sich der Product Owner immer
gleichbleibend stark engagiert. Bei einer solch engen Interaktion zwischen Product Owner
und Entwicklungsteam in diesen kurzen, zeitlich begrenzten Iterationen ist die Gefahr
relativ gering, dass sie den Kontakt zueinander verlieren. Und wenn Scrum gut funktio-
niert, kommt es auch nicht zu gegenseitigen Anschuldigungen!

9.2.6 Zusammenarbeit mit den Stakeholdern


Der Product Owner ist die Stimme der gesamten Stakeholder-Gemeinschaft – sowohl der
internen als auch der externen. Zu den internen Stakeholdern gehören beispielsweise die
Business Systems Owner, die Betriebsleitung, das Programmmanagement sowie Marke-
ting und Verkauf. Externe Stakeholder sind z.B. Kunden, Anwender, Partner, Regulierungs-
behörden und andere. Der Product Owner muss eng mit der gesamten Stakeholder-
Gemeinschaft zusammenarbeiten, um Informationen und Anregungen zu sammeln und
zu einer einheitlichen Vision zusammenzufügen, die als Grundlage für die Produktent-
wicklung dient.
Wenn sich der Product Owner allerdings überfordert fühlt und sich aufreibt, wird es für
ihn schwierig, seine Zusammenarbeit mit dem Entwicklungsteam und den Stakeholdern
in der gewünschten Intensität aufrechtzuerhalten. Manchmal wird die Belastung für eine
Person einfach zu groß, so dass er die Hilfe anderer in Anspruch nehmen muss, um die
vielfältigen Aufgaben, die mit seiner Rolle einhergehen, bewältigen zu können. Auf das
Konzept eines auf diese Art gebildeten Product-Owner-Teams werde ich später noch aus-
führlicher zurückkommen.

209
Kapitel 9
Der Product Owner

9.3 Eigenschaften/Fähigkeiten
Abbildung 9.5 zeigt wichtige Eigenschaften der Product-Owner-Rolle.
Ein guter Product Owner sollte zahlreiche Eigenschaften mitbringen, die sich in vier Kate-
gorien gliedern lassen: Fachwissen, soziale Kompetenz, Entscheidungsfähigkeit und Ver-
antwortung.

9.3.1 Fachwissen
Der Product Owner ist ein Visionär, der eine greifbare Vorstellung von dem Produkt ver-
mitteln und das Team anleiten kann, diese Vision zu verwirklichen. Eine Vision zu haben,
bedeutet aber nicht, dass jedes Detail oder der genaue Weg für deren Umsetzung absolut
klar sein müssen. Ein guter Product Owner weiß, dass man nicht alles im Voraus erahnen
kann und ist bereit, sich anzupassen, wenn eine Änderung erforderlich ist.

Ist ein Visionär

Fachwissen? Weiß, dass man nicht alles im Voraus erahnen kann

Besitzt Unternehmens- und Fachkenntnisse

Hat eine gute Beziehung zu den Stakeholdern

Kann verhandeln/Konsens erzielen


Leute?
Ist ein guter Kommunikator

Product-Owner- Ist ein starker Motivator


Eigenschaften

Ist berechtigt, Entscheidungen zu treffen

Ist bereit, schwere Entscheidungen zu treffen


Entscheidungen?
Ist entschlussfreudig

Schafft den Ausgleich zwischen unternehmerischen/technischen Problemen

Akzeptiert Verantwortung für das Produkt

Verantwortung? Ist engagiert und verfügbar

Handelt wie ein Mitglied des Scrum-Teams

Abb. 9.5: Eigenschaften des Product Owners

Um eine Vision auf möglichst effiziente Weise vermitteln und verwirklichen zu können,
benötigt der Product Owner entsprechendes fachliches Hintergrundwissen. Wer in dem
jeweiligen geschäftlichen Fachbereich neu ist, wird es schwer haben, als Product Owner
effizient zu arbeiten – denn wie soll man die Prioritäten der miteinander konkurrierenden
Funktionen richtig festlegen können, wenn man sich nicht mit dem Thema auskennt?

210
9.3
Eigenschaften/Fähigkeiten

9.3.2 Soziale Kompetenz


Ein Product Owner muss auch die »Stimme des Kunden« sein. Dazu ist eine gute Bezie-
hung zu den Stakeholdern erforderlich. Und weil oft mehrere Stakeholder involviert sind,
die gegensätzliche Bedürfnisse haben könnten, muss er darüber hinaus gut verhandeln
und die Konsensbildung unterstützen können.
Der Product Owner bildet den Dreh- und Angelpunkt zwischen der Stakeholder-Gemein-
schaft und dem restlichen Scrum-Team. In dieser Position braucht er gute Kommunika-
tionsfähigkeiten, um mit beiden Seiten zusammenarbeiten und ihnen die relevanten
Informationen in angemessener, verständlicher Form vermitteln zu können. Ein guter
Kommunikator besitzt außerdem folgende Qualitäten: Er ist auch dann bereit, seine Mei-
nung zu äußern, wenn sie dem Status Quo entgegensteht, er ist von seinen Ideen über-
zeugt, kennt sich in der Sache aus, ist in der Lage, in präziser und leicht verständlicher
Weise zu kommunizieren, und er ist glaubwürdig.
Außerdem sollte ein Product Owner ein starker Motivator sein. Wenn die Lage ernst wird,
kann er die Leute daran erinnern, warum sie sich überhaupt die Mühe machen und ihnen
helfen, ihren Enthusiasmus zu bewahren, indem er das geschäftliche Vorhaben bekräftigt.

9.3.3 Entscheidungsfindung
Der Product Owner muss mit diversen Entscheidungsvollmachten ausgestattet sein. In
Organisationen, die das Scrum-Entwicklungsverfahren gerade erst eingeführt haben, ist
die Person, die als Product Owner ausgewählt wurde, oftmals nicht befugt, wichtige Ent-
scheidungen zu treffen – doch das stellt ein großes Hindernis dar, denn: Eine solche Per-
son ist kein Product Owner.
Darüber hinaus muss der Product Owner natürlich auch bereit sein, gegebenenfalls
schwere Entscheidungen zu fällen, die üblicherweise mit Abstrichen in Bezug auf den
Umfang, die Terminplanung und das Budget des Projekts in Zusammenhang stehen – und
zeitnah erfolgen müssen sowie nicht ohne triftigen Grund widerrufen werden dürfen. Mit
anderen Worten: Der Product Owner muss ein entschlussfreudiger Macher sein.
Wenn er diese Entscheidungen fällt, muss ein Product Owner die richtige Balance zwi-
schen geschäftlichen Bedürfnissen und technischen Realitäten wahren. Zwar ist das
Scrum-Team als Ganzes verantwortlich, wenn Systeme unakzeptable Mengen an techni-
schen Schulden anhäufen, allerdings sind häufig naive Entscheidungen des Product
Owners und Entscheidungen, die Auswirkungen auf Systemebene nicht in Betracht zie-
hen, die größten zum Scheitern beitragenden Faktoren.

9.3.4 Verantwortung
In der Hauptsache zeichnet zwar der Product Owner für die Lieferung guter Unterneh-
mensergebnisse verantwortlich, das entbindet die anderen Mitglieder des Scrum-Teams
jedoch nicht von ihrer Verantwortung, ebenfalls ihren Teil zu der Generierung einer guten
Rendite beizutragen. Faktisch ist allerdings der Product Owner derjenige, der dafür sorgen
muss, dass die verfügbaren Ressourcen auf wirtschaftlich vernünftige Weise eingesetzt
werden, und der die Verantwortung trägt, wenn das nicht geschieht – immerhin hat er im

211
Kapitel 9
Der Product Owner

Laufe des gesamten Entwicklungsprozesses zahlreiche Gelegenheiten, das Product Backlog


zu ändern, Prioritäten neu zu vergeben oder die Arbeiten gar komplett einzustellen.
Der Product Owner muss engagiert sein und sowohl den Stakeholdern als auch dem Rest
des Scrum-Teams nach Möglichkeit jederzeit zur Verfügung stehen. Product Owner zu
sein, ist eine Vollzeitbeschäftigung: Wer in einer solchen Position versucht, die anfallenden
Aufgaben lediglich in Teilzeit zu erfüllen, ist auf dem besten Weg zum Misserfolg.
Und schließlich ist der Product Owner natürlich auch selbst ein Mitglied des Scrum-Teams
und weiß deshalb, dass gute wirtschaftliche Ergebnisse ohne die gemeinsamen Anstren-
gungen des gesamten Scrum-Teams unmöglich sind. Deshalb behandelt er das Entwick-
lungsteam und den ScrumMaster mit Respekt und baut darauf, dass alle zusammen die
gewünschten Ergebnisse abliefern. Sämtliche Mitglieder des Scrum-Teams sollten sich die
Devise der Musketiere zu eigen machen (dieses Konzept beschreibe ich in Kapitel 11
genauer). Für eine »Wir-gegen-sie«-Einstellung ist kein Platz: Product Owner, ScrumMas-
ter und Entwicklungsteam bilden eine Einheit, die zusammen auf dasselbe Ziel hinarbeitet.

9.4 Der Alltag eines Product Owners


Um das Ausmaß seiner Verantwortung besser würdigen zu können, schauen wir uns im
Folgenden einmal den »Alltag« eines Product Owners im Laufe einer Produktentwicklung
etwas genauer an (siehe Abbildung 9.6).
In den Wochen 1 und 2 ist der Product Owner sowohl an der Portfolio-Planung (siehe Kapi-
tel 16) als auch an der Produktplanung (siehe Kapitel 17) beteiligt. Im Zuge der Portfolio-
Planung arbeitet der Product Owner mit dem Portfolio-Manager oder dem Aufsichtsgre-
mium zusammen und diskutiert die an das Portfolio gestellten Erwartungen und Anforde-
rungen, die die Planung des neuen Produkts beeinflussen könnten. Diese Diskussionen
liefern die Vorgaben für die Produktplanung, bei der der Product Owner gemeinsam mit
den entsprechenden Stakeholdern und anderen eine aussagekräftige Vision des neuen Pro-
dukts ausarbeitet.
Nach Abschluss der Produktplanung wird das vorgeschlagene Produkt an die Portfolio-Pla-
nung übergeben, wo es durch den ökonomischen Filter der Organisation geschickt wird,
um festzustellen, ob die Entwicklung finanziert werden und wann die Arbeit beginnen
kann. Abbildung 9.6 zeigt, dass all dies unmittelbar nach Abschluss der Produktplanung
geschieht. In vielen Organisationen liegt jedoch vermutlich ein zeitlicher Abstand zwischen
dem Ende der Visionsentwicklung und dem Treffen der Genehmigungskommission oder
dem Aufsichtsgremium sowie dem eigentlichen Arbeitsbeginn.
In Woche 3 ist der Product Owner mit der ersten Release-Planung befasst (siehe Kapitel 18).
Dies bedeutet typischerweise einen Workshop zum Schreiben der Product-Backlog-Ele-
mente (PBIs) bzw. der Stories (siehe Kapitel 5), an dem die internen Stakeholder, die Mit-
glieder des Entwicklungsteams und möglicherweise auch externe Stakeholder teilnehmen,
um ein hochwertiges Product Backlog zu erstellen, das während der Release-Planung
benutzt werden kann. Die Mitglieder des Entwicklungsteams sollten zu diesem Zeitpunkt
bereits feststehen und verfügbar sein, weil die Finanzierung ja bereits genehmigt wurde.
Falls das Entwicklungsteam noch nicht aufgestellt wurde, kann notfalls ein Ersatzteam ein-
gesetzt werden.

212
9.4
Der Alltag eines Product Owners

Pflege überwachen Teilnehmen Fragen beantworten Möglichst teilnehmen

Daily Scrum
Sprint-Planung
Sprint Backlog
Product Backlog Sprint-Ausführung

Funktionen prüfen

Pflege
Potenziell
auslieferungsfähiges
Produkt-
inkrement
Stakeholder-Meetings

Sprint Review
Sprint-Retrospektive

Teilnehmen

Portfolio- Finanzierung Schätz-


Diskussionen genehmigt Workshop

Woche 1 Woche 2 Woche 3 Woche 4 Woche 5

Visionsbildung PBI-Schreib- Ersten Release-


Workshop Plan schaffen

Portfolio-Planung Release-Planung Sprint 1


Produktplanung

Abb. 9.6: Alltag des Product Owners

Nach dem Workshop zum Schreiben der Product-Backlog-Elemente nimmt der Product
Owner an einem Schätz-Workshop teil (vermutlich eher eine Folge von Meetings über ein
oder zwei Tage), in dem die Mitglieder des Entwicklungsteams (oder, wenn das Team noch
nicht endgültig feststeht, eines Ersatzteams) die Größe der höherwertigen Product-Back-
log-Elemente schätzen.
Anschließend führt der Product Owner eine erste Sitzung zur Release-Planung durch (län-
gerfristige Planung). Da inzwischen bereits einige der Product-Backlog-Elemente geschätzt
wurden, konzentriert man sich bei der Release-Planung darauf, die Prioritäten im Product
Backlog zu bestimmen und die aus dem Umfang, Zeitplan und Budget resultierenden Ein-
schränkungen auszugleichen (siehe Kapitel 18). In diesem Fall sind die Stakeholder die
wichtigsten Teilnehmer, jedoch müssen an irgendeiner Stelle auch einige oder alle Mitglie-
der des Entwicklungsteams einbezogen werden, um technische Abhängigkeiten zu identi-
fizieren, die die Anordnung der Elemente im Product Backlog beeinflussen könnten.

213
Kapitel 9
Der Product Owner

Das Ziel besteht darin, das Release so weit zu planen, dass ein akzeptables Maß an Klarheit
über die komplette Version herrscht und erste Antworten auf geschäftliche Fragen gegeben
werden können, wie etwa was und wann geliefert werden kann. Bei den meisten Produkten
sollte diese Aktivität nicht mehr als einen oder zwei Tage dauern. Wie ich in Kapitel 18 aus-
führen werde, ist die Release-Planung ein fortlaufender Prozess, so dass wir an dieser Stelle
nicht versuchen sollten, übermäßig präzise zu sein – schließlich werden wir den Release-
Plan immer wieder überarbeiten, sobald weiterführende relevante Informationen verfüg-
bar werden.
Nach der Release-Planung führt das Scrum-Team den ersten Sprint durch (Abbildung 9.6
zeigt einen zweiwöchigen Sprint in den Wochen 4 und 5). Zu Beginn des Sprints über-
wacht der Product Owner die Sprint-Planung (siehe Kapitel 19) und im weiteren Verlauf
der Sprint-Durchführung (siehe Kapitel 20) versucht er in der Regel auch, an den Daily
Scrums des Teams teilzunehmen. Das mag nicht immer möglich sein, ist aber eine
bewährte Praxis. Beim Daily Scrum hört der Product Owner zu und versucht einen Ein-
druck davon zu gewinnen, wie der aktuelle Sprint vorangeht und wie er dem Entwicklungs-
team helfen kann. Vielleicht merkt ein Teammitglied an, dass ihm die Spezifika eines der
Product-Backlog-Elemente nicht ganz klar sind und er daher weitere Informationen
braucht, um seine aktuelle Aufgabe abschließen zu können. Eine schnelle Erklärung
könnte der Product Owner bereits während des Daily Scrums liefern. Fällt die Antwort hin-
gegen umfangreicher und somit langwieriger aus, dann sollte er anbieten: »Ich bleibe nach
dem Daily Scrum gern hier und diskutiere das Problem mit dir.«
Generell muss der Product Owner möglichst jeden Tag zur Verfügung stehen, um Fragen
zu beantworten und Funktionen zu testen, sobald diese kontrollbereit sind. Sollte von vorn-
herein klar sein, dass er diese Aufgaben nicht täglich wahrnehmen kann, dann muss er sie
an einen geeigneten Stellvertreter delegieren, damit das Entwicklungsteam nicht blockiert
wird. Auf dieses Konzept werde ich weiter hinten in diesem Kapitel noch eingehen.
Während der Sprint-Durchführung trifft sich der Product Owner darüber hinaus auch mit
den internen und externen Stakeholdern, um sicherzustellen, dass die Prioritäten für den
kommenden Sprint stimmen und Informationen einzuholen, die die für künftige Sprints
ausgewählten Funktionen beeinflussen.
Er pflegt außerdem regelmäßig das Product Backlog, d.h., er schreibt neue Product-Back-
log-Elemente, verfeinert vorhandene Elemente, lässt sie vom Team schätzen und sowohl
vom Team als auch von den Stakeholdern priorisieren.
Am Ende des Sprints nimmt der Product Owner an den zwei Aktivitäten zum Untersuchen
und Anpassen teil: dem Sprint Review (siehe Kapitel 21) und der Sprint-Retrospektive
(siehe Kapitel 22). Sind diese abgeschlossen, wiederholt sich der Sprint-Zyklus und der Pro-
duct Owner nimmt an der nächsten Sprint-Planung teil.

9.5 Wer sollte Product Owner sein?


In den meisten Nicht-Scrum-Organisationen ist vermutlich keine Rolle mit der Bezeich-
nung »Product Owner« vorgesehen. Wer also sollte diese Rolle ausfüllen?
Wie ich bereits früher in diesem Kapitel erwähnt habe, muss sich der Product Owner stets
in zwei Richtungen gleichzeitig orientieren: einerseits an den internen und externen Stake-

214
9.5
Wer sollte Product Owner sein?

holdern und andererseits am Entwicklungsteam. Die Rolle des Product Owners repräsen-
tiert somit eine Verschmelzung der Art von Autorität und Verantwortung, wie sie auch mit
verschiedenen traditionellen Rollen einhergeht. In seiner umfassendsten Ausprägung
vereint ein Product Owner Elemente aus den Rollen des Produktmanagers, Produktver-
markters, Projektmanagers (siehe dazu auch Kapitel 13), Wirtschaftsanalysten und Akzep-
tanztesters.
Wer nun genau als Product Owner auftreten soll, hängt von der Art des Entwicklungspro-
jekts und der speziellen Organisation ab. Tabelle 9.1 beschreibt gute Kandidaten für ver-
schiedene Entwicklungsarten.

9.5.1 Interne Entwicklung


Bei einer internen Entwicklung sollte ein Bevollmächtigter aus der Gruppe, die von der Ent-
wicklung profitiert, zum Product Owner ernannt werden. Falls z.B. eine interne IT-Gruppe
ein System für die Marketinggruppe entwickelt, dann sollte jemand aus dem Marketing-
team als Product Owner auftreten (siehe Abbildung 9.7).

Art der Entwicklung Product-Owner-Kandidat


Interne Entwicklung Vertreter/Kunde aus dem Geschäftsbereich, der von der
Lösung profitiert
Gewerbliche Entwicklung Interner Stellvertreter für die eigentlichen Kunden und
Anwender (meist ein Produktmanager, Produktvermarkter
oder Projektmanager)
Ausgelagerte Entwicklung Vertreter/Kunde aus dem Unternehmen, das für die Lösung
bezahlt und den Nutzen daraus zieht
Komponententeam (architek- Meist ein Techniker, der das Backlog aus technischen Ele-
tonische Entwicklung) menten am besten priorisieren kann
Tabelle 9.1: Product Owner für verschiedene Arten der Produktentwicklung

Marketingabteilung IT-Abteilung

Marketing-
system

Abb. 9.7: Beispiel für einen Product Owner in einer internen Entwicklung

215
Kapitel 9
Der Product Owner

Manche Organisationen (üblicherweise solche, die bisher noch nicht realisiert haben, wie
wichtig es ist, einen Geschäftsmann bzw. kaufmännischen Mitarbeiter als täglich beteilig-
ten Product Owner einzusetzen) bitten möglicherweise einen IT-Mitarbeiter, die täglichen
Aufgaben des Product Owners zu übernehmen. Auf die Probleme, die dieser Ansatz mit
sich bringt, werde ich an anderer Stelle in diesem Kapitel noch zu sprechen kommen.

9.5.2 Gewerbliche Entwicklung


Bei einer gewerblichen Entwicklung – wie etwa einem Produkt, das ein Unternehmen an
externe Kunden verkaufen möchte – sollte der Product Owner ein Angestellter des Unter-
nehmens sein, der für die Endkunden spricht. Oft kommt diese Person aus den Reihen des
Produktmanagements oder des Produktmarketings (siehe Abbildung 9.8).

Externe Kunden Produktmanagement Entwicklungsabteilung


Produktmarketing
Projektmanagement

Kundenprodukt
Abb. 9.8: Beispiel für einen Product Owner in einer gewerblichen Entwicklung

Scrum-Anwender liefern sich eine erbitterte Debatte hinsichtlich der Frage, ob die Rolle des
Product Owners lediglich die Scrum- (und agile) Umbenennung der Produktmanager-Rolle
darstellt oder nicht. Manche glauben, die beiden Rollen seien synonym, andere behaupten,
dass die Product-Owner-Rolle umfangreicher sei als die Produktmanager-Rolle. Und wie-
der andere argumentieren natürlich, dass die Rolle des Produktmanagers größer sei. Also
ich sehe das so:
Die Bereiche des Produktmanagements und des Produktmarketings sind sehr umfassend.
Pragmatic Marketing, Inc., ein renommiertes Unternehmen auf dem Gebiet des Produkt-
managements/-marketings hat ein viel beachtetes Framework geschaffen, das die Rollen
und Verantwortlichkeiten für Produktmanagement- und Produktmarketing-Teams aus
dem Technologiesektor definiert (siehe Abbildung 9.9).
Um all diese Aktivitäten abzudecken, empfiehlt Pragmatic Marketing die Einrichtung meh-
rerer Rollen, unter anderem in Form von Produktstrategen, technischen Produktmanagern
und Marketing-Produktmanagern. Und die meisten Leute würden sicher zustimmen, dass

216
9.5
Wer sollte Product Owner sein?

ein gewerbliches Unternehmen, das diese ganzen Aktivitäten für ein größeres Produkt
durchführen lassen möchte, wahrscheinlich ein ganzes Team benötigt.
Soll der Product Owner diese ganzen Arbeiten durchführen? Diejenigen, die glauben, die
Product-Owner-Rolle sei lediglich ein Teil der traditionellen Produktmanager-Rolle, werden
anführen, dass ein Product Owner einfach nur der »technische Produktmanager« ist und
beschränken sich deshalb hauptsächlich auf die wenigen Aktivitäten innerhalb der gestri-
chelten Linie in Abbildung 9.9. Sie glauben, dass der Product Owner keine Zeit hat, sich
auf die anderen Aktivitäten zu konzentrieren, weil er jeden Tag für das Team zur Verfügung
stehen muss.

Busines s
Positioning
Marketing Pragmatic
Plan Plan
Marketing
Market Market
Pricing
Buying Customer Framework ™

Problems Definition Process Acquisition

A Market-Driven Model for


Win/Loss Distribution Buy, Build Buyer Customer Managing and Marketing
Analysis Strategy or Partner Personas Retention
Technology Products

Distinctive Product Product User Program


Competence Portfolio Profitability Personas Effectiveness

TACTICAL
STRATEGIC

MARKET STRATEGY BUSINESS PLANNING PROGRAMS READINESS SUPPORT

Competitive Product Launch Sales Presentations


Innovation Requirements
Landscape Roadmap Plan Process & Demos

Technology Use Thought “Special“


Collateral
Assessment Scenarios Leadership Calls

Status Lead Sales Event


Dashboard Generation Tools Support

Referrals & Channel Channel


(480) 515-1411 PragmaticMarketing.com
References Training Support
© 1993 – 2012 Pragmatic Marketing, Inc.

Abb. 9.9: Pragmatic-Marketing-Framework

Sicherlich ist der Product Owner dafür verantwortlich, die Arbeiten zu erledigen, die in der
gestrichelten Linie gezeigt werden. Allerdings vertrete ich den Standpunkt, dass er noch
mehr machen muss. Um genau zu sein, glaube ich, dass der Product Owner für die Durch-
führung so vieler Aktivitäten in Abbildung 9.9 verantwortlich sein sollte, wie notwendig
und praktisch für ihn sind. Das Ausmaß dieser Verantwortung würde natürlich von der
Organisation, dem speziellen Produkt und den Fertigkeiten der Person abhängen, die zum
Product Owner ernannt wurde. So würde eine Organisation, die einen einfachen Einheiten-
rechner zum Verkauf in einem App Store für Mobilgeräte herstellt, weniger Aktivitäten ver-
langen als eine Organisation, die die nächste Version ihrer Unternehmenssoftware
vorbereitet – und deshalb ist es nicht besonders praktisch, den Umfang des Verantwor-

217
Kapitel 9
Der Product Owner

tungsbereichs des Product Owners anhand des Pragmatic-Marketing-Frameworks zu defi-


nieren.
Wie ich gleich noch ausführen werde, kann es gelegentlich vorkommen, dass der Umfang
der Aktivitäten eines Product Owners für eine einzelne Person nicht zu bewältigen ist. In
diesen Fällen könnten wir ein Product-Owner-Team einsetzen, dessen Angehörige sich auf
das strategische Vorgehen und das Marketing konzentrieren. Dennoch wird es immer eine
einzige Person sein, die letztlich allein die Rolle des Product Owners für das Scrum-Team
einnimmt.

9.5.3 Ausgelagerte Entwicklung


Bei einer ausgelagerten Entwicklung – wenn z.B. Unternehmen A mit Unternehmen B
vertraglich vereinbart, dass dieses eine Lösung baut – sollte ein Vertreter von Unternehmen
A der Product Owner sein. Unternehmen B könnte einen eigenen Mitarbeiter anweisen,
eng mit dem Product Owner zusammenzuarbeiten, der Product Owner selbst sollte jedoch
von dem Unternehmen kommen, das für die Lösung bezahlt und den Nutzen daraus zieht
(siehe Abbildung 9.10).

Unternehmen A (Kunde) Unternehmen B (Vertragspartner)

(Gut)

(Schlecht)

Abb. 9.10: Beispiel für einen Product Owner in einer ausgelagerten Entwicklung

Kompliziert wird die Rolle des Product Owners, wenn Unternehmen A und Unternehmen
B einen traditionellen Entwicklungsvertrag mit festem Preis abschließen. In diesem Fall
wird Unternehmen B aller Wahrscheinlichkeit nach der Meinung sein haben, dass es den
überwiegenden Teil der ProductOwner-Verantwortung übernehmen sollte, weil es das
Risiko eines Festpreisvertrags schultert. In Wirklichkeit sollte jedoch Unternehmen A als
der eigentliche Kunde die Rolle des Product Owners füllen. Ein passenderer Vertrag würde
vorsehen, dass Unternehmen A das leistungsstarke Entwicklungsteam und den Scrum-
Master von Unternehmen B »mietet« und Unternehmen A den Product Owner stellt.

218
9.5
Wer sollte Product Owner sein?

9.5.4 Komponentenentwicklung
Und schließlich könnten Unternehmen auch Komponententeams einsetzen (siehe Kapitel
12), die Teile der Kundenlösungen erstellen, aber nicht die komplette Kundenlösung. Sol-
che Teams stellen üblicherweise Komponenten oder andere Bestandteile her, die dann von
anderen Teams benutzt werden, um die für den Kunden vorgesehenen Lösungen zusam-
menzubauen. Da sie sich auf die technische Komponentenebene konzentrieren, handelt es
sich bei deren Product Ownern in der Regel um technisch orientierte Personen, die in der
Lage sind, die technischen Funktionen in ihren Backlogs zu definieren und zu priorisieren
(siehe Abbildung 9.11).

Funktionsteams Komponententeam
Unternehmens-
orientiert

Technisch
orientiert

Abb. 9.11: Beispiel für einen Product Owner bei einer Komponentenentwicklung

In der Abbildung sind drei Teams für unternehmensorientierte Funktionen aufgeführt.


Diese stellen Funktionen her, die für den Endanwender interessant sind. Jedes Funktions-
team besitzt seinen eigenen Product Owner, der sich auf die Funktionen dieses Teams kon-
zentriert – und darüber hinaus macht sich jedes Team die Arbeit eines Komponententeams
zunutze, das Teile liefert, die zum Abschließen ihrer Funktionen notwendig sind. Das
Komponententeam braucht einen Product Owner, der die Entwicklung der verschiedenen
Anforderungen auf Komponentenebene, die von den Funktionsteams bereitgestellt wer-
den, überwachen und priorisieren kann. Der Product Owner des Komponententeams hat
vermutlich mehr technisches Know-how als die Product Owner der Funktionsteams.

219
Kapitel 9
Der Product Owner

9.6 Product Owner kombiniert mit anderen Rollen


Sofern es ihre Kapazitäten zulassen, kann eine Person auch als Product Owner für mehr als
ein Scrum-Team tätig sein (siehe Abbildung 9.12).

Dieselbe Person
ScrumMaster als Product Owner ScrumMaster

Entwicklungsteam Entwicklungsteam

Abb. 9.12: Ein und dieselbe Person als Product Owner in mehr als einem Scrum-Team

In der Regel ist es sogar einfacher, als Product Owner für mehrere Teams in derselben Ent-
wicklung zu fungieren, da die Arbeit dieser Teams mit hoher Wahrscheinlichkeit eng mit-
einander verknüpft ist.
Außerdem kann es auch vorkommen, dass ein und dieselbe Person sowohl Product Owner
als auch Mitglied des Entwicklungsteams ist. Grundsätzlich ist das jedoch keine so gute
Idee, denn in diesem Fall wäre die betreffende Person sowohl Product Owner als auch
ScrumMaster im selben Scrum-Team. Diese beiden Rollen bilden jedoch Gegengewichte
zueinander – und wenn eine einzige Person beide Rollen wahrnimmt, könnte dies zu
einem Interessenkonflikt führen, den wir möglichst vermeiden sollten.

9.7 Das Product-Owner-Team


Jedes Scrum-Team braucht eine Person, die zweifelsfrei als Product Owner ausgewiesen
und als einzige bevollmächtigt ist, die Aufgaben des Product Owners für dieses Scrum-
Team zu erfüllen sowie die Verantwortung dafür zu tragen.
Aber sollten wir möglicherweise auch einem ganzen Team gestatten, die Rolle des Product
Owners zu übernehmen? Wenn damit gemeint ist, das die Mitglieder dieses Teams
gemeinsam Entscheidungen treffen und gemeinsam haftbar sind, dann definitiv nicht –
denn um Scrum richtig anwenden zu können, darf nur eine Person der Product Owner
sein, Entscheidungen treffen und gegenüber dem Scrum-Team als Stimme der Stakehol-
der-Gemeinschaft auftreten.
Dennoch setzen manche Organisationen ein sogenanntes »Product-Owner-Team« ein, weil
ihnen bewusst ist, dass der Product Owner in ihrem Fall auf die Hilfe ausgewählter Mitar-
beiter angewiesen ist, die ihm Informationen und Hinweise zutragen. In anderen Unter-

220
9.7
Das Product-Owner-Team

nehmen könnte dagegen die Arbeitsbelastung für den Product Owner schlicht das Maß
dessen übersteigen, was eine in Vollzeit beschäftigte Person realistischerweise schaffen
kann. In diesen Fällen delegiert der Product Owner einen Teil seiner Aufgaben an andere.
Unter den genannten Umständen ist die Einrichtung eines Product-Owner-Teams durch-
aus akzeptabel, solange es eine Person in dem Team gibt, die am Ende die Entscheidungen
trifft, so dass die ganze Angelegenheit nicht in eine Art »Komitee-Verhalten« abrutschen
kann und jede Entscheidung womöglich erst von acht anderen Leuten abgenickt werden
muss.
Seien Sie vorsichtig, wenn Sie Product-Owner-Teams bilden. Product Owner, die nicht die
nötigen Fertigkeiten besitzen, um als mächtige zentrale Anlaufstelle der Produktentwick-
lung aufzutreten, brauchen kein Komitee – sie brauchen eine andere Rolle. Und auch Pro-
duct Owner, die zu beschäftigt sind, um ihre Aufgaben zu erfüllen, brauchen nicht
unbedingt ein Team – vielleicht liegt das wirkliche Problem darin, dass die Organisation zu
viele Entwicklungen auf einmal begonnen hat oder es nicht genügend Product Owner gibt,
um die notwendigen Produkte zu betreuen.
Vielleicht ist auch das Produkt, das wir bauen wollen, einfach zu groß und sollte in eine
Reihe kleinerer Teile mit häufigeren Releases zerlegt werden. Bei kleineren Teilen könnte
eine Person die Rolle des Product Owners viel einfacher ausfüllen. Aber auch wenn wir
unsere Teams schlecht strukturiert haben (siehe Kapitel 12) oder die Strukturen des Pro-
duct Backlogs nicht stimmen (siehe Kapitel 6), könnte die Arbeit für einen einzigen Pro-
duct Owner zu schwierig sein. Vergewissern Sie sich, dass Ihre Product-Owner-Teams
tatsächlich notwendig sind und nicht nur ein darunter verborgenes Problem verdecken –
ansonsten wird Ihre Situation nur noch komplizierter und Sie gefährden Ihr Gesamt-
ergebnis.

9.7.1 Product-Owner-Stellvertreter
Wie ich bereits erwähnte, bitten manche Unternehmen, die interne Entwicklungen vorneh-
men, einen IT-Mitarbeiter (z.B. einen Wirtschaftsanalysten oder einen Entwicklungsmana-
ger), als Product Owner zu agieren, weil der Kandidat aus dem kaufmännischen Bereich zu
sehr mit anderen Arbeiten ausgelastet ist. Da jeder weiß, dass der IT-Mitarbeiter eigentlich
nicht berechtigt ist, die wichtigen endgültigen Entscheidungen zu treffen (eine der wesent-
lichen Aufgaben jedes Product Owners), haben Organisationen, die dies tun, die Rolle des
Product Owners damit ineffektiv und verwirrend ausgefüllt. Besser wäre es, den Zeitplan
des geschäftlichen Mitarbeiters so weit freizuräumen, dass er als Product Owner handeln
kann, als den IT-Mitarbeiter bei bestimmten Interaktionen mit dem Team stellvertretend
vorzuschicken.
Ein Product-Owner-Stellvertreter ist eine Person, die vom Product Owner gebeten wird, in
bestimmten Situationen in seinem Namen zu handeln. Jeder im Scrum-Team weiß, dass
der Stellvertreter nicht der tatsächliche Product Owner ist, aber auch, dass der Product
Owner diese Person bevollmächtigt hat, zumindest einige taktische Entscheidungen in sei-
nem Namen zu treffen. Das kommt z.B. oft vor, wenn der Product Owner viel Zeit in Mee-
tings mit Kunden und Anwendern verbringt, um sicherzugehen, dass er seinen Finger am
Puls des Marktes behält. Diese Person steht dem Entwicklungsteam auf keinen Fall täglich
zur Verfügung. Hier könnte der Product Owner auf einen Stellvertreter zurückgreifen, der

221
Kapitel 9
Der Product Owner

die tägliche Interaktion mit dem Entwicklungsteam hinsichtlich der Product-Backlog-Ele-


mente erledigt.
Damit dieser Ansatz funktioniert, muss der Product Owner den Stellvertreter tatsächlich
ermächtigen, Entscheidungen zu treffen und darf diese Entscheidungen dann auch nicht
grundlos wieder außer Kraft setzen, denn damit würde er die Glaubwürdigkeit des Stellver-
treters beim Team untergraben. Denken Sie also daran: Der Product Owner kann zwar
anderen die Befugnis erteilen, ihm zu helfen, die endgültige Verantwortung für die Durch-
führung der Arbeit hingegen kann er nicht delegieren – er ist weiterhin dafür zuständig.

9.7.2 Chief Product Owner


Auch bei sehr großen Produkten wird oft ein Product-Owner-Team gebildet. Ich habe
bereits angemerkt, dass eine einzelne Person Product Owner für mehrere Scrum-Teams
sein kann. Was aber ist mit einem Szenario, das viele Teams umfasst? Ich habe z.B. einmal
eine Organisation beraten, in der bis zu 2.500 Leute an einem einzigen Entwicklungspro-
jekt beteiligt waren. Bei einer durchschnittlichen Teamgröße von weniger als 10 Personen
gab es in diesem Unternehmen also mehr als 250 Teams für die Entwicklungsarbeit. Eine
Person kann schwerlich Product Owner für 250 Teams sein. Realistisch gesehen, kann eine
einzelne Person nur für wenige Teams täglich da sein. In solchen Fällen muss die Rolle des
Product Owners hierarchisch aufgebaut sein, wie in Abbildung 9.13 dargestellt.

Chef-
Product Owner

Produktlinie-
Owner

Funktions-
Product Owner

Abb. 9.13: Hierarchische Product-Owner-Rolle

In Abbildung 9.13 ist am Ende die Person mit der Bezeichnung Chief Product Owner der
eigentliche Product Owner für das gesamte Produkt. Der »Chef« steht allerdings einem
ganzen Team aus Product Ownern vor, die gewährleisten, dass die Rolle des Product
Owners in allen tieferen Ebenen der Hierarchie korrekt wahrgenommen wird. Falls Sie sich
für diesen Ansatz entscheiden, müssen Sie dafür sorgen, dass die einzelnen Product
Owner die Befugnis erhalten, die Mehrzahl der Entscheidungen auf ihrer Ebene der Hie-
rarchie zu treffen, anstatt solche Entscheidungen nach oben durchreichen zu müssen.

222
9.8
Abschließende Bemerkungen

9.8 Abschließende Bemerkungen


In diesem Kapitel bin ich ausführlich auf die Rolle des Product Owners eingegangen. Ich
erläuterte, dass diese Rolle den zentralen Dreh- und Angelpunkt der Produktführung bildet
und beschrieb die damit verbundenen wichtigen Aufgaben und Eigenschaften. Anschlie-
ßend zeigte ich auf, was ein Product Owner im Laufe der verschiedenen Scrum-Aktivitäten
in einem Projekt zu tun hat und untersuchte auch, wer für die unterschiedlichen Projektty-
pen als Product Owner infrage kommt. Ebenso führte ich aus, wie eine einzelne Person als
Product Owner für mehrere Scrum-Teams auftreten und in Einzelfällen sowohl als Product
Owner als auch als Teammitglied desselben Scrum-Teams fungieren kann. Zum Schluss
stellte ich außerdem die Konzepte des Product-Owner-Teams und insbesondere auch der
Product-Owner-Stellvertreter und des Chief Product Owners vor. Im nächsten Kapitel
befassen wir uns mit der Rolle des ScrumMasters.

223
Kapitel 10

ScrumMaster

In diesem Kapitel befasse ich mich ausführlich mit der Rolle des ScrumMasters. Nach
einer Erläuterung der grundlegenden Zusammenhänge zwischen dieser und den anderen
Scrum-Rollen stelle ich zunächst die wichtigsten Aufgaben und Eigenschaften des Scrum-
Masters vor. Danach beschreibe ich den typischen »Alltag« eines ScrumMasters und unter-
suche, ob es sich bei dieser Rolle um einen Vollzeitjob handelt. Und zum Schluss gehe ich
auf die Frage ein, wer üblicherweise für die Rolle des ScrumMasters geeignet ist.

10.1 Überblick
Der ScrumMaster repräsentiert eine der drei Rollen, aus denen jedes Scrum-Team besteht
(die anderen sind der Product Owner und das Entwicklungsteam). Während sich der Pro-
duct Owner darauf konzentriert, das richtige Produkt zu bauen und das Entwicklungsteam
sich bemüht, das Produkt richtig zu bauen, lautet die Aufgabenstellung des ScrumMasters,
allen Beteiligten dabei behilflich zu sein, die Werte, Prinzipien und Praktiken von Scrum
zu verstehen und anzunehmen. Der ScrumMaster ist sozusagen der Coach sowohl des Ent-
wicklungsteams als auch des Product Owners. Darüber hinaus leitet er die Mitarbeiter auch
in punkto Prozessführung an und unterstützt sowohl das Scrum-Team als auch die
gesamte Organisation dabei, einen individuellen, organisationsspezifischen und effizien-
ten Zugang zu Scrum zu entwickeln.

10.2 Wichtigste Aufgaben


Abbildung 10.1 veranschaulicht die wichtigsten Aufgaben des ScrumMasters.

10.2.1 Coach
Der ScrumMaster betätigt sich als agiler Coach für das Scrum-Team – sowohl für das Ent-
wicklungsteam als auch für den Product Owner. (In Adkins 2010 finden Sie eine umfas-
sende Beschreibung des Konzepts des agilen Coachings.) In dieser Eigenschaft hat er die
Möglichkeit, jedwede Barrieren zwischen diesen beiden Rollen aus dem Weg zu räumen
und es dem Product Owner zu ermöglichen, die Entwicklung direkt zu unterstützen.
Wie der Trainer einer Sportmannschaft beobachtet auch der ScrumMaster, wie das Team
Scrum anwendet und hilft ihm nach Kräften, seine Leistung zu steigern. Wenn Probleme
auftreten, die das Team selbst lösen kann, hält sich der ScrumMaster genau wie jeder
andere gute Coach an die Devise: »Ich bin nicht dafür zuständig, eure Probleme zu lösen,
sondern helfe euch lediglich dabei.« Handelt es sich bei dem Problem hingegen um ein

225
Kapitel 10
ScrumMaster

gravierendes Hindernis, das das Team alleine nicht meistern kann, greift er jedoch auch
aktiv ein.

Coach

Servant Leader

Prozessautorität
ScrumMaster-
Aufgaben
Schutz vor Störungen

Beseitigung von Hindernissen

Berater in der Organisationsentwicklung

Abb. 10.1: Die wichtigsten Aufgaben des ScrumMasters

Einem neuen Product Owner steht der ScrumMaster insofern als Coach zur Seite, als dass
er ihm hilft, seine Aufgaben zu verstehen und durchzuführen und ihm auch anschließend
bei Aktivitäten wie der Pflege des Product Backlogs weiterhin Unterstützung gewährt. In
Analogie zur Welt des Sports lässt sich die Beziehung des ScrumMasters zum Product
Owner in etwa mit der eines Mannschaftscoachs zum Besitzer eines Sportteams verglei-
chen: Er soll dem Eigentümer helfen, das Geschäftsergebnis mithilfe von Scrum zu maxi-
mieren, sich um das Erwartungsmanagement, sprich das Abwägen und Steuern der
Erwartungen kümmern, dafür sorgen, dass der Eigentümer dem Team alles Notwendige
zur Verfügung stellt sowie die Beanstandungen und Änderungswünsche des Eigentümers
vertreten und so kommunizieren, dass sie in nachweislichen Verbesserungen für das Team
resultieren.

10.2.2 »Dienende Führungskraft«


Der ScrumMaster wird oft auch als Servant Leader, zu Deutsch etwa »dienende Führungs-
kraft«, des Scrum-Teams beschrieben. Damit wird zum Ausdruck gebracht, dass er dem
Scrum-Team, obwohl er als dessen Coach fungiert, zuallererst einmal zu Diensten ist. Er
sorgt insbesondere dafür, dass die wichtigsten Bedürfnisse des Teams erfüllt werden. Und
eine »dienende Führungskraft« würde niemals fragen: »Was werdet ihr heute für mich
tun?«, sondern immer: »Was kann ich heute tun, damit das Team effizienter wird?«

226
10.2
Wichtigste Aufgaben

10.2.3 Prozessautorität
Der ScrumMaster ist die Prozessautorität des Scrum-Teams. In dieser Eigenschaft ist er
bevollmächtigt, dafür zu sorgen, dass das Scrum-Team sich nicht nur an seine eigenen
Ansätze und Vorgehensweisen, sondern auch an die Scrum-Werte, -Prinzipien und -Prakti-
ken hält. Der ScrumMaster unterstützt das Scrum-Team bei der fortlaufenden Optimie-
rung der Arbeitsprozesse, um den gelieferten Geschäftswert zu maximieren.
Der Begriff »Autorität« ist in diesem Kontext nicht identisch mit der Art von Autorität zu
sehen, die ein Abteilungsleiter oder Projektmanager innehat. So stellt der ScrumMaster
beispielsweise niemanden ein und entlässt auch keine Mitarbeiter. Ebenso wenig kann er
dem Team vorschreiben, welche Aufgaben es als Nächstes bewerkstelligen sollte oder wie
es das tun muss. Der ScrumMaster muss auch nicht dafür sorgen, dass die Arbeit erledigt
wird. Stattdessen hilft er dem Team, seinen eigenen Prozess zu definieren und diesen ein-
zuhalten, um die Arbeit zu schaffen.

10.2.4 Schutz vor störenden Einflüssen


Des Weiteren schützt der ScrumMaster das Entwicklungsteam vor Störfaktoren von außen,
damit es sich weiter darauf konzentrieren kann, mit jedem Sprint Geschäftswerte abzulie-
fern. Störende Einflüsse können die unterschiedlichsten Quellen haben – von Managern,
die mitten im Sprint Teammitglieder umsetzen wollen, bis hin zu anderen Teams, die Pro-
bleme verursachen. Ganz egal, wo die Quelle für die Störungen liegt: Der ScrumMaster
agiert als Puffer (er beantwortet Anfragen, kümmert sich um das Management und schlich-
tet Streitigkeiten), damit sich das Team auf seine eigentliche Arbeit konzentrieren kann.

10.2.5 Beseitigung von Hindernissen


Außerdem ist der ScrumMaster dafür verantwortlich, Hindernisse aus dem Weg zu räu-
men, die die Produktivität eines Teams beeinträchtigen könnten (sofern es nicht selbst
dazu in der Lage ist). So habe ich einmal ein Scrum-Team beobachtet, das es andauernd
nicht geschafft hat, seine Sprint-Ziele zu erreichen. Behindert wurde es durch instabile Pro-
duktionsserver, die das Team während seiner Tests (als Teil seiner Definition von Fertig)
benutzte. Das Team selbst hatte keine Kontrolle über diese Server – sie unterstanden der
Verantwortung des Betriebsleiters. Und da die Teammitglieder das Hindernis nicht selbst
beseitigen konnten, nahm es der ScrumMaster auf sich, die Serverstabilität zu verbessern,
indem er mit dem Betriebsleiter und anderen zusammenarbeitete, die dieses Problem tat-
sächlich lösen konnten.

10.2.6 Berater in der Organisationsentwicklung


Für einen guten ScrumMaster reicht es aber noch lange nicht aus, sich lediglich um Ersatz
für fehlerhafte Server zu kümmern und ähnliche Hindernisse aus dem Weg zu räumen.
Ein guter ScrumMaster hilft dem Team auch dabei, seine Denkweise zu ändern. Scrum
kann den bislang üblichen Status Quo ganz beträchtlich durcheinanderbringen. Und die
Anpassungen, die nötig sind, um mit Scrum Erfolg zu haben, können schwierig und
schmerzhaft sein. Hier hilft der ScrumMaster, die Notwendigkeit dieser Änderungen, die
Auswirkungen von Scrum außerhalb des Scrum-Teams sowie die weitreichenden Vorteile,
die mit Scrum erreicht werden können, zu vermitteln. Außerdem sorgt er dafür, dass tat-

227
Kapitel 10
ScrumMaster

sächlich auf allen Ebenen der Organisation Veränderungen stattfinden, damit nicht nur
kurzfristige Erfolge erzielt werden, sondern auch langfristig ein Nutzen aus Scrum gezo-
gen werden kann. In großen Organisationen könnten sich die ScrumMaster auch zusam-
menschließen, um noch nachdrücklicher auf eine Änderung hinzuwirken.

10.3 Eigenschaften/Fähigkeiten
Abbildung 10.2 zeigt wichtige Eigenschaften eines ScrumMasters.

Sachkundig

Neugierig

Geduldig
ScrumMaster-
Eigenschaften
Zur Zusammenarbeit fähig

Schützend

Transparent

Abb. 10.2: Eigenschaften des ScrumMasters

10.3.1 Sachkundig
Um ein effizienter Prozesscoach sein zu können, muss sich der ScrumMaster selbstver-
ständlich sehr gut mit Scrum auskennen. Er sollte die technischen Probleme, denen sich
das Team gegenübersieht, ebenso gut verstehen wie die Technologien, die das Team für die
Entwicklung seiner Lösungen verwendet. Ein ScrumMaster muss zwar nicht unbedingt ein
Experte auf diesem Gebiet sein, ein vernünftiges technisches Verständnis schadet jedoch
auf keinen Fall. Ebenso wenig muss er im geschäftlichen Bereich allzu versiert sein (dazu
ist der Product Owner da), dennoch gilt auch hier, dass ein gewisses Grundverständnis vor-
handen sein sollte.

10.3.2 Neugierig
ScrumMaster kombinieren ihre Fähigkeiten als Coach und ihre Kenntnisse hinsichtlich der
Arbeitsprozesse, der eingesetzten Technik und den geschäftlichen Aspekten, um zielfüh-

228
10.3
Eigenschaften/Fähigkeiten

rende Fragen zu stellen. Sie initiieren bewusst investigative Gespräche, in denen sie Fragen
stellen, die ihre Gesprächspartner innehalten und sagen lassen: »Hm, darüber habe ich
noch nie nachgedacht. Aber jetzt, wo du es sagst, denke ich, dass es auch einen anderen
Weg geben könnte.« Richtig gute ScrumMaster beantworten Fragen fast nie direkt, sondern
reagieren automatisch mit einer Gegenfrage – allerdings nicht etwa einer lästigen oder um
des Fragens willen gestellten, sondern einer wohlüberlegten, tiefgreifenden, bohrenden
Frage –, mit der sie den Beteiligten erkennen helfen, dass sie selbst genug wissen, um
eigene Antworten darauf zu finden (eine Form des Sokratischen Gesprächs).

10.3.3 Geduldig
Da es ScrumMaster vorziehen, keine unmittelbaren Lösungen bzw. Antworten auf irgend-
welche Problemstellungen vorzugeben, müssen sie natürlich auch Geduld aufbringen und
dem Team Zeit geben, der Sache von selbst auf den Grund zu kommen. Für mich persön-
lich ist es manchmal recht schwierig, ScrumMaster zu sein – eben weil ich das Problem
erkenne, mit dem sich das Team herumschlägt, und die Lösung »weiß«. Nun, zumindest
glaube ich, die Lösung zu wissen! Es gibt einem schon ein gewisses Gefühl der Überlegen-
heit (und das geht mir und jedem anderen ScrumMaster so), wenn man selbst den Ein-
druck hat, man sei cleverer als die geballte Intelligenz des Teams. Deshalb muss ich mir
manchmal einfach auf die Zunge beißen, das Team die Lösung erarbeiten lassen und nur
gelegentlich zielführende Fragen stellen, um die Dinge ein wenig voranzubringen.

10.3.4 Teamfähig
Der ScrumMaster muss in der Lage sein, mit dem Product Owner, dem Entwicklungsteam
und allen anderen Parteien zusammenzuarbeiten, selbst wenn diese nicht unmittelbar mit
Scrum an sich zu tun haben. Als Prozesscoach hält der ScrumMaster außerdem immer
nach Gelegenheiten Ausschau, um die Mitglieder des Scrum-Teams dabei zu unterstützen,
eine mustergültige Zusammenarbeit innerhalb des Teams zu erreichen, beispielsweise
indem er selbst außergewöhnlichen Teamgeist beweist.

10.3.5 Schützend
Der ScrumMaster sollte sich schützend vor das Team stellen. Ähnlich wie ein Hütehund
seine Schäfchen vor den angriffslustigen Wölfen schützt, wacht auch der ScrumMaster
sorgsam über sein Team. Bildlich gesprochen, könnte es sich bei den Wölfen um organisa-
torische Hindernisse oder Personen mit abweichenden Zielen handeln. Im größeren Kon-
text, wenn es um wirtschaftlich sinnvolle Geschäftsentscheidungen geht, fungiert der
ScrumMaster als zuverlässiger »Bodyguard« des Teams. Er hat ein gutes Gespür sowohl für
die Belange des Teams als auch die Bedürfnisse der Organisation und hilft dem Scrum-
Team dabei, einen gesunden Mittelweg zu finden.
Darüber hinaus kümmert sich der ScrumMaster aber auch um Teammitglieder, die den
Anschluss an die »Herde« zu verlieren drohen. Wenn Schwierigkeiten auftreten, kann der
ein oder andere schnell mal in vertraute, nicht-agile Arbeitsweisen zurückfallen – und dann
ist es Aufgabe des ScrumMasters, Abweichler wieder einzufangen und ihnen zu helfen,
ihre Probleme zu überwinden, indem er ihnen aufzeigt, wie sie Scrum effizienter nutzen
können.

229
Kapitel 10
ScrumMaster

10.3.6 Transparent
Und schließlich sorgt der ScrumMaster auch dafür, dass in allen Formen der Kommunika-
tion höchstmögliche Transparenz herrscht. In der Zusammenarbeit mit dem Team ist kein
Platz für Heimlichtuerei und verborgene Motive. Was man vom ScrumMaster sieht und
hört, muss absolut verlässlich sein. Nichts weniger als das erwarten die Mitarbeiter von
einer »dienenden Führungskraft«. Und auch außerhalb des Scrum-Teams fördert der
ScrumMaster eine transparente Kommunikation – denn ohne einen transparenten Infor-
mationszugang kann sich die Organisation kaum selbst auf den Prüfstand stellen und ggf.
nötige Anpassungen und Veränderungen vornehmen, um mit Scrum die gewünschten
Geschäftsergebnisse zu erzielen.

10.4 Alltag
Aber wie genau sieht denn nun der Alltag eines ScrumMasters während eines Sprints aus?
In Abbildung 10.3 ist zu sehen, wie viel Zeit der ScrumMaster eines neu gebildeten Teams
ungefähr für jede der verschiedenen Aktivitäten im Laufe eines Sprints aufwenden könnte.
Sollte er allerdings ein leistungsstarkes Scrum-Team coachen, das schon mehrere Jahre
zusammenarbeitet, fallen die hier dargestellten Prozentwerte voraussichtlich etwas anders
aus.

100%
Aufgewendete Zeit

Beseitigung von Hindernissen


80%
Kommunikation
60% Organisationsentwicklung
Assistenz für Product Owner
40%
Trainieren des Teams
20% Scrum-Aktivitäten

0%
1 2 3 4 5 6 7 8 9 10
Tag in einem Sprint

Abb. 10.3: Alltag eines ScrumMasters

Wie in der Abbildung gezeigt, wendet der ScrumMaster jeden Tag ein gewisses Zeitkontin-
gent für die Organisation und Unterstützung der Scrum-Aktivitäten auf. Dazu gehören die
Sprint-Planung und -Durchführung, die Sprint-Reviews und -Retrospektiven sowie der
Daily Scrum. Diese Aktivitäten müssen angeschoben und überwacht werden, so dass das
restliche Scrum-Team in der Lage ist, auf einem Niveau zu arbeiten, auf dem es hochwer-
tige Ergebnisse erzielen kann.
Das Coaching der Teammitglieder zwecks einer verbesserten Nutzung sowohl von Scrum
als auch von den technischen Praktiken findet tagtäglich statt. Außerdem führt der Scrum-
Master ggf. auch Trainingseinheiten zur Auffrischung durch – indem er z.B. ein neues
Team beim Schätzen von Product-Backlog-Elementen an die Regeln des Planungspokers

230
10.5
Die Rolle ausfüllen

erinnert. Ein bestimmtes tägliches Zeitkontingent ist überdies der Kommunikation gewid-
met (etwa zur Aktualisierung von Sprint und Release Burndown oder Burnup Charts oder
für Gespräche mit Nicht-Scrum-Teammitgliedern).
Während des Sprints arbeitet der ScrumMaster mit dem Product Owner an der Pflege des
Product Backlogs (wie etwa dem Schreiben und Priorisieren neuer Product-Backlog-
Elemente). Zudem sorgt er ebenfalls gemeinsam mit dem Product Owner dafür, dass
wirtschaftlich vertretbare Kompromisse hinsichtlich wichtiger Variablen wie dem Funk-
tionsumfang, der Terminplanung, dem Budget und der Qualität geschlossen werden.
Ebenso verwendet der ScrumMaster einen Teil seiner Zeit darauf, der Organisation behilf-
lich zu sein, in ihrer Wertekette (Verkauf, Marketing, Personal, Subunternehmer usw.) ein
besseres Verständnis für Scrum zu entwickeln.
Ein (variabler) Zeitanteil seines Arbeitstages ist der Beseitigung von Hindernissen gewid-
met. Prinzipiell könnte der ScrumMaster zwar für diese Aktivität einen festen täglichen
Zeitrahmen reservieren, aber natürlich können jederzeit Hindernisse auftauchen und noch
dazu umfangreich und vordringlich sein. Deshalb muss er die Möglichkeit haben, seine
Zeitkontingente möglichst flexibel auf die diversen Aktivitäten verteilen zu können, um
auch auf unvorhergesehene Ereignisse bzw. Umstände reagieren zu können.
Die meisten Teams und Organisationen, die sich noch nicht mit Scrum auskennen, haben
anfänglich mit einer Menge Probleme zu kämpfen und konzentrieren sich dabei in aller
Regel vorrangig auf diejenigen, die offensichtlich und einfach zu beseitigen sind. Das
bedeutet jedoch nicht, dass man alle Hindernisse so leicht wieder loswird. Im Gegenteil:
Die nächste Problemstufe wird vermutlich sogar viel schwieriger und zeitaufwendiger zu
bewältigen sein. Die Aufgabe der Beseitigung von Hindernissen ist eine große Unbekannte
im Alltag eines ScrumMasters – denn sie kann die Zeitplanung, die in Abbildung 10.3 zu
sehen ist, schnell über den Haufen werfen.

10.5 Die Rolle ausfüllen


Wenn wir die Rolle des ScrumMasters besetzen, müssen wir sorgfältig überlegen, wer am
besten dafür geeignet ist, ob es sich um eine Vollzeitbeschäftigung handelt und ob sie mit
anderen Scrum- und Nicht-Scrum-Rollen kombiniert werden kann.

10.5.1 Wer sollte ScrumMaster sein?


Organisationen, die gerade erst in Scrum einsteigen, haben sich in aller Regel noch keine
Gedanken um die geeignete Personalie für die Rolle des ScrumMasters gemacht. Wo also
finden wir einen ScrumMaster? Ich habe großartige ScrumMaster kennengelernt, die vor-
her alle möglichen Positionen innehatten. Einige von ihnen waren zuvor als Projektmana-
ger oder Produktmanager tätig (obwohl Produktmanager viel eher in die Rolle des Product
Owners schlüpfen), andere ScrumMaster kommen aus der Entwicklung, dem Testbereich
oder haben einen anderen technischen Hintergrund. Solange eine Person die zuvor
erwähnten Eigenschaften besitzt und bereit ist, die mit dieser Rolle einhergehende Verant-
wortung zu übernehmen, kann sie ein effizienter ScrumMaster werden.
Manche Organisationen vertreten den Standpunkt, dass der technische Leiter oder der Ent-
wicklungschef die beste Wahl für den Job des ScrumMasters ist. Und in der Tat können sol-

231
Kapitel 10
ScrumMaster

che Leute sehr gut als ScrumMaster geeignet sein – möglicherweise aber auch nicht, denn
schließlich bekleiden sie nicht ohne Grund eine technische Führungsposition: Weil sie in
dem, was sie tun, sehr gut sind. Die ScrumMaster-Rolle kann diese Art von technischer
Expertise jedoch nicht in vollem Umfang ausnutzen. Und immer wenn technische Leiter
die Arbeit eines ScrumMasters erledigen, sinkt dadurch notgedrungen auch das Ausmaß
ihrer Effizienz als technische Führungskraft. Und in der Folge könnte es durchaus passie-
ren, dass das technische Ergebnis des Entwicklungsprojekts negativ beeinflusst wird, wenn
man solche Leute zum ScrumMaster macht. Ich werde später in diesem Kapitel noch da-
rauf eingehen, ob ein Mitglied des Entwicklungsteams gleichzeitig als ScrumMaster agie-
ren kann.
Auch Manager aus funktionalen Bereichen oder Ressourcenmanager können als Scrum-
Master erfolgreich sein, sofern sie die Fähigkeiten für den Job mitbringen. Allerdings wäre
es am besten, wenn sie dann nicht länger für die Personalverwaltung zuständig wären –
zumindest nicht für die Mitglieder ihrer Scrum-Teams. Da ein ScrumMaster keine betrieb-
liche Autorität besitzt, könnte dies andernfalls zu Verwirrung unter den Teammitgliedern
führen, weil sie nicht wissen, ob die Person in einem speziellen Fall als ScrumMaster oder
als Manager handelt. Aus diesem Grund versuche ich, solche Situationen zu vermeiden.
Manchmal ist es jedoch trotzdem unumgänglich, so dass wir in solchen Fällen lernen müs-
sen, mit potenziellen Interessenkonflikten zurechtzukommen.

10.5.2 Ist die Rolle des ScrumMasters eine Vollzeitbeschäftigung?


Jedes Scrum-Team hat einen ScrumMaster – doch ist die Rolle des ScrumMasters ein Voll-
zeitjob? Vermutlich nicht. Ein Scrum-Team, das bereits eine ganze Weile zusammenarbei-
tet und inzwischen gut mit Scrum zurechtkommt, braucht sicher weniger Coaching als ein
neues Team, das aus Leuten besteht, die noch nie zusammengearbeitet haben und sich mit
Scrum nicht auskennen.
Doch selbst wenn der ScrumMaster mit wachsender Erfahrung des Teams weniger Zeit mit
ihm verbringen muss, spielt er dennoch eine entscheidende Rolle für den Erfolg von
Scrum in der Organisation: Wenn der Bedarf des Teams an der tatkräftigen Unterstützung
des ScrumMasters sinkt, muss er sich normalerweise in erhöhtem Maße den logistischen
Hemmnissen zuwenden und einen Wandel innerhalb der Organisation herbeiführen.
In den meisten Fällen erfordert die Rolle des ScrumMasters auch weiterhin einen beträcht-
lichen Zeiteinsatz. Und in den Fällen, in denen sie tatsächlich keine Vollzeitbeschäftigung
ist, kann auch eine Rollenkombination in Erwägung gezogen werden.

10.5.3 ScrumMaster in Kombination mit anderen Rollen


Wenn jemand genügend freie Kapazitäten hat und sowohl als ScrumMaster als auch als
Mitglied des Entwicklungsteams infrage kommt, kann diese Person ggf. auch beide Rollen
wahrnehmen. Allerdings könnte es in dieser Kombination zu einem Interessenkonflikt
kommen, wenn der oder die Betreffende versucht, in beiden Rollen zugleich aufzutreten.
Stellen Sie sich z.B. vor, dass wichtige ScrumMaster-Aktivitäten erledigt werden müssen
(wie etwa das Beseitigen von Hindernissen) und gleichzeitig wichtige Aufgaben auf Task-
Ebene anstehen. Da beides gleichermaßen bedeutsam ist, wird die Effizienz des Scrum-
Teams beeinträchtigt, wenn in einem der beiden Bereiche Abstriche gemacht werden müs-

232
10.6
Abschließende Bemerkungen

sen. Verkompliziert wird die Lage zusätzlich noch dadurch, dass unerwartete Hindernisse
auftreten können, deren Beseitigung möglicherweise viel Zeit beansprucht. Damit wird es
noch schwieriger vorherzusagen, wie viel Zeit ein ScrumMaster als Teammitglied tatsäch-
lich noch für die Verrichtung der eigentlichen Aufgaben zur Verfügung hat.
Es gibt jedoch einen anderen Ansatz, der oft besser funktioniert: Sofern ein ScrumMaster
wirklich noch freie Kapazitäten hat, finde ich es meist sinnvoller, wenn diese Person als
ScrumMaster für mehrere Scrum-Teams arbeitet (siehe Abbildung 10.4).
Um ein guter ScrumMaster zu werden, braucht man wertvolle, nicht besonders häufig
anzutreffende Fertigkeiten. Insofern ziehe ich persönlich die Variante vor, bei der eine Per-
son, die diese Fertigkeiten mitbringt, mehreren Teams zur Verfügung steht, statt Zeit mit
Aktivitäten zu vergeuden, die nichts mit der ScrumMaster-Tätigkeit zu tun haben. Das ist
allerdings nur meine persönliche Ansicht, faktisch habe ich aber durchaus schon Scrum-
Teams erlebt, die mit beiden Ansätzen erfolgreich waren. In dieser Frage gibt es also keine
richtige oder falsche Antwort, aber es könnte ein falsches oder richtiges Vorgehen in einem
speziellen organisatorischen Kontext geben könnte.

Dieselbe Person
Product Owner als ScrumMaster Product Owner

Entwicklungsteam Entwicklungsteam

Abb. 10.4: Dieselbe Person als ScrumMaster für mehr als ein Team

Wie ich in Kapitel 9 bereits erwähnte, ist von der Rollenkombination aus ScrumMaster und
Product Owner dringend abzuraten, denn in seiner Eigenschaft als Coach des Scrum-
Teams ist der ScrumMaster auch der Scrum-Coach für den Product Owner – und man
kann ja schlecht sein eigener Coach sein. Darüber hinaus verfügt der Product Owner über
echte Produktautorität und kann Forderungen an das Team stellen. Der ScrumMaster tritt
hingegen meist als Vermittler in Bezug auf die Forderungen des Product Owners und die
Bedürfnisse und Fähigkeiten des Entwicklungsteams auf. Wenn Product Owner und
ScrumMaster eine Personalunion bilden, führt das nur zu unnötiger und noch dazu leicht
vermeidbarer Verwirrung.

10.6 Abschließende Bemerkungen


In diesem Kapitel habe ich die Rolle des ScrumMasters sowie seine Aufgaben als Coach,
»dienende Führungskraft«, Prozessautorität, schützende Instanz, Beseitiger von Hinder-
nissen und Berater in der Organisationsentwicklung beschrieben. Ebenso erörterte ich,
dass sich der ScrumMaster gut mit Scrum auskennen, zielführende Fragen stellen, gedul-

233
Kapitel 10
ScrumMaster

dig auf Problemlösungsvorschläge des Teams warten, mit allen Beteiligten zusammenar-
beiten, das Team vor unnötigen Störungen schützen sowie auf sichtbare und transparente
Weise kommunizieren können sollte. Als Nächstes ging ich dann zur Verdeutlichung die-
ser wichtigen Rolle auf die Einteilung des Zeitkontingents des ScrumMasters während
eines Sprints ein. Und zum Schluss zeigte ich die wichtigsten Kriterien für die Entschei-
dungsfindung in Bezug auf die Fragen auf, wer in der Organisation zum ScrumMaster
ernannt werden sollte, ob es sich um eine Vollzeitbeschäftigung handelt und wie man die
Rolle des ScrumMasters mit anderen Scrum-Rollen kombinieren könnte.
Im nächsten Kapitel werde ich genauer untersuchen, welche Rolle das Entwicklungsteam
in Scrum spielt.

234
Kapitel 11

Das Entwicklungsteam

In diesem Kapitel beschreibe ich die Rolle des Entwicklungsteams. Ich untersuche zuerst
die fünf wichtigsten Aufgaben dieser Rolle und schließe mit einer Beschreibung von zehn
Eigenschaften, die ein Entwicklungsteam aufweisen sollte.

11.1 Überblick
Traditionelle Softwareentwicklungsansätze definieren verschiedene Tätigkeitsarten wie
etwa Softwarearchitekt, Programmierer, Tester, Datenbankadministrator, UI (User Inter-
face)-Designer usw. Scrum definiert dagegen die Rolle des Entwicklungsteams. Im Prinzip
handelt es sich dabei einfach um eine funktionsübergreifende Ansammlung all dieser ver-
schiedenen Fachleute. Insbesondere repräsentiert das Entwicklungsteam eine der drei Rol-
len, die es in jedem Scrum-Team gibt. Die Mitglieder des Entwicklungsteams besitzen
zusammen alle Fähigkeiten, die nötig sind, um den vom Product Owner angeforderten
Geschäftswert zu liefern.
Der Begriff »Entwicklungsteam« mag vielleicht die falsche Bezeichnung für ein Team sein,
das aus mehr als nur den Entwicklern besteht. Es wurden auch schon andere Namen ver-
wendet, wie etwa »Delivery Team«, »Design-Bau-Test-Team« und auch nur »Team« – es ist
allerdings fraglich, ob eine dieser Bezeichnungen passender, weniger missverständlich
oder einfacher zu benutzen ist. Im Moment hat sich die Scrum-Gemeinde auf den Begriff
»Entwicklungsteam« geeinigt, weshalb auch ich ihn in diesem Buch benutzen werde.

11.2 Rollenspezifische Teams


Viele Organisationen teilen unterschiedliche Arbeitsbereiche absichtlich auf spezialisierte,
rollenspezifische Teams auf. Das heißt, es existiert beispielsweise ein Team aus Designern,
eins aus Entwicklern und wieder ein anderes aus Testern, die die in ihrem Fachbereich
anfallenden Arbeiten nach der Fertigstellung an andere Teams weiterreichen und somit
mehr oder weniger unabhängig voneinander arbeiten.
In Scrum muss das Entwicklungsteam in jedem Sprint sämtliche für die Herstellung eines
oder mehrerer vertikaler Bestandteile der Produktfunktionalität anfallenden Arbeiten erle-
digen. Dazu gehören unter anderem das Design, die Entwicklung, die Integration sowie
das Testen dieser Funktionalität. Deshalb muss sich unser Team mit all diesen Aufgaben
auskennen.
Manche Organisationen versuchen auch, zusätzlich zum Scrum-Team ein separates Team
zum Testen bzw. für die Qualitätssicherung zu bilden. Ich muss zugestehen, dass es

235
Kapitel 11
Das Entwicklungsteam

manchmal notwendig sein kann, ein Team zu haben, das sich eigens auf die Tests konzen-
triert – weil z.B. eine behördliche Anordnung ein separates Team für die Durchführung
bestimmter Tests vorschreibt – meist ist das aber nicht erforderlich. In der Regel sollte das
Testen vielmehr vollständig in die Arbeit integriert sein, die während der einzelnen Sprints
stattfindet – und aus diesem Grund sollte das Entwicklungsteam, das die Arbeit während
des Sprints erledigt, auch die Tests durchführen.
Schaffen Sie nach Möglichkeit immer funktionsübergreifende Teams. Der erfolgreiche Ein-
satz von Scrum wird durch die Verteilung der Arbeit an unterschiedliche, rollenspezifische
Teams ernsthaft behindert. Wenn Sie auf diese Weise vorzugehen planen, sollten Sie
zunächst sicherstellen, dass dies nicht aus reiner Gewohnheit geschieht, sondern zweifels-
frei ein echter Bedarf an rollenspezifischen Teams besteht.

11.3 Wichtigste Aufgaben


Abbildung 11.1 zeigt die Scrum-Aktivitäten in Bezug auf die wichtigsten Aufgaben des Ent-
wicklungsteams.

Pflegen Planen Durchführen Untersuchen & Anpassen

Daily Scrum
Sprint-Planung
Sprint Backlog
Product Backlog
Sprint-Ausführung

Pflege

Potenziell
auslieferungsfähiges
Produktinkrement

Sprint Review
Sprint-Retrospektive

Untersuchen & Anpassen

Abb. 11.1: Aufgaben des Entwicklungsteams in Bezug auf die Scrum-Aktivitäten

Ich werde diese Aufgaben nachfolgend im Einzelnen beschreiben.

11.3.1 Durchführung des Sprints


Während des Sprints erledigen die Mitglieder des Entwicklungsteams die eigentliche, krea-
tive Arbeit des Entwerfens, Bauens, Integrierens und Testens der Product-Backlog-Ele-
mente, so dass Inkremente potenziell auslieferungsfertiger Funktionalität entstehen. Dazu

236
11.3
Wichtigste Aufgaben

organisiert sich das Team selbst und entscheidet gemeinschaftlich, wie die Arbeit geplant,
aufgeteilt, ausgeführt und kommuniziert werden soll (mehr dazu in Kapitel 20). Das Ent-
wicklungsteam bringt also einen Großteil seiner Zeit mit der Sprint-Durchführung zu.

11.3.2 Tägliches Untersuchen und Anpassen (»Inspect and Adapt«)


Grundsätzlich ist die Teilnahme am Daily Scrum, bei dem das Team gemeinsam den Fort-
schritt zum Sprint-Ziel hin überprüft, für alle Teammitglieder Pflicht, damit entsprechende
Anpassungen in der Arbeitsplanung des aktuellen Tages vorgenommen werden können.
Sollten sich die Teammitglieder nicht vollzählig daran beteiligen, kann es passieren, dass
das Team den Gesamtüberblick verliert und möglicherweise sein Sprint-Ziel verfehlt.

11.3.3 Pflege des Product Backlogs


Ein Teil jedes Sprints ist der Vorbereitung des nächsten Sprints gewidmet. Dabei konzen-
triert sich ein Großteil der hiermit verbundenen Arbeit auf die Pflege des Product Backlogs,
sprich das Anlegen und Verfeinern, Schätzen und Priorisieren der Product-Backlog-Ele-
mente (mehr dazu finden Sie in Kapitel 6). Das Entwicklungsteam sollte in jedem Sprint
bis zu 10% seiner verfügbaren Kapazität reservieren, um dem Product Owner bei diesen
Aktivitäten zu helfen.

11.3.4 Den Sprint planen


Zu Beginn jedes Sprints beteiligt sich das Entwicklungsteam zunächst einmal an der
Sprint-Planung, um gemeinsam mit dem Product Owner und mit Unterstützung des
ScrumMasters bei der Definition der Zielsetzung für den nächsten Sprint zu helfen.
Anschließend legt das Team fest, welche hochpriorisierte Teilmenge der Product-Backlog-
Elemente es bauen muss, um dieses Ziel zu erreichen (siehe Kapitel 19). Die Sprint-Pla-
nung für einen zweiwöchigen Sprint dauert üblicherweise etwa einen halben Tag, die Pla-
nung eines vierwöchigen Sprints könnte somit auch einen ganzen Tag in Anspruch
nehmen.
Beachten Sie, dass die Planung iterativ erfolgt: Anstatt sich am Anfang der Entwicklung auf
einen sehr großen, unsicheren und übermäßig detaillierten Plan zu konzentrieren, stellt
das Team rechtzeitig zu Beginn jedes Sprints eine Reihe kleinerer, sichererer und detaillier-
terer Pläne auf.

11.3.5 Produkt und Prozess untersuchen und anpassen


Am Ende jedes Sprints nimmt das Entwicklungsteam an zwei Aktivitäten zum Untersu-
chen und Anpassen teil: dem Sprint Review und der Sprint-Retrospektive. Beim Sprint
Review betrachten Entwicklungsteam, Product Owner, ScrumMaster, Stakeholder, Sponso-
ren, Kunden sowie interessierte Mitglieder anderer Teams die gerade abgeschlossenen
Funktionen des aktuellen Sprints und diskutieren, wie am besten weiter verfahren wird
(siehe Kapitel 21). In der Sprint-Retrospektive stellt das Scrum-Team seinen Scrum-Prozess
sowie seine technischen Verfahren auf den Prüfstand und passt sie ggf. an, um Scrum
effektiver für die Wertschöpfung einzusetzen (siehe Kapitel 22).

237
Kapitel 11
Das Entwicklungsteam

11.4 Eigenschaften/Fertigkeiten
Abbildung 11.2 zeigt wichtige Eigenschaften des Entwicklungsteams.

Selbstorganisierend

Funktionsübergreifend vielseitig

T-förmige Fertigkeiten

Musketier-Einstellung

Entwicklungsteam-
Breitbandige Kommunikation
Eigenschaften

Transparente Kommunikation

Richtige Größe

Fokussiert und verpflichtet

Nachhaltiges Arbeitstempo

Langlebig

Abb. 11.2: Eigenschaften des Entwicklungsteams

11.4.1 Selbstorganisierend
Die Teammitglieder organisieren sich selbst, um die beste Methode zum Erreichen des
Sprint-Ziels zu finden. Das bedeutet, es gibt keinen Projekt- oder anderen Manager, der
ihnen sagt, wie sie arbeiten sollen (und ein ScrumMaster sollte sich niemals erdreisten, das
zu tun). Die Selbstorganisation ist eine Bottom-Up-Eigenschaft des Systems, d.h., sie ver-
läuft von unten nach oben, es gibt keine externe Kraft, die ein traditionelles, von oben auf-
oktroyiertes Management durchzusetzen versucht.
Ich möchte das an einem Beispiel verdeutlichen. In der Nähe meines Wohnortes in Colo-
rado gibt es einen Teich. Im Winter kommt immer ein Schwarm Kanadagänse und rastet
dort. Jedes Jahr haben wir also mehrere Hundert Gänse bei uns, die gleichzeitig nett anzu-
sehen sind und eine riesige Sauerei veranstalten. Nun besitze ich allerdings zwei Hunde
namens Letti und Toast. Normalerweise bleiben sie innerhalb des umzäunten Grund-
stücks, gelegentlich lassen wir sie jedoch draußen herumlaufen und wenn sie die Gänse
am Teich sehen, dann laufen sie hin, um sie zu begrüßen. Ich glaube nicht, dass sie die
Gänse jagen würden, aber wenn die Gänse Letti und Toast kommen sehen, dann entschei-
den sie üblicherweise, ihnen den Teich zu überlassen und fliegen auf.

238
11.4
Eigenschaften/Fertigkeiten

Haben Sie sich schon mal gefragt, woher ein auffliegender Vogelschwarm weiß, dass er das
charakteristische V-Muster (Schwarmmuster) formen muss? Glauben Sie, es gibt irgendwo
einen »Managervogel« mit einem imaginären Klemmbrett, der am Teich ein Treffen aller
Vögel einberuft, um sie anzuweisen, wie sie im Schwarm fliegen sollen (siehe Abbildung
11.3)?
Ich lebe nun schon sehr lange neben dem Teich und kann mich nicht erinnern, jemals ein
solches Treffen erlebt zu haben. (Obwohl mein Sohn Jonah vor einigen Jahren erklärte:
»Dad, du hast das noch nie gesehen, weil sie sich in der Nacht treffen!« Hm, da könnte
etwas dran sein...)
Die Gänse bilden ihren Schwarm natürlich durch Selbstorganisation, eine von unten nach
oben verlaufende Eigenschaft eines komplexen adaptiven Systems – es sei denn natürlich,
mein Sohn hat recht und die Vögel sind viel schlauer, als ich dachte. In solchen Systemen
interagieren viele Einheiten auf verschiedene Arten miteinander. Und diese Interaktionen
werden durch einfache, lokalisierte Regeln bestimmt, die in einem Kontext aus konstantem
Feedback arbeiten (siehe Abbildung 11.4).

Hört zu!
Wenn wir abheben, fliege ich
voran. George, du bleibst 1 Meter
links hinter mir, und Cindy, du fliegst
1 Meter rechts hinter mir. Der
Rest verteilt sich fächerförmig
dahinter.

Ich

Abb. 11.3: Schwarmverhalten ist nicht das Ergebnis einer Top-Down-Planung

Solche Systeme weisen interessante Eigenschaften auf, sind bemerkenswert robust und
produzieren erstaunliche Innovationen.

239
Kapitel 11
Das Entwicklungsteam

Genau wie bei den schwärmenden Vögeln gibt es auch beim Entwicklungsteam keine
befehlsgebende Autorität von oben, die dem Team vorgibt, wie es seine Arbeit tun soll.
Stattdessen organisiert sich ein funktionsübergreifendes Team aus ganz unterschiedlichen
Leuten selbst auf die bestmögliche Weise, um die anstehende Arbeit erledigen zu können.
Im Prinzip bildet das Team seine Variante des V-Musters.

• Drängelt nicht
• Fliegt in ungefähr dieselbe
Richtung wie die Nachbarn
• Fliegt an derselben Position
relativ zu den Nachbarn

Abb. 11.4: Schwarmverhalten: einfache Regeln und häufiges Feedback

Dennoch spielen die Manager eine wichtige Rolle in Scrum: Sie schaffen (und erhalten) die
Umgebung für das sich selbst organisierende Team. Auf die Rolle der Manager werde ich in
Kapitel 13 noch ausführlicher zu sprechen kommen.

11.4.2 Funktionsübergreifend vielseitig


Die Mitglieder des Entwicklungsteams sollten funktionsübergreifend ausgerichtet sein.
Zusammen sollten sie die notwendigen und hinreichenden Fertigkeiten besitzen, um das
komplette Projekt bewerkstelligen zu können. Ein gut aufgestelltes Team kann ein Element
aus dem Product Backlog nehmen und eine hochwertige, funktionierende Funktion her-
stellen, die der Definition von Fertig des Scrum-Teams folgt.
Teams, die ausschließlich aus Leuten mit denselben Fertigkeiten bestehen (sogenannte
Silo-Teams), können höchstens einen Teil der Arbeit erledigen, daher müssen sie ihre Pro-
dukte schließlich wiederum an andere Silo-Teams übergeben. So übergibt z.B. das Entwick-
lungsteam den Code an das Testteam oder das UI-Team gibt die Bildschirmentwürfe an das
Team weiter, das für die Geschäftslogik zuständig ist. Übergaben bergen allerdings ein
hohes Potenzial für Missverständnisse und teure Fehler – und mit vielseitigen Teams kön-
nen wir die Anzahl der Übergaben minimieren, ohne vollständig darauf verzichten zu
müssen, mehrere Teammitglieder zu haben, die sich außerordentlich gut in ein und dersel-
ben Disziplin wie etwa der Java- oder C++-Entwicklung oder dem Testen auskennen.

240
11.4
Eigenschaften/Fertigkeiten

Funktionsübergreifend vielseitige Teams bringen darüber hinaus auch vielfältige Sichtwei-


sen in die Arbeit ein, was letztlich zu besseren Ergebnissen führt (siehe Abbildung 11.5).

Funktionsübergreifende Teammitglieder
Funktionsübergreifend
vielseitig
Unterschiedliche Hintergründe

Interpretationen

Strategien/Heuristiken
Entwicklungsteam- Unterschiedliche
Vielseitigkeit Perspektiven
Mentale Modelle

Vorlieben

Schnellere Lösungen

Bessere Ergebnisse Bessere Lösungen

Größere Innovationen

Abb. 11.5: Teamvielseitigkeit

Ein funktionsübergreifendes Team besteht aus Mitgliedern mit verschiedenen Hintergrün-


den. Jedes Teammitglied bringt seine eigenen kognitiven Werkzeuge zum Lösen von Pro-
blemen mit. Zu diesen Werkzeugen können unterschiedliche Interpretationen (derselben
Daten), unterschiedliche Lösungsstrategien (oder Heuristiken) für auftretende Probleme,
unterschiedliche mentale Modelle für die Funktionsweise von Elementen und unterschied-
liche Vorlieben für Vorgehensweisen und Lösungen gehören. Diese Art der Vielseitigkeit
führt in der Regel zu besseren Ergebnissen, d.h. schnelleren Lösungen, höherwertigen Pro-
dukten und bedeutenderen Innovationen, was sich wiederum in einem größeren wirt-
schaftlichen Wert niederschlägt (Page 2007).
Wir sollten Teamvielseitigkeit auch in dem Sinne verstehen, dass wir im selben Team ältere
und jüngere Mitarbeiter vereinen. Haben wir zu viele ältere Leute im Team, könnte das zu
unnötigen Turbulenzen führen – ähnlich wie die viel zitierten vielen Köche, die den Brei
verderben. Zu viele jüngere Leute könnten andererseits bedeuten, dass das Team nicht
genügend Erfahrungen und Kenntnisse besitzt, um die Arbeit zu erledigen. Eine gute
Mischung fördert hingegen eine gesunde, der Zusammenarbeit zuträgliche Lernumge-
bung.

11.4.3 T-förmige Fertigkeiten


Flexible Entwicklungsteams bestehen aus Mitgliedern mit T-förmigen Fertigkeiten (siehe
Abbildung 11.6).
T-förmige Fertigkeiten bedeutet, dass ein Teammitglied (sagen wir »Sue«) weitreichende
Fertigkeiten in seinem bevorzugten Funktionsbereich, seiner Lieblingsdisziplin oder
seinem Fachgebiet besitzt. Sue ist z.B. eine ausgezeichnete Designerin für die User Experi-

241
Kapitel 11
Das Entwicklungsteam

ence (UX) – das ist ihr Spezialgebiet, in dem sie am liebsten arbeitet. Sie kann aber auch
außerhalb ihres Kernbereichs tätig werden und z.B. Tests durchführen oder für die Doku-
mentation sorgen. Vermutlich ist sie darin zwar nicht so gut wie jemand, der sich auf diese
Tätigkeiten spezialisiert hat, dennoch kann sie durchaus aushelfen, wenn das Team in die-
sen Bereichen einen Engpass erfährt. So gesehen, besitzt Sue breit gefächerte Fertigkeiten,
die es ihr erlauben, auch außerhalb ihres Kernbereichs zu arbeiten.

Fähigkeit, außerhalb des


Kernbereichs zu arbeiten

Funktionsbereich,
Disziplin oder Spezialgebiet

Abb. 11.6: T-förmige Fertigkeiten

Es ist unrealistisch zu glauben, dass jede Person in einem Team an jeder Aufgabe arbeiten
könnte. Das wäre ein ziemlich hochtrabendes Ziel. So wäre es in Bereichen mit einer star-
ken Spezialisierung wie beispielsweise der Videospielentwicklung, in denen ein Team
einen Grafikdesigner, einen Animator, einen Tontechniker, einen KI (Künstliche Intelli-
genz)-Programmierer und einen Tester umfassen könnte, unvernünftig anzunehmen, dass
jeder alle Aufgaben leisten kann. Wäre ich in einem Team, das ein Videospiel entwickelt,
dann könnte ich an der KI arbeiten und einige Tests durchführen, für die künstlerischen
Aspekte wäre ich jedoch definitiv nicht geeignet (das würde sich niemand wünschen!). Ich
könnte allerdings den Grafikdesignern bei einigen nicht kreativen Arbeiten helfen, etwa
beim Konvertieren von Dateiformaten mit Photoshop oder beim Anlegen von Skripten
zum Bearbeiten mehrerer Dateien.
Manager sollten sich darauf konzentrieren, Teams zusammenzustellen, in denen sich die
besten T-förmigen Fertigkeiten vereinen, die mit dem verfügbaren Personal zu bekommen
sind. Allerdings ist es manchmal nicht möglich, gleich von Anfang an die gewünschten
Teamfähigkeiten abzurufen, aber glücklicherweise können sich die Fertigkeiten im Laufe
der Produktentwicklung weiterentwickeln. Aus diesem Grund ist es wichtig, eine Umge-
bung zu schaffen, in der die Mitarbeiter kontinuierlich lernen und neue Fertigkeiten erwer-
ben können, egal, ob es sich dabei um Fachwissen, technische Kenntnisse, neue
Denkweisen oder andere Fähigkeiten handelt. Das Management muss den Teammitglie-
dern also stets auch Zeit zum Lernen und Experimentieren einräumen (siehe Kapitel 13).

242
11.4
Eigenschaften/Fertigkeiten

Aber ist es in Ordnung, reine Spezialisten im Team zu haben? Kommen wir noch einmal
auf unser Beispiel mit Sue zurück und nehmen wir an, sie sei zwar eine großartige UX-
Designerin, wäre für andere Aufgaben allerdings nur äußerst bedingt geeignet. Da wir
jedoch tatsächlich so wenige UX-Designer haben, wollen wir auch gar nicht, dass sie
etwas anderes macht als wichtige UX-Designarbeit. Wir brauchen ihre Fertigkeiten im
Team, können aber nur etwa 10% ihrer Zeit mit teambezogener Arbeit füllen. In einem
solchen Fall würde die offensichtliche Lösung darin bestehen, Sues Zeit auf mehrere
Teams aufzuteilen.
Dennoch müssen wir auch dabei realistisch bleiben. Sue wäre zweifellos völlig überfordert,
wenn sie ihre Zeit in 10%-Häppchen auf viele Teams gleichzeitig aufteilen würde – das
würde sehr schnell ein massives »Flaschenhalsproblem« nach sich ziehen (siehe den
Abschnitt »Fokussiert und verpflichtet« weiter hinten in diesem Kapitel). Rufen Sie sich
aus Kapitel 3 ins Gedächtnis zurück, dass unser Ziel nicht darin bestehen sollte, Leute wie
Sue zu 100% auszulasten. Stattdessen sollten wir uns mehr Sorgen um die unerledigte
Arbeit machen (den Staffelstab, der auf dem Boden liegt), die sich anhäuft, wenn wir uns
zu stark auf eine übermäßig beanspruchte Ressource verlassen. Deshalb würden wir Sue
lediglich einer vertretbaren Anzahl an Projekten als Spezialistin zuweisen, nicht aber gleich
so vielen, dass sie in der Endkonsequenz Verzögerungen verursachen würde.
Da unser Ziel darin besteht, einen guten Workflow für die Teammitglieder zu erreichen,
die breit gefächerte T-förmige Fertigkeiten besitzen, sollten wir Sue alternativ dazu ermun-
tern, anderen Teammitgliedern ihr Wissen auf dem Gebiet des UX-Designs zu vermitteln,
damit wir uns nicht mehr so stark auf Spezialisten verlassen müssen.
Zusammenfassend lässt sich also sagen, dass unsere Zielsetzung lautet, ein Team zu bil-
den, dessen Mitglieder die passenden Fertigkeiten besitzen, um die wichtigsten Spezialge-
biete abzudecken. Zusätzlich sollten einige Überschneidungen bei den Fertigkeiten
vorhanden sein, damit eine gewisse Flexibilität gewährleistet ist. Dazu sollten viele Team-
mitglieder T-förmige Fertigkeiten besitzen, aber natürlich brauchen wir weiterhin einige
Spezialisten in unserer Teamzusammenstellung.

11.4.4 Die Musketier-Einstellung


Die Mitglieder des Entwicklungsteams (und das Scrum-Team als Ganzes) müssen der glei-
chen Devise folgen wie die drei Musketiere: »Einer für alle und alle für einen.« Diese Mus-
ketier-Einstellung festigt das Gefühl, dass die Teammitglieder gemeinsam dafür
verantwortlich sind, die Arbeit zu schaffen – sie gewinnen als Team oder sie verlieren als
Team.
Ich wäre sehr verwundert, wenn ich in einem gut funktionierenden Scrum-Team zu hören
bekäme: »Ich bin mit meiner Arbeit fertig, aber du hast deine Arbeit nicht geschafft und
deshalb sind wir gescheitert.« Eine solche Einstellung ignoriert die Tatsache, dass alle
Teammitglieder im selben Boot sitzen (siehe Abbildung 11.7).
Die Teammitglieder müssen anerkennen, dass sie zusammenarbeiten müssen, um ihre
Verpflichtungen zu erfüllen, weil sonst am Ende alle ein Problem haben, wenn sie schei-
tern. Um gemeinsam Erfolg zu haben, braucht man Teammitglieder mit einer Musketier-
Einstellung.

243
Kapitel 11
Das Entwicklungsteam

Durch die Zusammenstellung eines Teams, dessen Mitglieder T-förmige Fertigkeiten auf-
weisen, unterstützt man diese Einstellung und setzt sie aktiv in die Praxis um, weil die ein-
zelnen Mitarbeiter in der Lage sind, mehrere verschiedene Aufgaben zu übernehmen. In
diesen Teams wird niemand, der eine Arbeit erledigen kann, sagen: »Das ist nicht mein
Job.«
Da jedoch nicht immer wirklich jedes Teammitglied so flexibel in mehreren Arbeitsberei-
chen eingesetzt werden kann, wird es schon mal den ein oder anderen geben, der sagt: »Ich
bin nicht in der Lage, diese Arbeit zu erledigen.« In diesem Fall könnte das Team beschlie-
ßen, die betreffende Person einem anderen Teammitglied zur Seite zu stellen, das die benö-
tigte Fertigkeit besitzt und ihr Wissen auf diese Weise weitervermittelt.
Doch selbst wenn die begrenzten eigenen Fertigkeiten jemanden daran hindern, funktions-
übergreifend zu arbeiten, können die Teammitglieder ihre Arbeit immer noch so organisie-
ren, dass im Laufe des Sprints ein guter Workflow erreicht und kein Teammitglied
überlastet wird. Sollten Sie hingegen z.B. die ganze Testarbeit bis zum Ende des Sprints
aufsparen, damit der »Tester« die Arbeit erledigen kann, ist ein Scheitern quasi schon vor-
programmiert. In Kapitel 20 finden Sie eine ausführlichere Diskussion zu der Frage, wie
das Team den Workflow während der Sprint-Durchführung organisieren sollte.

Bloß gut, dass das


Leck nicht auf
unserer Seite ist!

Abb. 11.7: Die Teammitglieder müssen handeln, als würden sie alle im selben Boot sitzen

Bei einer Musketier-Einstellung gibt es keine »Mitläufer«. Jedes Teammitglied trägt die Ver-
antwortung, sich jederzeit vollständig in das Team einzubringen. Oft bedeutet das auch,
dass man sich an Aktivitäten außerhalb des eigenen Spezialgebiets beteiligt und beispiels-
weise neue Sichtweisen in die projektbezogenen Diskussionen einbringt. Sollte z.B. ein
Teammitglied, das auf das Testen spezialisiert ist, der Meinung sein, ein Problem in dem
Design entdeckt zu haben, das das Team für eine künftige Funktion vorgesehen hat, ist es
seine Pflicht, diesen Punkt im Team anzusprechen, statt mit den Schultern zu zucken und
zu sagen: »Ist nicht mein Job. Außerdem kennen die sich damit sowieso besser aus als
ich.«

244
11.4
Eigenschaften/Fertigkeiten

11.4.5 Kommunikation mit hoher Bandbreite


Die Mitglieder des Entwicklungsteams müssen sowohl miteinander als auch mit dem Pro-
duct Owner und dem ScrumMaster auf eine Weise kommunizieren, dass wertvolle Infor-
mationen schnell, effizient und mit minimalem Overhead transportiert werden.
Eine Kommunikation mit hoher Bandbreite erhöht sowohl die Häufigkeit als auch die Qua-
lität der Informationsweitergabe. So hat das Scrum-Team viel öfter Gelegenheit, seine
Arbeit zu überprüfen und entsprechende Anpassungen vorzunehmen. Und das wiederum
führt zu besseren und schnelleren Entscheidungen. Da der wirtschaftliche Wert der Infor-
mationen zeitgebunden ist, kann das Team zu einer Wertsteigerung beitragen, indem es
die Frequenz des Informationsaustauschs erhöht. Durch schnelles Ausnutzen aller sich
ergebenden Gelegenheiten und Erkennen von verschwenderischen Situationen kann es
vermeiden, mehr Ressourcen aufzuwenden als nötig, weil es den falschen Weg gegangen
ist.
Es gibt eine Reihe von Methoden, mit denen ein Team eine Kommunikation mit hoher
Bandbreite erreichen kann. Das Agile Manifest (Beck et al. 2001) besagt, dass eine Kommu-
nikation von Angesicht zu Angesicht der zu bevorzugende Ansatz ist. Sicherlich sind Team-
mitglieder, die physisch voneinander getrennt sind oder vorrangig eine nicht interaktive
Kommunikation (wie etwa über Dokumente) nutzen, im Nachteil gegenüber Teams, die
zusammen an einem Ort sitzen und direkt miteinander kommunizieren.
Ich persönlich ziehe es vor, dass meine Teammitglieder am gleichen Ort arbeiten. Viele
Organisationen setzen jedoch aus den unterschiedlichsten Gründen verteilte Teams ein, so
dass eine Zusammenarbeit am gleichen Ort nicht immer möglich oder praktisch ist. Ich
selbst habe bereits viele verteilte Teams erlebt, die von den Vorteilen einer bandbreitenstar-
ken Kommunikation profitieren konnten. Insofern gilt: Das direkte Gespräch ist nicht der
einzige Weg, um dieses Ziel zu erreichen – es ist aber ein guter Ausgangspunkt, wenn es
die geschäftlichen Bedingungen zulassen.
Bei verteilten Teams kann ein bestimmtes Maß an technischer Unterstützung die Band-
breite der Kommunikation verbessern. Auch ich habe bereits mit Organisationen zusam-
mengearbeitet, deren Teammitglieder weit verstreut waren. Hier war es möglich, mithilfe
ziemlich eindrucksvoller Telefonkonferenz-Technik an Diskussionen teilzunehmen, die
sich anfühlten, als würden alle Beteiligten im selben Raum sitzen. Aber war das genauso
gut wie räumliche Nähe? Nein. Dennoch bewirken derartige moderne technische Mittel
schon eine bedeutende Verbesserung der Kommunikationsbandbreite unter den Teammit-
gliedern.
Teams mit funktionsübergreifend arbeitenden Mitgliedern sind bereits ein wichtiger
Schritt zu einer hohen Kommunikationsbandbreite. Solche Teams verfügen über geradlini-
gere Kommunikationskanäle, weil sie problemlosen Zugang zu den Mitarbeitern haben,
die erforderlich sind, um die Aufgabe zu erfüllen. Außerdem sind formelle Übergaben an
andere Teams (meist in Form schriftlicher Dokumente) in solchen funktionsübergreifen-
den Teams eher unwahrscheinlich. Wenn alle im selben Team sind, kommt es generell nur
noch selten zu formellen Übergaben, was die Kommunikationsgeschwindigkeit deutlich
erhöht.
Natürlich sollten wir darüber hinaus auch den Zeitaufwand für jegliches Zeremoniell redu-
zieren, das die Teammitglieder Prozessabläufen unterwirft, die kaum oder keinen Wert

245
Kapitel 11
Das Entwicklungsteam

schaffen. Wenn die Teammitglieder z.B. erst drei Umwege nehmen müssen, bevor sie mit
einem realen Kunden oder Anwender reden können, stellt diese Vorgehensweise für »Mit
einem Kunden sprechen« eher ein echtes Hemmnis für eine breitbandige Kommunikation
dar, weil die Bandbreite sinkt, wenn man erst sinnlose Dokumente erstellen oder langwie-
rige und potenziell unnötige Genehmigungsverfahren durchlaufen muss. Solche Hinder-
nisse gilt es zu erkennen und zu eliminieren, um die Teamkommunikation als Ganzes zu
verbessern.
Der Kommunikationsbandbreite zuträglich ist dagegen, wenn man nur kleine Teams hat.
Die Kommunikationskanäle in einem Team skalieren nicht proportional zur Anzahl der
Leute, sondern nehmen stattdessen entsprechend der Formel N(N-1)/2 quadratisch zu.
Wenn also 5 Leute im Team sind, gibt es 10 Kommunikationskanäle. Bei 10 Leuten sind es
schon 45 Kommunikationskanäle. Mehr Teammitglieder bedeuten somit einen höheren
Overhead für die Kommunikation und damit auch eine geringere Bandbreite.

11.4.6 Transparente Kommunikation


Die Kommunikation innerhalb des Teams sollte nicht nur eine hohe Bandbreite haben
(also schnell und effizient sowie mit einem minimalen Overhead erfolgen), sondern auch
transparent sein. Eine transparente Kommunikation gewährleistet ein klares Verständnis
dessen, was tatsächlich passiert. Man vermeidet Überraschungen und hilft, das Vertrauen
unter den Teammitgliedern zu steigern. Ich persönlich finde, dass Teams auf eine Weise
kommunizieren sollten, die am wenigsten Überraschungen auslöst. Beispielsweise kann
ich mich an ein Scrum-Team erinnern, in dem eine Person während der Daily Scrums ihre
Worte regelmäßig so wählte, dass nicht klar war, was sie getan hatte und was sie weiterhin
plante. Daher waren die anderen häufig überrascht (oder besser gesagt »überrumpelt«),
wenn sie später merkten, dass die Kommunikation dieser Person absichtlich schleierhaft
bleiben und zu Missverständnissen führen sollte. Andere Teammitglieder trauten ihr
schließlich nicht mehr über den Weg, was wiederum dazu führte, dass das Team in seiner
Fähigkeit zur Selbstorganisation behindert wurde und Probleme hatte, seine Sprint-Ziele
zu erreichen.

11.4.7 Die richtige Größe


Scrum bevorzugt kleine Teams. Es ist allgemein anerkannt, dass es am besten ist, wenn
fünf bis neun Leute in einem Team arbeiten. Die These, dass kleine Teams am effizientes-
ten sind, wird auch durch diverse Veröffentlichungen untermauert (Putnam 1996; Putnam
und Myers 1998). Meine eigenen Erfahrungen aus den letzten 25 Jahren haben gezeigt,
dass Teams aus fünf bis sieben Leuten die beste Größe für eine schnelle Lieferung von Wer-
ten darstellen.
Mike Cohn führt eine Reihe von Gründen für kleine Teams an, darunter (Cohn 2009):
쐽 Es wird weniger gebummelt und gefaulenzt – schließlich kann man sich nicht damit
herausreden, dass jemand anders die Arbeit schon irgendwann erledigen wird.
쐽 In einem kleinen Team besteht eine höhere Wahrscheinlichkeit für konstruktive Inter-
aktion.
쐽 Es ist weniger Zeit für Koordinationsaufgaben erforderlich.
쐽 Niemand kann im Hintergrund verschwinden.

246
11.4
Eigenschaften/Fertigkeiten

쐽 Kleine Teams sind für ihre Mitglieder befriedigender.


쐽 Es kommt seltener zu schädlicher Überspezialisierung.

Natürlich ist es auch möglich, dass ein Team zu klein ist. Dies ist beispielsweise dann der
Fall, wenn es nicht genügend Leute enthält, um die Aufgabe zu erfüllen oder effizient zu
arbeiten.
Die Bevorzugung kleiner Teams soll allerdings nicht heißen, dass wir Scrum nicht für ein
größeres Entwicklungsprojekt einsetzen könnten. Im Gegenteil: Scrum wird häufig ver-
wendet, um Produkte zu bauen, die mehr als neun Leute erfordern. Anstatt jedoch ein gro-
ßes Scrum-Team mit z.B. 36 Mitgliedern im Entwicklungsteam zu haben, würden wir vier
oder mehr Scrum-Teams einrichten, deren Entwicklungsteams jeweils aus höchstens neun
Leuten bestehen würden.
Ein Scrum-Projekt skaliert nicht durch ein größeres Entwicklungsteam, sondern durch
mehrere Scrum-Teams. Es gibt verschiedene Möglichkeiten, um mehrere Scrum-Teams
miteinander zu koordinieren. Ein verbreiteter Ansatz ist als Scrum of Scrums bekannt.
Dabei kommen Mitglieder aus den einzelnen Scrum-Teams zusammen, um ein höher
angebundenes Äquivalent eines Daily Scrum zu »zelebrieren« (mehr dazu in Kapitel 12).

11.4.8 Fokussiert und verpflichtet


Teammitglieder müssen auf das Ziel des Teams fokussiert und ihm verpflichtet sein.
Fokussiert bedeutet, dass jedes Teammitglied engagiert ist, sich konzentriert und seine
Aufmerksamkeit dem Ziel des Teams widmet. Verpflichtet bedeutet, dass jedes Teammit-
glied gewillt ist, das gemeinsame Ziel des Teams zu erreichen – egal, ob gute oder schlechte
Zeiten bevorstehen.
Wenn eine Person nur an einem Produkt arbeitet, ist es viel einfacher, fokussiert und ver-
pflichtet zu sein. Wird diese Person jedoch aufgefordert, an mehreren gleichzeitig ablau-
fenden Produktentwicklungen teilzunehmen, muss sie ihre Zeit auf diese Projekte
aufteilen und ihren Fokus sowie ihre Hingabe für die einzelnen Produkte zwangsläufig ver-
ringern.
Fragen Sie jemanden, der an mehreren Produkten arbeitet, nach seinem Fokus und seiner
Verpflichtung, und Sie bekommen vermutlich Folgendes zu hören: »Ich habe so viel zu
tun, dass ich für jedes Produkt das Beste zu geben versuche und dann zum nächsten Pro-
dukt springe. Ich habe nie das Gefühl, mich richtig auf ein Produkt konzentrieren und es
richtig machen zu können. Wenn an mehreren Produkten zur selben Zeit ein Notfall ein-
treten würde, könnte ich nicht bei allen aushelfen.«
Ein Teammitglied hat es deutlich schwerer, gute Qualität abzuliefern, wenn es ständig von
Produkt zu Produkt wechselt. Noch schwieriger ist es, sich gleichzeitig mehreren Produk-
ten verpflichtet zu fühlen. Ein solches Teammitglied sitzt nicht nur in einem Boot, sondern
hüpft ständig zwischen mehreren Booten hin und her. Aber nach welchen Kriterien soll
diese Person ihre Hilfe einbringen, wenn viele dieser Boote zur selben Zeit leck schlagen?
Wenn sie nicht zur Stelle ist, um Wasser zu schöpfen, ist sie diesem Team nicht verpflichtet
– dann ist sie im besten Fall am Team beteiligt. Und um den anderen Teammitgliedern
gegenüber fair zu sein, sollte das beteiligte Teammitglied gleich von Anfang an klarstellen,
dass es nur beteiligt ist und in kritischen Zeiten nicht unbedingt zur Verfügung steht.

247
Kapitel 11
Das Entwicklungsteam

Es gibt zahlreiche Untersuchungen, die die weithin verbreitete Annahme stützen, dass eine
Beteiligung an mehreren Produkten (oder Projekten) oder an mehreren Teams die Produk-
tivität beeinträchtigt. Abbildung 11.8 zeigt ein entsprechendes Diagramm (Wheelwright
und Clark 1992).

90%
Zeit in Prozent, in der Werte

80%
70%
geschaffen werden

60%
50%
40%
30%
20%
10%
0%
1 2 3 4 5 6
Anzahl gleichzeitiger Projekte

Abb. 11.8: Die Kosten des Multitaskings

Die in diesem Zusammenhang erhobenen Daten deuten darauf hin, dass niemand zu
100% produktiv ist – in jedem sozial verantwortlichen Unternehmen (Corporate Citizen)
gibt es einen Overhead. Allerdings scheint die Produktivität bei der Beteiligung an zwei
Projekten besser zu sein als bei einem einzelnen Projekt. Das hängt damit zusammen, dass
in Unterbrechungszeiten der Projektaktivität ein Alternativprojekt bereitsteht, zu dem die
Mitarbeiter wechseln können, so dass sie in der Summe produktiver sind.
Legt man diese Daten zugrunde, dann ist es aus wirtschaftlicher Sicht jedoch eine schlechte
Idee, an drei oder mehr Projekten gleichzeitig zu arbeiten, weil mehr Zeitaufwand erforder-
lich ist, um die Arbeit zu koordinieren, sich wieder in das betreffende Projekt hineinzufin-
den sowie Informationen einzuholen und dadurch weniger Zeit für die eigentliche Arbeit
bleibt. An wie vielen Projekten/Produkten (und möglicherweise unterschiedlichen Teams)
sollte eine Person also idealerweise gleichzeitig arbeiten? Wahrscheinlich an nicht mehr als
zwei. Ich persönlich tendiere sogar eher zu einem einzigen, denn in der heutigen vernetz-
ten und informationsgesättigten Welt mit E-Mail, Instant Messaging, Twitter, Facebook und
anderen Technologien ist »Corporate Citizenship«, also die soziale Verantwortung eines
Unternehmens, durchaus gleichbedeutend mit der Arbeit an nur einem einzigen Projekt
zu sehen!
Doch was machen wir mit unseren Spezialisten, die möglicherweise gleichzeitig mehreren
Produkten zugeordnet werden müssen? Greifen wir noch einmal auf das Beispiel von Sue
(der UX-Designerin) zurück, die zu 10% einem bestimmten Team zugeordnet war (die rest-
liche Zeit war anderen Teams gewidmet). Auch wenn wir uns wünschen würden, dass Sue
nur an einem oder zwei Produkten arbeiten müsste, ist es dennoch möglich, dass sie an
fünf Produkten gebraucht wird. Was dann? Nun, lassen Sie doch einfach den Spezialisten
selbst entscheiden, wie vielen Produkten/Projekten er seine Aufmerksamkeit gleichzeitig

248
11.4
Eigenschaften/Fertigkeiten

zuwenden kann. Wenn Sue also sagt, dass sie keine zusätzliche Arbeit mehr übernehmen
kann, dann weisen Sie sie auch keinem weiteren Produkt oder Team zu. Wahrscheinlich
wird ihre Entscheidung aus unternehmerischer Sicht problematisch sein, dennoch sollte in
einem solchen Fall eine andere Lösung für dieses Dilemma gefunden werden.
Und davon gibt es einige. Erstens: Reduzieren Sie die Anzahl Ihrer gleichzeitigen Projekte.
Meist ist das schon die richtige Lösung, denn viele Organisationen nehmen ganz einfach
von vornherein zu viele Projekte auf einmal in Angriff (siehe Kapitel 16 für eine ausführli-
chere Diskussion). Eine andere Lösung bestünde darin, mehr Spezialisten anzuheuern, um
die Arbeitslast aufzuteilen. Die dritte Lösung wäre, andere Mitarbeiter darin zu bestärken
und zu unterstützen, ihre Fertigkeiten in dem betreffenden Fachbereich zu verbessern.
Und als vierte Lösung käme natürlich auch eine Kombination aus den ersten drei Lösun-
gen infrage. Denn sollten Sie Ihre Mitarbeiter drängen, an zu vielen Projekten/in zu vielen
Teams gleichzeitig zu arbeiten, reduzieren Sie am Ende nur deren Fokus und Hingabe und
gefährden damit auch das Geschäftsergebnis.

11.4.9 In einer nachhaltigen Geschwindigkeit arbeiten


Eins der Leitprinzipien von Scrum ist, dass die Teammitglieder in einer nachhaltigen
Geschwindigkeit arbeiten sollten (keine Gewaltmärsche mehr!). Wenn sie das tun, liefern
sie erstklassige Produkte, bewahren sich aber dennoch eine gesunde und angenehme
Umgebung.
Bei einer sequenziellen Entwicklung verschieben wir wichtige Aktivitäten wie die Integra-
tion und Tests gern bis ans Ende, weil wir üblicherweise überwältigend viele andere Proble-
men lösen müssen, bevor unser Abgabetermin erreicht ist. Die Konsequenz daraus ist ein
steiler Anstieg der Intensität in den späteren Phasen (siehe Abbildung 11.9).

Scrum
Traditionell
Intensität

Zeit
Abb. 11.9: Nachhaltige Geschwindigkeit im Zeitverlauf

Diese unglaublich arbeitsintensive Zeit ist durch »Superhelden« geprägt, die nächtelang
und auch an den Wochenenden arbeiten, um den Fertigstellungstermin zu schaffen. Man-

249
Kapitel 11
Das Entwicklungsteam

che Leute blühen in solchen Situationen regelrecht auf, sie lieben die Aufmerksamkeit und
Anerkennung, die ihnen für ihre außerordentlichen Bemühungen zuteil wird. Für alle
anderen ist der Stress allerdings einfach übermächtig. Als Organisation sollten wir uns
daher fragen: »Warum mussten wir in den Nächten und an den Wochenenden arbeiten
und was sollten wir ändern?«
Vergleichen Sie diese Ausgangssituation nun einmal mit dem typischen Intensitätsprofil
beim Einsatz von Scrum, wo wir in jedem Sprint kontinuierlich Funktionen entwickeln,
testen und integrieren. In jedem Sprint sollten die Teammitglieder gute technische Verfah-
ren wie das Refactoring, fortlaufende Integration und automatisierte Tests einsetzen, damit
sie häufig und regelmäßig funktionierende Werte abliefern können, ohne sich zu überar-
beiten.
Wir werden also vermutlich innerhalb eines Sprints merken, dass die Intensität zum Ende
hin, wenn es darum geht, alle zur Erfüllung unserer starken Definition von Fertig erforder-
lichen Arbeiten abzuschließen, ein wenig ansteigt. Dennoch sollte die Gesamtintensität des
Arbeitsaufkommens während eines Sprints grundsätzlich der Intensität vorhergehender
Sprints in etwa gleichen – damit gewährleistet ist, dass das Team in einer Geschwindigkeit
arbeitet, die sich auf Dauer auch durchhalten lässt.
Auf diese Weise erreichen wir eine ausbalancierte Arbeitsbelastung, die nicht in großen
Brocken oder intensiven Spitzen über uns hereinbricht, und vor allem nicht zu einem spä-
ten Zeitpunkt, wenn das den größten Schaden anrichten würde. Eine derartige Balance
bedeutet zudem, dass das Scrum-Team vermutlich nur wenige Überstunden machen muss
und deshalb weniger Burnouts erleidet.

11.4.10 Langlebig
Der effiziente Einsatz von Scrum erfordert keine Arbeitsgruppen, sondern echte Teams.
Ein Team besteht aus einer vielseitigen, funktionsübergreifenden Ansammlung von Leu-
ten, die eine gemeinsame Vision verfolgen und zusammenarbeiten, um diese Vision zu
erreichen. Eine Arbeitsgruppe ist dagegen lediglich eine Ansammlung von Leuten, die
unter einer gemeinsamen Bezeichnung referenziert wird. Außer diesem Namen haben die
Mitglieder einer Arbeitsgruppe allerdings nicht viel gemeinsam und würden daher die Auf-
gaben, die ich für die Rolle des Entwicklungsteams beschrieben habe, nicht effizient erfül-
len.
Teamaufstellungen sollten langlebig sein. Ich halte meine Teams in der Regel so lange
zusammen, wie es sich wirtschaftlich vernünftig vertreten lässt. Und die wirtschaftlichen
Aspekte sprechen für langlebige Teams. Untersuchungen von Katz haben gezeigt, dass
langlebige Teams produktiver sind als neu gebildete Arbeitsgruppen (Katz 1982). Darüber
hinaus demonstrieren Forschungen von Staats, dass die Vertrautheit des Teams (frühere
gemeinsame Arbeitserfahrungen der Teammitglieder) die Effizienz und die Qualität der
Teamergebnisse positiv beeinflussen kann (Staats 2011). Und höhere Produktivität, Effi-
zienz und Qualität führen zu besseren Geschäftsergebnissen.
Wenn wir mit einer Arbeitsgruppe beginnen, die aus Leuten besteht, die noch nie zusam-
mengearbeitet haben, müssen wir Zeit und Geld aufwenden, um sie zu einem echten Team
zusammenzuschweißen. Die meisten Arbeitsgruppen müssen bestimmte Phasen durch-
laufen (»Forming, Storming, Norming und Performing«), bis sie zu hochfunktionalen

250
11.4
Eigenschaften/Fertigkeiten

Teams zusammenwachsen (Tuckman 1965). Wenn es aber erst einmal soweit ist, stellen sie
einen echten Gewinn für unsere Organisation dar, weil alle Mitglieder dieser Teams wissen,
wie sie zusammenarbeiten müssen und sich gegenseitiges Vertrauen verdient haben. Da-
rüber hinaus hat jedes Team wichtige historische Informationen angehäuft, wie z.B. die Ent-
wicklungsgeschwindigkeit (Velocity) und eine gemeinsame Schätz-Historie (siehe Kapitel
7). Und wenn wir ein Team auflösen oder seine Zusammensetzung ändern, dann haben
diese wertvollen, teamspezifischen historischen Informationen keinen Kontext mehr, in
dem man sie direkt einsetzen könnte.
Leider erlebe ich viel zu oft Organisationen, die den wahren Wert ihrer Teams nicht zu
schätzen wissen. Die meisten Organisationen haben eigene Systeme und Verfahren entwi-
ckelt, um ihre Mitarbeiter dynamisch zu »Teams« (eigentlich handelt es hierbei eher um
Arbeitsgruppen) zusammenzustellen. Meiner Meinung nach verkennen solche Praktiken
allerdings einen wesentlichen Aspekt von Scrum: Der wahre Wert liegt im Team. Die
Währung des agilen Arbeitens ist das Team. So lautet etwa einer der Kernwerte des Agilen
Manifests »Individuen und Interaktionen«. Mit anderen Worten: Das Team ist der wert-
vollste Aktivposten.
Wenn man Mitarbeiter von einem Team zum anderen verschiebt, zerstört man die Integri-
tät des Teams. Ich bezweifle, dass die SWAT-Spezialeinheit (Special Weapons and Tactics)
der New Yorker Polizei regelmäßig umgebaut wird. Die Mitglieder dieses speziellen Teams
haben gelernt, zusammenzuarbeiten und einander in gefährlichen Situationen zu sichern.
Und würde ihre Zusammensetzung ständig verändert werden, würden Vertrauen, Integri-
tät und Effizienz auf die Dauer Schaden nehmen. (In unserer Situation wäre ein Abfall der
Entwicklungsgeschwindigkeit die Folge, im Fall der SWAT-Einheit ein Verlust an Sicher-
heit.)
Die meisten Organisationen wären viel besser dran, wenn sie es sich zur Regel machen
würden, wenigstens das Kernteam so lange wie möglich unverändert bestehen zu lassen
und die Teams von Produkt zu Produkt zu versetzen. Es ist wirtschaftlich immer sinnvoller,
gut aufgestellte Teams im Ganzen zu versetzen als einzelne Leute.
Das soll aber nicht heißen, dass Sie Ihre Teams unter allen Umständen über einen langen
Zeitraum zusammenhalten sollten und könnten. Es kann natürlich auch vorkommen, dass
sich ein Team nicht in der von uns erhofften Form zusammenfindet oder auf andere Art
dysfunktional ist. In solchen Fällen wäre es selbstverständlich wirtschaftlich sinnvoller, das
Team aufzulösen.
So war ich beispielsweise einmal als Coach für eine Organisation tätig, in der wir ganz
bewusst ein leistungsstarkes Scrum-Team auflösten, um eine weitreichendere Integration
von Scrum innerhalb der Organisation zu unterstützen. Hier erfolgte die Auflösung nicht
etwa, weil das Team seine Arbeit beendet hatte und es Zeit war, die Mitarbeiter für das
nächste Entwicklungsprojekt neuen Teams zuzuordnen, sondern weil wir es für besser
hielten, mit den Scrum-erfahrenen Personen sechs neue Scrum-Teams zu bilden, als das
Originalteam beizubehalten.
Da Teams generell ein so wertvoller Aktivposten sind, müssen sie auch als Maßstab dafür
gelten, wie viele und welche Arten von Produktentwicklungen wir gleichzeitig durchführen
sollten. Ich werde das in Kapitel 16 ausführlicher diskutieren.

251
Kapitel 11
Das Entwicklungsteam

11.5 Abschließende Bemerkungen


In diesem Kapitel beschrieb ich die Team-Rolle. Ich betonte, dass das Team dafür verant-
wortlich ist, Product-Backlog-Elemente in potenziell auslieferbare Produktinkremente zu
verwandeln. Außerdem stellte ich die Aufgaben des Teams während der einzelnen Sprints
vor. Anschließend listete ich zehn Eigenschaften auf, die wir uns von unseren Teams wün-
schen. Insbesondere wollen wir Teammitglieder haben, die sich selbst organisieren und
funktionell vielseitig sowie ausreichend versiert sind, um die Arbeit zu erledigen. Ange-
sichts der Aufgaben, die auf das Team warten, brauchen wir eine gute Kombination aus T-
förmigen Fertigkeiten, um ein möglichst effizientes Schwarmverhalten zu erreichen. Und
wenn das Spektrum der Fertigkeiten innerhalb des Teams noch nicht ausreicht, dann wün-
schen wir uns Mitarbeiter, die daran interessiert sind, ihr Wissen und ihre Fähigkeiten aus-
zubauen.
Wir wollen außerdem Teammitglieder, die eine Musketier-Einstellung (»Einer für alle, alle
für einen«) vertreten. Teams sollten so beschaffen sein, dass eine breitbandige Kommuni-
kation möglich ist. Und wir ziehen kleinere Teams den größeren vor. Um fokussiert und
verpflichtet zu bleiben, ist es am besten, wenn die Teammitglieder nur an einer oder zwei
Entwicklungen gleichzeitig arbeiten. Langfristig gesehen, bevorzugen wir Teams, deren
Zusammensetzung über einen längeren Zeitraum hinweg unverändert bleiben kann.
Im nächsten Kapitel werde ich mich auf die verschiedenen Strukturen des Scrum-Teams
konzentrieren, die Sie nutzen können, wenn Sie Ihren Einsatz von Scrum ausweiten.

252
Kapitel 12

Die Strukturen des Scrum-Teams

Die Scrum-Teams sind die wichtigsten Eckpfeiler einer Scrum-Organisation. Wie sie struk-
turiert sind und in welcher Beziehung sie zueinander stehen, kann den Erfolg einer Orga-
nisation mit Scrum ganz beträchtlich beeinflussen. In diesem Kapitel zeige ich
unterschiedliche Möglichkeiten auf, um Scrum-Teams zu strukturieren. Beginnen werde
ich mit dem Unterschied zwischen einem Funktionsteam und einem Komponententeam.
Anschließend befasse ich mich mit der Frage, wie man mehrere zusammenwirkende
Scrum-Teams koordiniert.

12.1 Überblick
Wenn Sie ein kleines Produkt haben, dann müssen Sie sich nicht allzu viele Gedanken über
den Inhalt dieses Kapitels machen: Stellen Sie einfach ein funktionsübergreifendes Ent-
wicklungsteam auf, das die Eigenschaften besitzt, die ich in Kapitel 11 beschrieben habe,
und besetzen Sie die Rollen des ScrumMasters und des Product Owners mit geeigneten
Kandidaten. Aus Sicht des Scrum-Teams können Sie dann loslegen!
Nehmen wir jedoch einmal an, aus Ihrem einen funktionsübergreifenden Scrum-Team
wird eine leistungsstarke Maschinerie zum Abliefern von Geschäftswerten und Ihre Orga-
nisation beginnt zu wachsen. Oder Sie haben bereits eine größere Organisation und nach
der Entwicklung Ihres ersten Produkts mithilfe von Scrum wollen Sie dieses Entwicklungs-
verfahren in größerem Maßstab einsetzen. In beiden Fällen werden Sie bald die Arbeit
mehrerer Scrum-Teams koordinieren müssen, deren kombinierte Anstrengungen nötig
sind, um einen zunehmend größeren Geschäftswert abzuliefern.
Wie sollten Sie diese Teams strukturieren, damit Sie leistungsstark und gut koordiniert
sind? Ich gehe auf diese Frage ein, indem ich untersuche, ob Sie Funktions- oder Kompo-
nententeams haben sollten und mit welchen Verfahren Sie die Aktivitäten mehrerer Teams
koordinieren können.

12.2 Funktionsteams versus Komponententeams


Ein Funktionsteam ist ein funktions- und komponentenübergreifendes Team, das Endkun-
denfunktionen aus dem Product Backlog holen und fertigstellen kann. Ein Komponenten-
team dagegen konzentriert sich auf die Entwicklung einer Komponente oder eines
Subsystems, das benutzt werden kann, um nur einen Teil einer Endkundenfunktion herzu-
stellen.
In Kapitel 6 habe ich das Beispiel angeführt, dass ein GPS-Hersteller ein Team für die
»Routenplaner«-Komponente zusammenstellen könnte, um den anspruchsvollen Code zu

253
Kapitel 12
Die Strukturen des Scrum-Teams

organisieren, der mit dem Ermitteln einer Route von einem Ausgangspunkt zu einem Ziel
einhergeht. Immer wenn es Bedarf an neuen GPS-Funktionen gibt, die eine Routenpla-
nung beinhalten, würden die Routenplaner-spezifischen Teile dieser Funktionen dem für
die »Routenplaner«-Komponente zuständigen Team zur Entwicklung zugewiesen.
Komponententeams werden manchmal auch als Subsystem-Teams bezeichnet. Oft funk-
tioniert eine Community of Practice, die aus Mitarbeitern mit den gleichen Spezialkenntnis-
sen besteht (siehe Abbildung 13.4), ebenfalls wie ein Komponententeam. In diesen Teams
sind alle Mitglieder vermutlich demselben Abteilungsleiter verantwortlich und agieren als
eine gemeinsame, zentralisierte Ressource für andere Teams. Ein Beispiel könnte die zent-
ralisierte UX-Abteilung sein, die Bedienoberflächen (User Interface, UI) für andere Teams
herstellt.
Scrum bevorzugt Funktionsteams. Leider ziehen viele Organisationen Komponententeams
vor – weil man davon ausgeht, dass ein bestimmter Codebereich in einem Expertenteam,
dem man sichere und effiziente Änderungen zutraut, am besten aufgehoben wäre. In der
Regel wird unterstellt, dass Leute, die nicht mit dem Code vertraut sind, ihn versehentlich
auf unvorhergesehene Weise beschädigen könnten, so dass es naheliegender erscheint, ein
Komponententeam mit der Entwicklung des betreffenden Codes zu beauftragen und im
Namen Dritter Änderungen daran vornehmen zu lassen.
Nehmen wir einmal an, wir entwickeln ein Produkt, dessen Funktionen oft in drei Kompo-
nentenbereiche hineinspielen (siehe Abbildung 12.1).

Product Backlog

K 1 PB K 2 PB K 3 PB

Komponententeam 1 Komponententeam 2 Komponententeam 3

Komponente 1 Komponente 2 Komponente 3

Abb. 12.1: Ein Produkt und mehrere Komponententeams

In diesem Beispiel gibt es kein Funktionsteam, das an einem vollständigen Product-Back-


log-Element arbeitet. Stattdessen wird eine Funktion von der Spitze des Product Backlogs
ausgewählt und in seine Bestandteile auf Komponentenebene zerlegt (die drei Teile inner-
halb des gepunkteten Rechtecks in Abbildung 12.1). Diese Zerlegung erfolgt entweder

254
12.2
Funktionsteams versus Komponententeams

gemeinsam durch die Mitglieder des Scrum-Komponententeams, vielleicht aber auch


durch einen Softwarearchitekten.
Die einzelnen Teile der Funktion werden dann in die entsprechenden Product Backlogs der
Komponententeams gelegt (das erste Teil kommt z.B. in das Komponentenbereich-1-Pro-
duct-Backlog – in der Abbildung »K 1 PB«). Jedes Komponententeam führt vor seinem
komponentenbereichsspezifischen Backlog Scrum aus und stellt die komponentenspezifi-
schen Teile der Endkundenfunktionen her, nicht jedoch die vollständige Funktion. Mithilfe
einer Technik wie Scrum of Scrums, auf die ich in Kürze eingehen werde, integrieren die
Komponententeams ihre einzelnen Komponenten miteinander und liefern die vollständige
Kundenfunktion ab.
Wenn es nur ein Produkt gibt, von dem Anforderungen an die Komponententeams ausge-
hen, funktioniert dieses Vorgehen vermutlich sogar. Die meisten Organisationen bilden
jedoch Komponententeams für Komponentenbereiche, die in mehreren Produkten einge-
setzt werden sollen. Abbildung 12.2 zeigt, wie die Arbeit ablaufen könnte, wenn es von zwei
Produkten herrührende Anforderungen an dieselben Komponententeams gibt.
Jedes Product Backlog auf Funktionsebene enthält für den Kunden wertvolle Elemente, die
sich über mehrere Komponentenbereiche erstrecken. In Abbildung 12.2 gibt es nun also
zwei Produkte, die erfordern, dass die Komponententeams an ihren speziellen Komponen-
ten arbeiten.

Product Backlog 1

Product Backlog 2

K 1 PB K 2 PB K 3 PB

Komponententeam 1 Komponententeam 2 Komponententeam 3

Komponente 1 Komponente 2 Komponente 3

Abb. 12.2: Zwei Produkte und mehrere Komponententeams

255
Kapitel 12
Die Strukturen des Scrum-Teams

Stellen Sie sich vor, Sie seien der Product Owner eines der Komponententeams. Sie müs-
sen nun miteinander konkurrierende Anforderungen von zwei Produkten priorisieren,
während Sie sich gleichzeitig mit den anderen auf Komponentenebene arbeitenden Teams
koordinieren müssen, um sicherzustellen, dass die verschiedenen Teile zum passenden
Zeitpunkt integriert werden.
Bei zwei Produkten ist die Logistik dieses Problems vermutlich noch überschaubar. Doch
was ist, wenn die Organisation an 10 oder 15 Produkten gleichzeitig arbeitet und jedes die-
ser Produkte Teile auf Komponentenebene in die Backlogs der Komponententeams ein-
bringt? Bei dieser Größe ist die Logistik zum Ermitteln der richtigen Reihenfolge für die
Arbeit an den einzelnen Teilen innerhalb eines Komponententeam-Backlogs und die
gleichzeitige Koordination und Integration mit den anderen Komponententeams nicht
mehr zu bewältigen.
Meiner Erfahrung nach erkennen die meisten Organisationen, die Komponententeams
einsetzen, dass es ein Problem gibt, sobald die Dinge auseinanderzufallen drohen (wenn
quasi der Staffelstab zu Boden fällt). Normalerweise geht das so vonstatten: Ein Manager
fragt einen der Product Owner auf der Funktionsebene: »Wie kann es sein, dass die Kun-
denfunktion noch nicht fertig ist?« Er erhält die Antwort: »Nun ja, alle Komponententeams
bis auf eins haben die Teile abgeschlossen, die wir ihnen zugewiesen haben. Aber weil das
letzte Team noch nicht fertig ist, konnte auch die Funktion nicht abgeschlossen werden.«
Daraufhin könnte der Manager sagen: »Und wieso hat das Team den ihm zugewiesenen
Teil nicht fertiggestellt?« Und die Antwort des Product Owners könnte nun lauten: »Ich
habe gefragt und man hat mir gesagt, dass sie 15 konkurrierende Änderungsanforderungen
in ihrem Komponentenbereich hatten und aus technischen Gründen der Meinung waren,
dass es sinnvoller wäre, zuerst an den Anforderungen für die anderen Produkte zu arbei-
ten. Aber sie versprechen, unseren Teil noch zu beenden – vielleicht im nächsten Sprint.«
Das ist natürlich keine Art, seine Organisation zu betreiben. Wir können uns nie sicher
sein, wann (oder gar ob) wir eine Funktion ausliefern können – weil die Verantwortung für
die Auslieferung auf zwei oder drei Komponententeams verteilt wurde, die jeweils ganz
unterschiedliche Prioritäten haben könnten. Wenn man Komponententeams auf diese
Weise einsetzt, erhöht sich die Wahrscheinlichkeit, dass eine Funktion nicht fertig wird,
um ein Vielfaches, weil es nun mehrere Stellen gibt, an denen etwas misslingen könnte
(jedes Komponententeam), und nicht nur eine (ein einziges Funktionsteam).
Gibt es eine Lösung für dieses Problem? Nun, eine sehr gute Lösung wäre die Schaffung
eines funktionsübergreifenden Funktionsteams, das alle Fertigkeiten in sich vereint, die
notwendig sind, um an mehreren Endbenutzerfunktionen zu arbeiten und sie abzuschlie-
ßen – ohne dass man Teile an Komponententeams auslagern müsste. Doch wie steht es um
den wichtigsten Grund, aus dem die meisten Organisationen Komponententeams aufstel-
len – um sicherzustellen, dass ein vertrauenswürdiges Team im Komponentenbereich
arbeitet? Würden Funktionsteams nicht zu einer chaotischen Entwicklung und Wartung
der wiederverwendbaren Komponenten mit riesigen Mengen an technischen Schulden
führen? Nicht wenn wir ordentlich aufgestellte Funktionsteams haben, die sich mit der Zeit
die Code-Eigentümerschaft teilen und ihn gemeinsam und in vertrauenswürdiger, zuver-
lässiger Weise betreuen.
Sie erleichtern sich den Übergang zu dem Modell mit mehreren Funktionsteams, die sich
die Code-Eigentümerschaft teilen, wenn Sie die Teams so organisieren, wie in Abbildung
12.3 gezeigt.

256
12.2
Funktionsteams versus Komponententeams

Product Backlog 1
Funktionsteam 1

Komponententeam 1 Komponententeam 2 Komponententeam 3


K 1 PB K 2 PB K 3 PB

Komponente 1 Komponente 2 Komponente 3

Abb. 12.3: Funktionsteam und Komponententeams kombiniert

Mit diesem Ansatz wurde das Konzept eines Funktionsteams wieder eingeführt. Es gibt
nun ein einziges Funktionsteam, das eine Endkundenfunktion aus dem Product Backlog
holen kann. Dieses Funktionsteam ist vollständig dafür verantwortlich, die Arbeit zu erledi-
gen und die entsprechende Logistik zu organisieren.
Weiterhin sind in diesem Modell vertrauenswürdige Komponententeams zu finden, die
dabei helfen, die Integrität der einzelnen Komponentenbereiche zu bewahren. Diese Kom-
ponententeams haben auch ein Product Backlog, das üblicherweise technisch orientierte
Arbeit enthält, die im Komponentenbereich erledigt werden muss (möglicherweise Arbeit
zum Abzahlen technischer Schulden).
Wie ebenfalls in Abbildung 12.3 dargestellt, kann ein Mitglied eines Komponententeams
auch einem Funktionsteam zugewiesen werden. Diese Person trägt nun die doppelte Ver-
antwortung sowohl eines »Bestäubers« als auch eines »Ernters« (Goldberg und Rubin
1995).
In der Rolle des Bestäubers »befruchten« die Mitglieder der Komponententeams die Funk-
tionsteams mit Wissen über die Komponentenbereiche, um das Konzept der gemeinsamen
Code-Eigentümerschaft innerhalb der Funktionsteams zu unterstützen. In der Rolle des
Ernters sammeln die Mitglieder der Komponententeams Änderungen, die die Funktions-
teams innerhalb der Komponentenbereiche vornehmen müssen, und diskutieren diese
dann mit ihren Kollegen in den anderen Komponententeams, die wiederum ebenfalls
Änderungen in denselben Komponentenbereichen sammeln könnten. Durch diese Diskus-
sionen können die Mitglieder der Komponententeams für eine bessere Koordination der
Änderungen im Komponentenbereich sorgen, die nötig sind, um die Anforderungen der
verschiedenen Funktionsteams zu erfüllen. Die Mitarbeiter, die die Änderungen im Kom-
ponentenbereich vornehmen, können dies außerdem in einer kohärenten, konfliktfreien
Weise erledigen und damit die konzeptuelle Integrität der Komponentenbereiche gewähr-
leisten. Und die Mitglieder der Komponententeams haben die Möglichkeit, einander über

257
Kapitel 12
Die Strukturen des Scrum-Teams

potenzielle Wiederverwendungschancen zu unterrichten, weil alle über die Änderungen,


die in den Komponentenbereichen »geerntet« werden, Bescheid wissen.
Genau wie der Ansatz mit einem reinen Komponententeam kann aber auch dieses Vorge-
hen in einem großen Maßstab scheitern – allerdings aus anderen Gründen, die sich sogar
lösen lassen. Als ich diese Methode z.B. in einem großen Unternehmen vorstellte, sagte
man dort: »Aber unsere Funktionen können in bis zu 50 verschiedenen Systemen [Kompo-
nenten] auftauchen. Wir können doch nicht 50 Leute in ein Funktionsteam versetzen.« Es
ist natürlich tatsächlich möglich, dass eine Funktion 50 Komponenten enthält, allerdings
kommt es nur selten vor, dass alle 50 Komponenten direkt miteinander interagieren. Wir
brauchen also nicht ein Team mit 50 Leuten, sondern schaffen stattdessen mehrere »Funk-
tionsteams«, die wir um kleinere Cluster aus Komponenten herum platzieren, die in einem
höheren Maße interagieren (siehe z.B. Kapitel 13, Abbildung 13.5 und Abbildung 13.6), und
koordinieren dann die Arbeit dieser Teams mit den Techniken, die ich später in diesem
Kapitel noch beschreiben werde.
Eine andere Möglichkeit, wie der Ansatz aus Abbildung 12.3 scheitern kann, ist, wenn die
Organisation an 40 unterschiedlichen Produkten arbeitet und nur vier Teammitglieder in
einem Komponentenbereich hat. Es ist nicht sinnvoll, Mitarbeiter zehn verschiedenen
Funktionsteams gleichzeitig zuzuweisen. Dieses Problem kann man aber lösen, indem
man die Anzahl der Produkte reduziert, die zum selben Zeitpunkt entwickelt werden (siehe
Kapitel 16), mehr Mitarbeiter mit Kenntnissen im Komponentenbereich trainiert (oder ein-
stellt) und die gemeinsame Code-Eigentümerschaft fördert (das ist die langfristige Vision).
Meiner Erfahrung nach gibt es keine Lösung, die auf alle möglichen Varianten des Kon-
flikts zwischen Funktions- und Komponententeams passt. Die meisten großen und erfolg-
reichen Scrum-Organisationen verwenden ein gemischtes Modell, das hauptsächlich aus
Funktionsteams mit einem gelegentlichen Komponententeam besteht – wenn es wirt-
schaftlich sinnvoll ist, das Komponententeam als zentralisierte Ressource bereitzuhalten.
Leider bevorzugen viele Organisationen das umgekehrte Modell – hauptsächlich Kompo-
nententeams und nur gelegentlich ein Funktionsteam – und zahlen dann einen hohen
Preis in Form von Verzögerungen aufgrund häufig unterbrochener Abläufe.

12.3 Koordination mehrerer Teams


Scrum skaliert nicht, indem man zunehmend größere Entwicklungsteams aufstellt, son-
dern indem man mehrere Scrum-Teams genau der richtigen Größe hat. Allerdings haben
wir bei mehr als einem Scrum-Team das Problem, dass wir diese Teams irgendwie koordi-
nieren müssen. Zwei Techniken zum Koordinieren mehrerer Teams sind das Scrum of
Scrums und die umfassendere Form, die als Release-Train bekannt ist.

12.3.1 Scrum of Scrums


In Kapitel 2 erwähnte ich, dass das Entwicklungsteam während der Sprint-Durchführung
jeden Tag einen Daily Scrum abhält. Dabei sind nur die Mitglieder dieses Scrum-Teams
anwesend.
Um die Arbeit mehrerer Teams zu koordinieren, wird oft ein Scrum of Scrums oder SoS
abgehalten (siehe Abbildung 12.4).

258
12.3
Koordination mehrerer Teams

Scrum of Scrums

Abb. 12.4: Scrum of Scrums

Diese Praxis erlaubt es mehreren Teams, ihre Arbeiten zu koordinieren. Das Team, das das
SoS durchführt, besteht aus einzelnen Mitgliedern der verschiedenen Entwicklungsteams.
Jedes Entwicklungsteam legt selbst fest, welches Mitglied zum Scrum of Scrums geschickt
wird – am besten eignet sich derjenige, der etwas zu den Abhängigkeiten zwischen den
Teams sagen kann. Ich finde zwar eine gewisse Konsistenz bei der Repräsentation der
Teams ganz gut, gestehe aber zu, dass im Laufe der Zeit unterschiedliche Mitarbeiter zum
SoS geschickt werden können – je nachdem, wer am besten in der Lage ist, das Team zu
vertreten und über die gerade aktuellen Probleme berichten kann.
Manche Teams schicken sowohl ein Mitglied des Entwicklungsteams als auch ihren Scrum-
Master (der für zwei oder mehr Scrum-Teams zuständig sein könnte) zum SoS – wobei
gemeinsam darauf geachtet werden muss, dass die Gesamtanzahl der Teilnehmer nicht zu
groß wird. Es kann sogar sinnvoll sein, für das Scrum of Scrums einen eigenen ScrumMas-
ter zu haben. Falls eine solche Rolle existiert, könnte man sie einem ScrumMaster eines der
Teams übertragen oder einem ScrumMaster, der nicht direkt mit einem der Teams zusam-
menarbeitet.
Es gibt mehrere Vorgehensweisen, um ein Scrum of Scrums durchzuführen. Die Teilneh-
mer müssen selbst entscheiden, was für sie am besten funktioniert. Typisch ist immer, dass
das SoS nicht jeden Tag, sondern nur einige Male pro Woche bei Bedarf durchgeführt wird.
Die Teilnehmer beantworten hier ähnliche Fragen wie beim Daily Scrum:
쐽 Was hat mein Team seit dem letzten Treffen geleistet, das die anderen Team beeinflus-
sen könnte?
쐽 Was wird mein Team vor dem nächsten Treffen tun, das die anderen Teams beeinflus-
sen könnte?
쐽 Bei welchen Problemen meines Teams könnten die anderen Teams helfen?

259
Kapitel 12
Die Strukturen des Scrum-Teams

Manche Teams beschränken ihre Scrum of Scrums genau wie die Daily Scrums der einzel-
nen Teams auf maximal 15 Minuten. Und sie verschieben die Problemlösung auf die Zeit
nach dem SoS, damit nur diejenigen Teilnehmer anwesend sein müssen, deren Beteili-
gung unmittelbar für die Problemlösung erforderlich ist.
Alternativ kann man das Scrum of Scrums aber auch über die 15-minütige Zeitbegrenzung
hinaus ausdehnen: Obwohl die Teilnehmer jedes SoS mit einer 15-Minuten-Timebox zum
Beantworten der drei Fragen beginnen, wird das SoS nach den 15 Minuten fortgesetzt und
den Teilnehmern somit Gelegenheit geboten, Probleme zu besprechen.
Theoretisch kann das Scrum of Scrums auf mehrere Ebenen ausgeweitet werden. Nehmen
wir einmal an, es sind viele Teams an einer Produktentwicklung beteiligt. Typischerweise
würden sich diese Teams in Clustern im Funktionsbereich zusammenfinden. Innerhalb
eines solchen Team-Clusters kann ein traditionelles SoS dazu dienen, die Arbeit eines
Funktionsbereichs zu koordinieren. Sinnvollerweise hält man ein übergeordnetes SoS ab,
das sogenannte Scrum of Scrum of Scrums (oder einfacher: ein Scrum auf Programme-
bene), mit dem man die Arbeit zwischen den Clustern koordiniert. Dieser Ansatz kann
funktionieren, allerdings gibt es auch andere Techniken zum Koordinieren sehr vieler
Teams. Eine davon ist der Release-Train, zu dem wir als Nächstes kommen.

12.3.2 Der Release-Train


Ein Release-Train (»Release-Zug«) ist ein Ansatz zum Ausgleichen der Vision, der Planun-
gen und der Abhängigkeiten vieler Teams. Dabei ermöglicht man eine teamübergreifende
Synchronisation basierend auf einem gemeinsamen Rhythmus. Ein Release-Train konzen-
triert sich auf einen schnellen, flexiblen Workflow auf der Ebene eines umfangreicheren
Produkts.
Die Zug-Metapher soll andeuten, dass es einen öffentlichen Zeitplan dafür gibt, wann die
Funktionen »den Bahnhof verlassen«. Alle Teams, die an der Entwicklung des Produkts
beteiligt sind, müssen ihre Fracht zum vereinbarten Zeitpunkt auf dem Zug untergebracht
haben. Wie in jedem Land mit zuverlässigen Zugverbindungen fährt der Release-Train
immer pünktlich ab und wartet auf niemanden. Falls andererseits ein Team den Zug ver-
passt, muss es sich aber auch nicht grämen, da zu einem bekannten Zeitpunkt in der
Zukunft ein weiterer Zug abfahren wird.
Leffingwell definiert die Regeln für einen Release-Train folgendermaßen (Leffingwell 2011):
쐽 Es werden häufige und regelmäßige Planungs- und Release-Termine (bzw. Termine für
potenziell auslieferbare Inkremente) für die Lösung festgelegt (die Termine und die
Qualität sind fest vorgegeben, der Umfang ist variabel).
쐽 Die Teams haben gemeinsame Iterationslängen.
쐽 Es werden dazwischenliegende globale, objektive Meilensteine etabliert.
쐽 Auf der obersten oder Systemebene sowie auf den Funktions- und Komponentene-
benen wird eine kontinuierliche Integration implementiert.
쐽 Die Release-Inkremente stehen in regelmäßigen Intervallen (üblicherweise 60 bis 120
Tage) zur Voransicht für den Kunden, für die interne Begutachtung sowie für die Qua-
litätssicherung auf Systemebene zur Verfügung.
쐽 Spezielle Iterationen auf Systemebene werden benutzt (oder können benutzt werden),
um technische Schulden zu reduzieren und Zeit für besondere Validierungs- und Test-
läufe auf Release-Ebene bereitzustellen.

260
12.3
Koordination mehrerer Teams

쐽 Damit Teams auf ähnlichen Konstrukten aufbauen können, müssen im Vorfeld be-
stimmte Infrastrukturkomponenten – Schnittstellen, Systementwicklungs-Kits, ge-
meinsame Installations- und Lizenzierungsprogramme, UX-Frameworks, Daten- und
Webservices und dergleichen – eingerichtet werden.
Abbildung 12.5 zeigt einen teilweisen Release-Train, der auf Leffingwells Definition beruht.
Der Release-Train ist ein sehr umfassendes Konzept mit mehreren Detailstufen, darunter
Portfolio- und Release-Ebenen. Wie ich in Kapitel 6 erwähnte, basiert der Release-Train auf
einem Unternehmens-Backlog-Modell, das drei Ebenen von Backlogs enthält: das Portfolio-
Backlog (mit Epics, die dem Portfolio-Management gehören), das Programm-Backlog (mit
Funktionen, die dem Programmmanagement gehören) und die Team-Backlogs (mit sprint-
fähigen User Stories, die den Product Ownern gehören). Abbildung 12.5 zeigt nur die
Team-Ebene. Die Details der Planungen auf Portfolio- und Release-Ebene werden in Kapitel
16 bzw. Kapitel 18 diskutiert.
Der Train auf Team-Ebene aus Abbildung 12.5 zeigt insgesamt neun Teams in drei Funk-
tionsbereichen. Jedes Team innerhalb eines Funktionsbereichs führt seine eigenen Sprints
durch. Die Arbeit hierfür holt es sich aus dem dazugehörenden Backlog im Funktionsbe-
reich. Alle Teams innerhalb eines Funktionsbereichs koordinieren und integrieren ihre
Arbeit mit einer Technik wie etwa dem Scrum of Scrums.
Untersuchen und Anpassen

Untersuchen und Anpassen


Release-Planung

Release-Planung
Sprints

PSI/Release
PSI/Release

Team-
Ebene

Zeit

Abb. 12.5: Struktur des Release-Trains

261
Kapitel 12
Die Strukturen des Scrum-Teams

So oft es sich praktisch einrichten lässt, sollte es eine systemweite Integration und Tests
über die Funktionsbereiche hinweg geben. Manche Teams halten sich den letzten Sprint
vor der Abfahrt des Zuges für das Hardening (»Erhärten«) dessen, was in den vorherigen
Sprints entwickelt wurde, sowie für das Integrieren und Testen der Ergebnisse über die
Funktionsbereiche hinaus frei (so könnte z.B. Sprint 4 in Abbildung 12.5 ein Hardening-
Sprint sein). Mit zunehmender Verbesserung der Fertigkeiten des Teams sollte der Bedarf
an Hardening-Sprints jedoch sinken.
Die Sprints sind für alle Teams, die am Release-Train teilnehmen, gleich lang und syn-
chron. Das bedeutet, dass sie für alle Teams zum selben Zeitpunkt beginnen und enden.
Damit ist nicht nur innerhalb eines Funktionsbereichs, sondern bei allen Teams, die am
Produkt arbeiten, eine Synchronisation möglich.
Schließlich steht nach einer festen Anzahl von Sprints ein potenziell auslieferbares Inkre-
ment (Potentially Shippable Increment; PSI) zur Verfügung. Im Fall von Abbildung 12.5
sind dies vier Sprints. Wenn die Organisation weiß, dass zuverlässig zu bestimmten Zeit-
punkten Release-Punkte eintreten, kann sie ihre anderen Aktivitäten entsprechend syn-
chronisieren. Zu den Release-Punkten kann die Organisation entweder ein PSI an ihre
Kunden ausliefern (falls das unternehmerisch sinnvoll ist) oder bestätigen, dass die Arbeit
innerhalb der einzelnen Funktionsbereiche über die Bereichsgrenzen hinaus integriert und
getestet wurde und ein internes Review einleiten.
Jeder Release-Train beginnt mit einem Release-Planungstreffen, das alle Teams umfasst,
die an dem PSI arbeiten (siehe Abbildung 12.5). Das bedeutet, dass potenziell Hunderte
Leute gleichzeitig an einem gemeinsamen Planungstreffen teilnehmen. Ich muss zuge-
ben, dass dies faszinierend anzusehen ist. Hier ein Überblick über eine Planung dieser
Größe:
Erstens brauchen Sie einen großen Raum! Der Chief Product Owner (siehe Abbildung 9.13)
leitet im Normalfall diese Aktivität. Die Mitglieder der einzelnen Scrum-Teams sitzen meist
am selben Tisch oder halten sich zumindest im gleichen Bereich auf (vorzugsweise in der
Nähe einer freien Wand, an der sie ihre Artefakte aufhängen können). Scrum-Teams, die
im selben Funktionsbereich arbeiten, bleiben zusammen. Nachdem der Chief Product
Owner einen Überblick über das PSI gegeben hat, treffen sich die Teams mit den anderen
Teams aus dem Funktionsbereich. Die Product Owner aus dem Funktionsbereich geben
dann einen Überblick über ihren Funktionsbereich für den kommenden Release-Train.
Anschließend fangen die einzelnen Scrum-Teams an, ihre Sprints zu planen, indem sie
Funktionen auf die einzelnen Sprints verteilen. Diese Aktivität wird als Sprint Mapping
bezeichnet und in Kapitel 18 noch eingehender thematisiert. Da die Scrum-Teams eigent-
lich an einem Gemeinschaftsprojekt mehrerer Teams arbeiten, gibt es Abhängigkeiten zwi-
schen den Teams. Um diese Abhängigkeiten zu organisieren, kann ein Mitglied eines
Scrum-Teams zu einem beliebigen Zeitpunkt aufstehen, zu einem anderen Scrum-Team
gehen (mit einer Karteikarte oder einem Klebezettel) und dieses Team fragen, ob es wäh-
rend des kommenden Release-Trains die Arbeit fertigstellen kann, die auf die Karte
geschrieben wurde. Falls das möglich ist, kann sich das Team, das die Anfrage stellt, zu der
abhängigen Funktion verpflichten.
Während dieser Zeit können Leute, die für mehrere Teams verantwortlich sind, wie etwa
der Chief Product Owner, die Funktionsbereich-Product-Owner und gemeinsame Architek-
ten, von Tisch zu Tisch gehen, um sicherzustellen, dass der übergreifende Plan verstanden

262
12.4
Abschließende Bemerkungen

wurde. Natürlich kann ein Scrum-Team auch jederzeit fordern, dass eine dieser Personen
kommt und weiterhilft.
Sobald die Release-Train-Sprints abgeschlossen und wir am PSI-Release-Punkt (Abfahrt des
Zuges) angekommen sind, führen wir auf Release-Train-Ebene Untersuchungen und
Anpassungen durch. Die erste entsprechende Aktivität ist ein PSI-Review der kompletten
Fracht, die auf den Release-Train geladen wurde. Die zweite ist eine Retrospektive auf
Release-Train-Ebene, die sich darauf konzentriert, wie man künftige Release-Trains noch
effizienter gestalten könnte. Und dann geht es schon mit der Release-Planung für den
nächsten Release-Train weiter.

12.4 Abschließende Bemerkungen


In diesem Kapitel habe ich die verschiedenen Methoden erläutert, mit denen sich Scrum-
Teams strukturieren lassen. Ich begann mit einer Beschreibung der Funktionsteams, die
funktionsübergreifend vielseitig und ausreichend sind, um eine Endkundenfunktion aus
dem Product Backlog zu nehmen und fertigzustellen. Danach verglich ich Funktionsteams
mit Komponententeams, die in bestimmten Komponenten-, Bestands- oder Architekturbe-
reichen arbeiten, die nur einen Teil dessen repräsentieren, was in die Endkundenfunktio-
nen integriert werden muss. Als Nächstes stellte ich ein gemischtes Modell aus Funktions-
und Komponententeams vor und zeigte, wie es genutzt werden kann, um einer Organisa-
tion den Übergang in eine Ausgangslage zu erleichtern, bei der es vorwiegend Funktions-
teams gibt, die jeweils gemeinsam den Code besitzen.
Dann erklärte ich, wie man mehrere Scrum-Teams koordinieren kann. Ich begann mit
einer traditionellen Scrum-Praxis namens Scrum of Scrums und beschrieb dann ein Kon-
zept namens Release-Train, das eingesetzt werden kann, um eine große Anzahl an
Scrum-Teams zu koordinieren. Im nächsten Kapitel werde ich mich von den traditionel-
len Rollen des Scrum-Teams lösen und die Rolle der Manager in einer Scrum-Organisa-
tion diskutieren.

263
Kapitel 13

Manager
Gibt es in einer Welt, in der sich die Teams selbst organisieren, noch Platz für Manager?
Auf jeden Fall. Auch wenn diese Rolle nicht unmittelbar im Scrum-Framework vorgesehen
ist, ist der Manager trotzdem ein wichtiger Bestandteil einer agilen Organisation. Immer-
hin finden sich auch eine Menge »Nicht-Scrum-Rollen« in den Organisationen, die durch-
aus für deren Betrieb entscheidend sind. (Beispiel: Der Lohnbuchhalter ist ebenfalls keine
Scrum-Rolle, allerdings habe ich auch noch kein Scrum-Teammitglied kennengelernt, das
nicht bezahlt werden wollte!)
In diesem Kapitel gehe ich zunächst auf die Aufgaben von Managern verschiedener Funk-
tionsbereiche (auch Ressourcenmanager genannt) in einer Scrum-Organisation ein – wie
beispielsweise Entwicklungs- und Qualitätssicherungsmanager, Art Directors etc. – und
erläutere anschließend die Projektmanager-Rolle innerhalb einer Scrum-Organisation.
Die Informationen in diesem Kapitel sind in erster Linie für Organisationen interessant, in
denen es Abteilungsleiter und Projektmanager gibt. Sollte Ihre Organisation vergleichs-
weise klein sein und nur wenige Manager beschäftigen, können Sie die folgenden Seiten
auf Wunsch überspringen – andererseits werden Ihnen hier aber auch einige grundle-
gende Erkenntnisse vermittelt, die Ihnen später, wenn Ihre Organisation gewachsen ist,
zweifelsohne von Nutzen sein können.

13.1 Überblick
Laut einer Branchenumfrage aus dem Jahr 2011 stellt die Furcht vor dem Verlust der
Managementkontrolle das größte Hindernis beim Übergang zu Scrum dar (siehe Abbil-
dung 13.1, aus Version-One 2011).

Verlust der Managementkontrolle 33%


Mangelnde Vorabplanung 33%
Management ist gegen Änderungen