Anmerkung zu Terminologie und Inhalt dieser Arbeit:

Für die bessere Lesbarkeit der Arbeit wird auf Geschlechtertrennung in dieser Arbeit verzichtet. Im Folgenden werden Berufsbezeichnungen und beide Geschlechter umfassende Personengruppen mit dem im Duden aufgeführten Artikel in der Einzahl beschrieben. In allen Fällen sind damit die männlichen, sowie die weiblichen Personen gemeint. Die in dieser Arbeit verwendeten Abkürzungen sind die durch den Duden standardisierten Abkürzungen. Eigene Abkürzungen in dieser Arbeit werden nach der ersten Erwähnung in voller Schreibweise in nachfolgenden Klammern eingeführt. Fachterminologie wird in die deutsche Sprache übersetzt, soweit eine in der Literatur anerkannte Übersetzung existiert. Falls diese nicht existiert wird der original Terminus ver- wendet.

Inhaltsverzeichnis

  Inhaltsverzeichnis  

  Abbildungsverzeichnis  III

  Abkürzungsverzeichnis  IV

1  Einleitung  5

1.1  Problemstellung.  6

1.2  Motivation und Zielsetzung  7

1.3  Methodisches Vorgehen bei der Erstellung des Modells  7

2  Theoretische Grundlagen  9

2.1  Traditionelle Vorgehensmodelle zur Software-Entwicklung  9

2.2  Agile Vorgehensmodelle zur Software-Entwicklung  10

2.3  Agiles Management-Framework Scrum  10

2.3.1  Sprint Planning  13

2.3.2  Sprint Run  14

2.3.3  Sprint Review.  16

2.3.4  Sprint Retrospektive  17

2.4  Organisationsstrukturen in Unternehmen  18

2.5  Change Management  24

3  Das Enterprise Transition Model von Schwaber  25

4  Selektion eines Change Management Modells als Basis zur  

  Integration des Enterprise Transition Model von Schwaber  28

4.1  Der Drei-Phasen-Ansatz von Lewin  28

4.2  Das 3W-Modell nach Krüger  29

4.3  Eight-Stage Process von Kotter  30

4.4  Die Modelle im Vergleich  36

5  Das integrative Vorgehensmodell  38

5.1  Phase 1: Wandlungsbedarf analysieren und  

  Wandlungsbereitschaft initialisieren  40

5.2  Phase 2: Transitionsteam gründen  42

5.3  Phase 3: Umsetzungsweg entwickeln und  

  Umsetzungsteams besetzen  44

5.4  Phase 4: Wandlungsfähigkeit herstellen und  

  Transparenz erhöhen.  51

5.5  Phase 5: Wandlungsbedarf umsetzen  54

5.6  Phase 6: Wandlungsqualität sichern und  

  Wandlungsgeschwindigkeit erhöhen  55

I

Inhaltsverzeichnis

5.7  Phase 7: Organisationsstruktur anpassen und Kultur verankern  58

6  Schlussbetrachtung  67

6.1  Ergebnisbetrachtung  67

6.2  Kritische Würdigung  67

6.3  Ausblick  68

7  Quellenverzeichnis  70

II

  Abbildungsverzeichnis  

  Abbildungsverzeichnis  

  Abbildung 1: Integration des Scrum Transition Process in ein  

  Veränderungsmanagement-Modell  

  Abbildung 2: Envisioning und Sprintphasen in Scrum  

  Abbildung 3: Detailausschnitt der Phase: Sprint Planning  

  Abbildung 4: Detailausschnitt der Phase: Sprint Run  

  Abbildung 5: Detailausschnitt der Phase: Sprint Review  

  Abbildung 6: Detailausschnitt Sprint Retrospective  

  Abbildung 7: Formen der Primärorganisation  

  Abbildung 8: Beispiel einer einfachen funktionalen Organisationsstruktur  

  Abbildung 9: Beispiel einer divisionalen Organisationsstruktur.  

  Abbildung 10: Beispiel einer einfachen Matrixorganisationsstruktur  

  Abbildung 11: Beispiel einer Projekthierarchie  

  Abbildung 12: Prozess und Prozesskette  

  Abbildung 13: Prozessmanagement als Primär- und Sekundärorganisation  

  Abbildung 14: Enterprise Transition Project Organization  

  Abbildung 15: Scrum Rollout Process  

  Abbildung 16: Der modellierte Scrum Adaption Process nach Schwaber  

  Abbildung 17: Die fünf Phasen des 3W-Modells  

  Abbildung 18: Modellierung des Eight-Stage Process  

  Abbildung 19: Beispielphase  

  Abbildung 20: Beispielaktivität  

  Abbildung 21: Gesamtmodellausschnitt mit Fokus auf Phase 1  

  Abbildung 22: Detailansicht Phase 1  

  Abbildung 23: Gesamtmodellausschnitt mit Fokus auf Phase 2  

  Abbildung 24: Detailansicht Phase 2  

  Abbildung 25: Stellenbesetzung des Transitionsteams  

  Abbildung 26: Gesamtmodellausschnitt mit Fokus auf Phase 3  

  Abbildung 27: Detailansicht Phase 3  

  Abbildung 28: Entscheidungsbaum zur Ableitung der Strategie  

  Abbildung 29: Prozess zur Realisierung des Wandlungsbedarfs  

  Abbildung 30: Darstellung von beispielhaften Scrum Rollout Teams  

  Abbildung 31: Gesamtmodellausschnitt mit Fokus auf Phase 4  

  Abbildung 32: Detailansicht Phase 4  

  Abbildung 33: Gesamtmodellausschnitt mit Fokus auf Phase 5  

  Abbildung 34: Gesamtmodellausschnitt mit Fokus auf Phase 6  

III

  Abkürzungsverzeichnis  

  Abbildung 35: Detailansicht Phase 6  55

  Abbildung 36: Gesamtmodellausschnitt mit Fokus auf Phase 7  58

  Abbildung 37: Detailansicht Phase 7  58

  Abbildung 38: Beispielausschnitt einer funktionalen Organisationsstruktur  

  mit Abbildung eines virtuellen Teams  60

  Abbildung 39: Beispielausschnitt einer divisionalen Organisationsstruktur  

  mit konsequenter Ausrichtung nach Scrum  61

  Abbildung 40: Beispielhafte Hierarchisierung von Product Ownern in der  

  Linienorganisation  62

  Abbildung 41: Von der Unternehmensvision zur Produktanforderung  63

  Abbildung 42: Beispielausschnitt einer Matrixorganisation mit Ausrichtung  

  nach Scrum  64

  Abbildung 43: Gegenüberstellung der Unterschiede zwischen Scrum und  

  einer prozessorientierten Organisation  65

  Abkürzungsverzeichnis  

  BPMN Business Process Modeling Notation  

  eEPK Erweiterte Ereignisgesteuerte Prozesskette  

  ETC Enterprise Transition Team  

  TPB Enterprise Transition Product Backlog  

IV

1 Einleitung

Seit etlichen Jahren schon analysieren Wissenschaftler sowie Praktiker zugleich, wie es gelingen kann IT-Projekte so erfolgreich und effizient wie möglich abzuwickeln. Als Erfolg wird dabei ein Projekt gewertet, welches seine geplanten Projektziele innerhalb seines zuvor definierten Zeit- und Kostenrahmes erfüllt. Die ‚Standish Group’ hat seit 1994 schon mehr als 50.000 beendete IT-Projekte bzgl. ihrer Resultate beobachtet und statistisch erfasst. Davon wurden lediglich 32% aller durchgeführten und von der Standish Group registrierten Projekte in ihrem ‚Chaos Report 2009‘ als erfolgreich gewertet. Der Erfolg von Projekten ist also auch heute noch keine Selbstverständlichkeit, sondern ¹ eher eine Ausnahme.

Die Untersuchungen des US amerikanischen Unternehmens belegen, dass die Softwarekrise der 1960er Jahre auch weiterhin nicht überstanden ist. Der damalige Ansatz, Software nach den Regeln der traditionellen Ingenieursdisziplinen zu entwickeln, führte zwar zu vielen ausgefeilten Vorgehensmodellen der Softwareentwicklung, jedoch nicht zum erhofften Erfolg.

Einen völlig anderen Ansatz bietet hierbei die ‚Agile Softwareentwicklung’, deren Fundament das agile Manifest bildet, welches sich durch folgende Prinzipien darstellen lässt:

“Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation ² Responding to change over following a plan”

Diese Wertebasis wurde im Jahre 2001 von insgesamt 18 Autoren verfasst, ohne dabei jedoch in der Konsequenz weiterführende Methoden, Werkzeuge oder Rollen zu definieren, so dass sich in den Folgejahren verschiedene agile Vorgehensmodelle entwickelten. Eine der bekanntesten agilen Vorgehensmodelle ist ‚Scrum‘. Die vorliegende Diplomarbeit zeigt die Herausforderungen, die Großunternehmen bei einer unternehmensweiten Einführung von Scrum derzeit haben und soll durch ein eigens entwickeltes Vorgehensmodell, eine zielgerechte Risikominimierung des Scheiterns anbieten.

¹ vgl. Standish Group, CHAOS Summary Report 2009, Zugriff: 06.12.2010

² vgl. Beck, Kent et al., Manifesto for agile Software Development, Zugriff: 10.12.2010

1.1 Problemstellung

Der Übergang zu Scrum ist schwieriger als es viele Unternehmen vermuten und wird

³ Dies könnte vor allem daran liegen, dass das Regel- demzufolge häufig unterschätzt.

werk im Vergleich zu schwergewichtigen Prozessen zwar einfach zu erlernen ist, jedoch kaum Aussagen zur konkreten Implementierung in Unternehmen getroffen werden können.

Die notwendigen Änderungen zum Ausschöpfen des umfassenden Potentials welches Scrum zweifelsohne bietet, sind sehr weitreichend und verlangen nicht nur von der jeweiligen Entwicklungsabteilung tiefgreifende Verhaltensänderungen, sondern fordern auch von fast allen anderen Mitarbeitern eine Umstellung in ihren Denkmustern und Gewohnheiten.

Allein die Tatsache, dass Scrum selbstgesteuerte Teams voraussetzt, verlangt von Führungskräften ein massives Umdenken ihrer eigenen Führungsrolle und ihres Führungsverhaltens. Die typischen Managementaufgaben wie planen, koordinieren und kontrollieren werden beim Einsatz von Scrum nicht mehr durch einen sonst üblichen Linien-Manager oder Projektleiter durchgeführt, sondern durch das Team selbst übernommen. Aber das Team muss sich ebenfalls den Herausforderungen stellen, seine Arbeit selbständig teamintern zu managen und letztlich für seine Arbeitsergebnisse auch die Verantwortung übernehmen.

Der organisatorische Wandel von traditionellen Vorgehensweisen im Bereich des Software-Engineering hin zu Scrum und die damit notwendigen Änderungen von Gewohnheiten und Arbeitsweisen werden höchstwahrscheinlich bei vielen Mitarbeitern auf Widerstand stoßen.

Für den Erfolg eines solchen Änderungsvorhabens ist der Umgang mit Widerständendiese rechtzeitig zu erkennen und richtig zu beantworten - von entscheidender Bedeutung. Schafft man es nämlich in dem Zuge nicht, mit den Widerständen konstruktiv ⁴ umzugehen, so ist das gesamte Änderungsvorhaben gefährdet. Der Scrum Miterfinder Ken Schwaber hat in seinem Werk ‚The Enteprise and Scrum‘ auf wenigen Seiten dargestellt, wie Scrum in Unternehmen eingeführt werden kann, allerdings keinen Ansatz mitgeliefert, wie die notwendige Umstellung der möglicherweise ⁵ problematischen Denkhaltungen stattfinden und sinnvoll verankert werden soll.

³ vgl. Cohn, Mike, Agile Softwareentwicklung, 1. Auflage 2010, Addison-Wesley, S. 31

⁴ vgl. Doppler, Klaus et al., Change Management, 11. Auflage 2005, Campus Verlag, S. 324

⁵ vgl. Schwaber, Ken, Scrum im Unternehmen, 1. Auflage 2008, Microsoft Press Deutschland, S. 9-19

Auf der anderen Seite existieren sehr wohl verschiedene Transformationsmodelle, um kulturelle Änderungen im Unternehmen zu implementieren und durchzuführen. Ein integratives Vorgehensmodell, welches beide Aspekte berücksichtigt, existiert jedoch aktuell nicht.

1.2 Motivation und Zielsetzung

Aktuell existiert kein integratives Vorgehensmodell, welches eine Einführung von Scrum

in Großunternehmen beschreibt und zeitgleich einen organisatorischen Wandel berück- sichtigt, so dass hier Nachholbedarf besteht. Da bislang 70-80% aller Änderungsvorha- ben ihr Ziel verfehlen, ist das Ziel der vorliegenden Diplomarbeit, ein integratives Vor- gehensmodell zu entwickeln, wodurch das Risiko eines Scheiterns signifikant minimiert ⁶ werden kann.

Dieses Modell soll Aufschluss über die Aktivitäten bei der Einführung von Scrum, deren zeitliche Abfolge und die Art und Weise der Ausführung geben. Zudem sollen die Artefakte, die während des Änderungsvorhabens entstehen, beschrieben werden. Das zu definierende Vorgehensmodell soll speziell für Großunternehmen >= 1000 Mitarbeiter zugeschnitten sein, welche ihren Hauptumsatz durch Softwareentwicklung generieren.

1.3 Methodisches Vorgehen bei der Erstellung des Modells ⁷ ist ein häufig zitierter Spruch des Autors Peter „Culture eats strategy for breakfast“

Drucker. Glaubt man seiner These und möchte man ein Modell in ein Anderes integrieren, so kann es nur richtig sein, das strategische Modell in das Kulturändernde einzubetten und nicht umgekehrt.

Dazu werden zuerst verschiedene Veränderungsmanagement-Modelle analysiert und hinsichtlich ihrer Anwendbarkeit für das eigens zu entwickelnde Modell verglichen. Wird ein passendes Modell gefunden, so wird dieses speziell auf die Einführung von Scrum in Großunternehmen angepasst und der von Schwaber beschriebene ‚Scrum ⁸ darin integriert, so dass beide Modelle ineinander greifen. Transition Process‘

⁶ vgl. Vahs, Dietmar, Organisation, 7. Auflage 2009, Schäffer Pöschel, S. 394

⁷ Wright, Patrick M., The Chief HR Officer: Defining the New Role of Human Resource Leaders, 1.

Auflage 2011, John Wiley & Sons, S. 215

⁸ vgl. Schwaber, Ken, The Enterprise and Scrum, 1. Auflage 2007, Microsoft Press, S. 13-15

7

Veränderungsmanagement-Modell

Abbildung 1: Integration des Scrum Transition Process in ein Veränderungsma- nagement-Modell Quelle: Eigene Abbildung

Die Prozessmodellierung soll mit Hilfe der standardisierten, grafischen Spezifikationssprache für Geschäftsprozesse und Arbeitsabläufe ‚Business Process Modeling Notati- ⁹ on’ (BPMN) erfolgen.

⁹ vgl. Object Management Group, Business Process Modeling Notation V 1.1, Zugriff: 27.04.2011

2 Theoretische Grundlagen

Um die nachfolgenden Abhandlungen und Untersuchungen bzgl. der Einführung von Scrum in Großunternehmen in Gänze nachvollziehen zu können, sind zunächst die in diesem Zusammenhang relevanten und bedeutsamsten wissenschaftstheoretischen Grundlagen erklärungs- und erläuterungsbedürftig. Zu diesem Zweck sollen sie nun im folgenden Abschnitt grundlegend skizzierend erörtert werden.

Um die grundsätzlichen Unterschiede zwischen traditionellen und agilen Vorgehensmodellen zur Software-Entwicklung zu verstehen, werden die Charakteristika beider Typen vorgestellt. Da Scrum das konkrete Vorgehensmodell ist, welches in Unternehmen eingeführt werden soll und auch die Kernkomponente des zu integrierenden Scrum Transition Process von Schwaber bildet, wird der gesamte Scrum-Prozess mit seinen Rollen, Artefakten und Meetings skizziert. Eine konsequente Einführung von Scrum, bei der das gesamte Potential ausgeschöpft werden soll, bedeutet für Mitarbeiter die Veränderung Ihrer Einstellungen und für Unternehmen die Veränderung ihrer Organisationsstruktur. Um diesen organisatorischen Wandel zu begleiten und zu unterstützen wird die Managementdisziplin Change Management angewendet und deren Ziele und Inhalte kurz umrissen. Zur Darstellung, wie Scrum in eine bestehende primäre Organisationsstruktur implementiert werden kann und welche Auswirkungen auftreten könnten, werden die Unterschiede der in der Literatur befindlichen Primärorganisationsstrukturen vorab erklärt.

Damit wären die wesentlichen, für diese Arbeit relevanten Theoriekonzepte angeführt, die im Zusammenhang mit der Einführung von Scrum von Bedeutung sind.

2.1 Traditionelle Vorgehensmodelle zur Software-Entwicklung

Ein Vorgehensmodell in der Software-Entwicklung ist allgemein definiert als „(…)eine ¹⁰ abstrakte Darstellung(…)“ , von „(…) Tätigkeiten, die zur Produktion eines Software- ¹¹ undkann nach verschiedenen Gesichtspunkten klassifiziert werproduktes führen.“

den. Eine Möglichkeit ist die Differenzierung nach traditionell und agil.

Traditionelle Vorgehensmodelle basieren auf ingenieursmäßigem Vorgehen und sind dadurch charakterisiert, dass sie sehr genaue Vorgaben machen, auf welche Art und Weise ein definiertes Artefakt innerhalb einer vorgegebenen Phase zu erzeugen ist. Sie implizieren, dass Anforderungen an das zu erstellende Software-Produkt vor dessen

¹⁰ Sommervielle, Ian, Software Engineering, 8. Auflage 2007, Pearson Studium, S. 95

¹¹ Sommervielle, Ian, Software Engineering, 8. Auflage 2007, Pearson Studium, S. 94

9

Realisierung umfassend spezifiziert sind und sich im Produkterstellungsverlauf nicht mehr ändern, da die Änderungskosten mit jeder weiteren Phase nahezu exponentiell ¹² Die Phasen werden in der Regel sequentiell durchlaufen und erst vollständig steigen.

abgeschlossen, bevor eine nächste Phase startet. Weit verbreitete Modelle, mit denen große Software-Entwicklungsprojekte durchgeführt werden und daher bei Großunternehmen häufig Anwendung finden, sind das Wasserfallmodell, der IBM Rational Unified Process und das V-Modell XT.

2.2 Agile Vorgehensmodelle zur Software-Entwicklung

Agile Vorgehensmodelle basieren auf den Prinzipien des agilen Manifests und unterscheiden sich von traditionellen Modellen im Wesentlichen dadurch, dass nur ein Minimum an Regelwerk und Rollen existiert, so dass die Art und Weise der Ausführung den ¹³ Ein weiteres Wesensmerkmal ist die inkrementelle Vorgehenswei-Individuen obliegt.

se, die beinhaltet, dass die Phasen Analyse, Spezifikation, Realisierung und Test nicht einmalig durchgeführt, sondern ständig für jede Iteration wiederholt werden. Dadurch wird ermöglicht, dass nicht alle Systemanforderungen bereits vor einer ersten Realisierung vorliegen müssen, sondern nur so viele, wie sich innerhalb eines definierten Zeitfensters auch in lauffähige Software umsetzen lassen. Während die inkrementelle Vorgehensweise auch in klassischen Vorgehensmodellen angewandt werden kann und eine Strategie bei der Systemintegration beschreibt, ein vordefiniertes Ziel in Teiletappen zu erreichen, beinhalten Agile Vorgehensmodelle auch noch die iterative Vorgehensweise, bei der sich das entstehende Softwareprodukt, durch sukzessive Verfeinerung und ständige Änderung, den Zielen und Wünschen des Auftraggebers annähern soll.

2.3 Agiles Management-Framework Scrum

Scrum wurde im Jahre 2001 von Jeff Sutherland, Ken Schwaber und Mike Beedle entwickelt und lässt sich als agiles Management-Framework beschreiben, um Software in- ¹⁴ Abgeleitetvon den Prinzipien des „agikrementell und iterativ entwickeln zu können.

¹⁵ und inspiriert von einem Artikel in der Harvard Business Review: „The len Manifests“

¹² vgl. Helmke, Hartmut et al., Einführung in die Software-Entwicklung: Vom Programmieren zur

erfolgreichen Software-Projektarbeit, 1. Auflage 2007, Hanser Fachbuchverlag, S. 175

¹³ vgl. Schneider, Uwe et al., Taschenbuch der Informatik, 6. Auflage 2007, Hanser Fachbuch, S. 231

¹⁴ vgl. Pichler, Roman, Scrum, 1. Auflage 2008, dpunkt.Verlag, S.1

¹⁵ vgl. Beck, Kent et al., Manifesto for agile Software Development, Zugriff: 10.12.2010

¹⁶ haben die Autoren eine Anleitung zur Soft-New New Product Development Game“

ware-Entwicklung verfasst, die im Gegensatz zu schwergewichtigen Prozessen zwar eine Grundstruktur mit Rollen, Artefakten und Meetings beinhaltet, jedoch keine detaillierte Beschreibung zur Art und Weise der Entwicklung vorgibt. Diese wird vom Entwicklungsteam selbst auf empirischer Basis erarbeitet.

Folgende Rollen finden in jedem Scrum-Projekt Anwendung:

Product Owner

Er repräsentiert den Kunden bzw. den Auftraggeber der zu erstellenden Software und erfasst dessen Bedürfnisse. Er ist verantwortlich für den Produkterfolg und erstellt und priorisiert kontinuierlich ein Prodcuct Backlog, welches ein aus User Stories bestehender Anforderungskatalog umfasst. Eine User Story ist eine Anforderung, die aus Kundenperspektive formuliert und mit Akzeptanzkriterien versehen wird, anhand dessen der Fertigstellungsgrad der zu entwickelnden Software erkannt werden kann.

Entwicklungsteam

Das Entwicklungsteam besteht aus allen Personen, die aktiv an der Gestaltung der Software beteiligt sind. Dazu zählen aber mindestens Entwickler und Tester, es können aber auch weitere Personen wie z.B. Systemarchitekten oder Designer einbezogen werden. Aufgabe des Teams ist die Umsetzung der im Product Backlog abgebildeten User Stories zu einem vereinbarten Zeitpunkt. Eine Besonderheit des Teams ist, dass es selbstgesteuert arbeitet und innerhalb des Projektrahmens keinem Projektleiter oder sonstigen Führungskräften fachlich unterstellt ist.

Scrum Master

Der Scrum Master ist verantwortlich für die Einhaltung des leichtgewichtigen Scrum-Regelwerks, moderiert alle Meetings und hilft dem Team beim Lernprozess und der Selbstorganisation. Er hat keine direkte Weisungsbefugnis und sollte möglichst keine weitere Rolle innerhalb des Teams einnehmen.

Ein Scrum-Projekt startet mit der Envisioning-Phase, in welcher der Product Owner eine Produktvision erstellt. Damit ist ein Dokument gemeint, welches Aufschluss über

¹⁶ vgl. Takeuchi, Hirotaka et al., The New New Product Development Game, 1. Auflage 1986, Harvard

Business Review

11

die strategische Ausrichtung des Produktes gibt. Außerdem werden darin die Zielgruppe(n), der Wettbewerbsstand und der potentiell zu erwartende Umsatz beschrieben. Abgeleitet aus der Produktvision entsteht das initiale Product Backlog, dem mindestens so viele User Stories hinzufügt werden, dass das Produkt nach dessen Umsetzung einen Mehrwert für den Kunden bereitstellen würde und somit vermarktbar wäre. Anschließend beginnt die erste Iteration, die Sprint genannt wird und deren Länge je nachdem meist zwischen 2-4 Wochen beträgt. Jeder Sprint besteht aus vier sequenziell, nach glei- ¹⁷ chem Muster ablaufenden Phasen.

Abbildung 2: Envisioning und Sprintphasen in Scrum Quelle: Eigene Abbildung

In der Phase Sprint Planning entscheidet das Entwicklungsteam, welche User Stories es umsetzen möchte. Die Realisierung geschieht im sogenannten Sprint Run. Während die- ser Zeit sind die Anforderungen stabil und dürfen nicht verändert werden. Nach Ab- schluss der Realisierung erfolgt das Sprint Review, in dem die umgesetzten User Stories dem Product Owner als fertige Software demonstriert werden und dieser gleichzeitig die Möglichkeit bekommt, die fertige Software zu akzeptieren oder Teile abzulehnen. Die Sprintphase wird durch das Meeting Sprint Retrospective abgeschlossen. Hierbei be- trachtet das Team zusammen mit dem Scrum Master die letzten drei Phasen rückwir- kend und diskutiert gemeinsam, inwieweit dieser Prozess zu Zufriedenheit von Statten ging und/oder ob der Ablauf bzw. die einzelnen Arbeitsschritten als verbesserungswür- dig erscheinen. Anschließend beginnt die nächste Sprintiteration. Die vier Phasen wer- den in den folgenden Kapiteln noch genauer zu betrachten sein.

¹⁷ vgl. Pichler, Roman, Scrum, 1. Auflage 2008, dpunkt.Verlag, S.57-62

12

2.3.1 Sprint Planning

Abbildung 3: Detailausschnitt der Phase: Sprint Planning Quelle: Eigene Abbildung

Nachdem der Product Owner das Product Backlog mit ausreichend User Stories gefüllt und in ihrer Signifikanz absteigend priorisiert hat, ruft der Scrum Master ein Sprint Planning Meeting ein, welches auch von ihm moderiert wird. In der ersten Hälfte des Meetings präsentiert der Product Owner dem Entwicklungsteam seine am höchsten priorisierten User Stories und beantwortet die Fragen des Entwicklungsteams. Das Entwicklungsteam schätzt den jeweiligen Aufwand der einzelnen User Stories und legt fest, welche User Stories es bis zum Ende der nächsten Phase, dem Sprint Run, umsetzen möchte. Die umzusetzenden User Stories werden dann vom Entwicklungsteam in einem Sprint Backlog festgehalten. In der zweiten Hälfte des Meetings verlässt der Product Owner den Raum, während das Entwicklungsteam aus den User Stories konkrete Aufgaben ableitet und auf seine Mitglieder verteilt.

13