Einführungshandbuch SCRUM

Aus Winfwiki

Wechseln zu: Navigation, Suche

Fallstudienarbeit

Hochschule: Hochschule für Oekonomie & Management
Standort: Düsseldorf
Studiengang: Bachelor Wirtschaftsinformatik
Veranstaltung: Fallstudie / Wissenschaftliches Arbeiten
Betreuer: Prof._Dr._Uwe_Kern
Typ: Fallstudienarbeit
Themengebiet: Agile Softwareentwicklung
Autor(en): Carolin Weber, Jennifer Werner, Björn Wählen
Studienzeitmodell: Tagesstudium
Semesterbezeichnung: SS11
Studiensemester: 2
Bearbeitungsstatus: begutachtet
Prüfungstermin:
Abgabetermin:


Namen der Autoren: Jennifer Werner, Björn Wählen, Carolin Weber
Titel der Arbeit: "Einführungshandbuch Scrum"
Hochschule und Studienort: FOM Düsseldorf


Inhaltsverzeichnis

1 Einleitung

Scrum ist ein kundenorientiertes, iteratives Vorgehensmodell zur Entwicklung von Software. Scrum versucht, die Prinzipien agiler Softwareentwicklung in der Praxis anzuwenden. Das Framework Scrum besteht aus vordefinierten Tools und Prozessen, die nach klar definierten Schemata angewendet werden. Durch seinen Aufbau sorgt Scrum für Effizienz und Transparenz der Entwicklung. Der entscheidende Vorteil gegenüber etablierten Vorgehensmodellen ist dabei, dass am Ende jedes Intervalls potentiell einsetzbare Software an den Kunden geliefert werden kann.

„Another change that Scrum engenders can be best described by thinking of how a house is built. The buyer of the house cannot move into the house until the entire house is completed. Suppose that there were an incremental, iterative approach for home construction. Suppose that using this approach, houses were built room by room. The plumbing, electrical and infrastructure would be built in the first room and then extended to each room as it was constructed. Buyers could move in as soon as they had decided that enough rooms had been completed. Then additional rooms could be constructed depending on the needs of the buyer.”[1]

Ausgehend davon ist Scrum nicht nur für Unternehmen interessant, die sich effizientere Projekte wünschen. Vor allem Kunden profitieren von Scrum. Da die starren Gebilde von Pflichten- und Lastenheft in Scrum nicht existieren, hat der Kunde mehr Möglichkeiten, die entstehende Software durch Anforderungen zu beeinflussen. Der Kunde wird von Anfang an indirekt durch den Product Owner vertreten. Meetings am Ende eines Intervalls, des sog. "Sprints" erlauben es dem Kunden, Teile des fertigen Produktes live zu erleben und zu kommentieren. So können Unstimmigkeiten und Fehlanforderungen noch im Projekt behandelt werden, ohne dass der Gesamtprozess gestört wird.

2 Grundlagen

Scrum ist eine Methode zur agilen Softwareentwicklung. Weitere Methoden zur agilen Softwareentwicklung sind unter Anderem Crystal, Feature Driven Development und Extreme Programming.

Bei der Softwareentwicklung mit Scrum wird das Projekt immer in mehrere Teile zerlegt, sog. "Sprints". Bei der Entwicklung wird dann mit den für das Projekt wichtigsten Teilen bzw. Anforderungen begonnen, die weniger wichtigen Teile werden zum Schluss fertiggestellt. Welche Anforderungen am wichtigsten sind, entscheidet der Product Owner, der das Produkt vertritt. Er gliedert die Anforderungen an das Projekt an Ihrem Geschäftswert, erläutert sie dem Entwicklerteam und achtet auf die korrekte Umsetzung. Die Anforderungen werden im sog. Product Backlog gesammelt. Der Product Backlog wird wiederum zerteilt in verschiedene Items, die hinterher einzeln oder zu mehreren die Aufgaben des Sprint Backlogs ausmachen. Ein Sprint ist der Zeitraum der Entwicklung und umfasst höchstens vier Wochen. Am Ende eines Sprints steht ein "Stück" Software, das potentiell bereits einsetzbar ist. So werden nach und nach die Items des Product Backlogs abgearbeitet, bis das Projekt fertig gestellt wurde.

Das Team in Scrum ist selbstorganisierend. Es gibt in Scrum keinen Projektmanager im herkömmlichen Sinne, sondern die Aufgaben des Projektmanagers sind aufgeteilt auf die drei Rollen in Scrum: Team, Product Owner und Scrum Master. Da das Team selbst organisierend ist, kann und darf es nicht von Micromanagement betroffen sein. Das Team entscheidet wer welche Arbeiten erledigt. Der Wegfall von Hirarchie innerhalb des Projektes ist ein wichtiger Bestandteil von Scrum.

Die Prinzipien agiler Softwareentwicklung lauten:

  • Individuen und Interaktionen mehr als Prozesse und Werkzeuge
  • Funktionierende Software mehr als umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
  • Reagieren auf Veränderung mehr als das Befolgen eines Plans[2]


Diese Regeln liegen der Anwendung von Scrum zugrunde. Das Scrum Framework ist an vielen Stellen interpretierbar und lässt dem Anwender viele Freiheiten in der Benutzung. An allen Stellen, an denen Scrum Raum für eigene Ideen lässt, sollten die Regeln des Agilen Manifests beachtet werden. So ist gewährleistet, dass man sich auch weiterhin im Rahmen der angestrebten Agilität bewegt.


2.1 Begriffsklärung

Der Begriff Scrum ist englisch und beschreibt eine Standardsituation des Rugbysports, bei der nach einer Unterbrechnung das Spiel wieder aufgenommen wird. Das ist symptomatisch für den Ablauf in Scrum und kann mit einem Sprint verglichen werden: Nach einer Periode werden die Aufgaben re-evaluiert und die Arbeit wieder aufgenommen.

Scrum wird in der Literatur oft in Großbuchstaben geschrieben, aber es handelt sich dabei nicht um ein Acronym.

2.2 Funktion

Scrum dient der Projektbearbeitung bei der Softwareentwicklung. Hierbei kann Scrum in unterschiedlichsten Bereichen eingesetzt werden und dient nicht nur der Entwicklung von Standardprodukten sondern auch von Individualsoftware. Weiterhin ist durch die agile Vorgehensweise eine Verschlankung von Projekten möglich. Es wird nur das entwickelt, was benötigt wird und Änderungen sind leicht durchführbar und sogar während der Entwicklung erwünscht.

Nach Hirotaka Takeuchi und Ikujiro Nonaka dient Scrum ursprünglich der Produktentwicklung und sollte diese um einiges schneller und flexibler machen. Ausgehend von diesem Ursprung ist der Anspruch von Scrum die Weiterentwicklung und ständige Verbesserung nicht nur des Produktes, sondern auch der Mitarbeiter und Prozesse in allen Belangen. Dahinter steht ursprünglich die japanische Arbeitsphilosophie Kaizen.[3]

2.3 Entstehung/Entwicklung

Scrum geht zurück auf Hirotaka Takeuchi und Ikujiro Nonaka und deren Artikel im Harvard Business Journal "The New New Product Development Game"[4]. Dort kommt erstmals der Zusammenhang mit Rugby zustande.

Im Jahr 1991 erwähnten DeGrace und Stahl zum ersten Mal den "Scrum approach"[5].

Anfang der neunziger Jahre nutzte Ken Schwaber erstmalig diese Vorgehensweise in seiner Firma Advanced Development Methods. Zeitgleich setzte Jeff Sutherland, in Zusammenarbeit mit anderen, Scrum ein. Sutherland und Schwaber präsentierten 1995 einen Vortrag auf der OOPSLA '95, der das Scrum Vorgehensmodell erstmalig beschreibt. Schwaber und Sutherland arbeiteten in den Folgejahren an der Verbesserung des Vorgehensmodells bis zu dem, was wir heute als Scrum kennen.

Im Jahr 2001 taten Schwaber und Mike Beedle sich zusammen und verfassten das Buch "Agile Softwareentwicklung mit Scrum"[6].

2.4 Agile Softwareentwicklung und Abgrenzungen

Es gibt verschiedene Methoden zur Softwareentwicklung, wobei alle Methoden nach festen Schemata durchgeführt werden. Da Software in immer kürzeren Zeitrahmen und mit immer mehr Anforderungen entwickelt wird und auch die Qualität kontinuierlich steigen soll, sind bestimmte Rahmenpläne - oder "Frameworks" - zur Organisation notwendig. Bei diesem Rahmenplan sind folgende Punkte von Bedeutung:

  • Reihenfolge und Phasen des Arbeitsablaufes sowie die in den verschiedenen Phasen durchzuführenden Aktivitäten
  • Verantwortlichkeiten und Konsequenzen
  • Anforderungen (Was wird für das Projekt benötigt?) und ggf. Teilprodukten
  • Mitarbeiterqualifikationen (Müssen ggf. Mitarbeiterschulungen durchgeführt werden?)
  • zu verwendende Standards, Richtlinien, Methoden und Werkzeuge

Es gibt hierbei die klassischen und die agilen Methoden, die sich in der Art der Vorgehensweise voneinander unterscheiden.

Bei den klassischen Modellen werden die einzelnen Projektphasen eher sequenziell abgehandelt und sind zudem sehr dokumentenlastig organisiert. Bei den klassischen Methoden werden Projekte in einzelne Abschnitte aufgeteilt, wobei in den einzelnen Abschnitten bestimmte Ergebnisse erzielt werden sollen. Zudem werden bei den klassischen Modellen alle Tätigkeiten in Phasen aufgeteilt. Typisch für die klassischen Methoden ist es, dass beschrieben wird wie etwas während eines Projektes gemacht werden soll oder auch was in einem Dokument zu einer bestimmten Zeit beschrieben sein muss, damit die Software entwickelt werden kann. Da der Kunde allerdings erst relativ spät einen Einblick in die Realisierung der gewünschten Software bekommt, entsteht hierbei bereits zu Beginn das Risiko, dass die Software, trotz vorher formulierter Anforderungen nicht dem entspricht, was sich der Kunde vorgestellt hatte. Durch vorgegebene Dokumente und Richtlinien soll dieses Risiko reduziert werden. Bereits zu Beginn des Projektes soll deshalb auch eine möglichst große Planbarkeit erreicht werden.

Agile Methoden dagegen sind eher darauf ausgerichtet auf Änderungen im Projekt kurzfristig reagieren zu können. Deshalb wird bei agilen Methoden auch grundsätzlich keine Dokumentationsweise festgelegt. Es wird lediglich formuliert was gemacht wird und nicht, wie etwas durchgeführt werden soll. Eines der grundlegenden Prinzipien der agilen Softwareentwicklung besagt: "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage". Daher sind neue Anforderungen oder Änderungen zu jeder Zeit willkommen [7]. Weiterhin ist das Ziel der agilen Softwareentwicklung eine Verschlankung des gesamten Prozesses, um den Softwareentwicklungsprozess zu optimieren. Um dieses Ziel zu erreichen rücken hierbei Projektziele, Kunden, Werte sowie Prinzipien und Methoden zur Zielerreichung in den Mittelpunkt. Das wichtigste Ziel der gesamten agilen Softwareentwicklung ist jedoch eine funktionierende Software für den Kunden und auch eine erfolgreiche Integration von weiteren Softwarelösungen, welche durch wechselnde Anforderung erforderlich werden. Die Entwicklung agiler Software soll leicht umzusetzen und später flexibel anpassbar sein. Der Entwicklungsprozess ist hierbei sehr kommunikationsintensiv.

Im Gegensatz zur agilen Softwareentwicklung liegt der Kritikpunkt bei den traditionellen Vorgehensmodellen vor allem in der fehlenden Flexibilität. Dadurch wird es oft schwierig kurzfristige Änderungswünsche des Kunden in die Entwicklung mit einzubeziehen, so dass beispielsweise mehrere Versionen hintereinander entwickelt werden müssen[8].

3 Einführungsschritte

3.1 Vorbereitung

Um Projekte mit Scrum erfolgreich durchzuführen sollten zunächst erst einmal alle wissen, womit sie es zu tun haben. Die Artefakte, Aufgaben, Rollen und Regeln sollten allen Teilnehmern verständlich sein - auch den Stakeholdern. Es ist wichtig, dass auch innerhalb des eigenen Unternehmens die Vorgehensweise auf allen hierarchischen Ebenen beschlossen und akzeptiert ist. In Zusammenarbeit mit Kunden ist es gut, die Arbeitsweise von Sprints herauszustellen, damit innerhalb eines Sprints keine projektgefährdenden Störungen seitens des Kunden aufkommen. Änderungen sind immer Möglich - aber erst nach einem Sprint, nicht währenddessen.

Das Arbeiten im Scrumframework ist für frisch gebildete Teams oder Scrum-Neulinge immer eine große Herausforderung, da die Umgewöhnung vom herkömmlichen Projektmanagement groß ist. Daher sollte in den ersten Intervallen mit Anpassungsschwierigkeiten gerechnet werden. Speziell der Scrum Master sollte darauf vorbereitet sein, dass das Team sich zu Beginn zu große Ziele setzt was zu Frustration bei Team und Stakeholdern führen kann.

3.2 Aufbau des Frameworks

3.2.1 Vision

Die Vision ist ein wichtiger Teil innerhalb von Scrum. Dabei „ist das Finden, Weitertragen und Verbreiten der Vision Aufgabe des Product Owners“[9]. Es handelt sich nicht um die technische Umsetzung, sondern darum ein Projektziel zu formulieren.

Bei der Ausarbeitung dieses Ziels sollten Leitfragen beachtet werden, die helfen können. Darunter beispielsweise die Frage nach dem Grund für das Projekt und in welchen Bereichen die Software benötigt wird.

Außerdem sollte in der Vision angegeben werden, welchen Einschränken seitens des Umfelds und des Zwecks das Projekt unterliegt. Dazu gehören unter anderem das Budget, der grobe Zeitrahmen und andere Umwelteinflüsse.

Die Vision wird von Product Owner in Zusammenarbeit mit dem Kunden erstellt. Dadurch kennt der Product Owner auch das zu erreichende Projektziel sehr genau. Folglich ist die Vision nicht nur ein Gefühl, sondern auch ein klar definiertes Ziel auf welches das Projekt hinarbeiten soll.
Insgesamt wird dadurch die Vision nicht nur „richtungsweisend für ein Projekt, sondern mehr das Herz eines Projektes.“ [10]

3.2.2 Rollen

Bei der Durchführung eines Projektes mit Hilfe von Scrum werden die am Projekt mitarbeitenden Personen in verschiedene Gruppen, auch Rollen genannt, eingeteilt, welche unterschiedliche Verantwortungen während des Projektes übernehmen.
Zu den Rollen gehören der Scrum Master, der Product Owner, das Scrum Team und der Stakeholder. Zwar haben die Mitarbeiter der verschiedenen Rollen unterschiedliche Verantwortungen, jedoch sind alle am Projekt beteiligten Personen hierarchisch gleichgestellt und somit auch gleich wichtig für die erfolgreiche Durchführung eines Projektes mit Hilfe von Scrum.

3.2.2.1 Scrum Master

Der Scrum Master hat unterschiedliche Aufgaben und trägt verschiedene Verantwortungen.
Er hat die Verantwortung für den Scrum-Prozess und seine Umsetzung. Somit ist er der Vermittler zwischen dem Team und der Außenwelt und unterstützt das Team in allen Belangen. Er achtet auf die ständige Optimierung der Umwelt und strebt einen maximalen Nutzen der Scrum-Techniken an.
Eine weitere wichtige Aufgabe ist das Beseitigen von Hindernissen. Die Hindernisse können sowohl innerhalb des Teams entstehen als auch von außen an das Team heran getragen werden. Der Scrum Master muss für ein ungestörtes Arbeitsumfeld des Teams sorgen und Hindernisse beseitigen. Ein Hindernis kann beispielsweise fehlende Informationen seitens Product-Owners sein. Folglich sorgt der Scrum Master auch für einen ungestörten und fehlerfreien Informationsfluss zwischen Product Owner und Team. Hierbei muss der Scrum Master auch darauf achten, dass das Team vor unberechtigten Eingriffen während des Sprints geschützt ist.
Dazu moderiert er auch die Scrum-Meetings und hält bei dieser Gelegenheit auch die Scrum-Artefakte aktuell.

Ein Scrum Master hat aber nicht nur Aufgaben und Verantwortungen, sondern unterliegt auch verboten:
Er darf nicht der Chef des Teams sein, stammt also idealerweise aus einer andern Abteilung oder ist gar ein externer Dienstleister.
Bei der Verteilung der Items, also welches Teammitglied welche Arbeit übernimmt, darf der Scrum Master nur beratend zur Seite stehen.
Sollte der Scrum Master eine Doppelfunktion oder gar eine Mehrfachfunktion bei einem Scrum-Projekt begleiten, kommt es in der Regel zu Interessenkonflikten. Diese gilt es zu vermeiden, weshalb er sich ausschließlich auf die o.g. Aufgaben konzentrieren soll.

Der Scrum Master wird früher oder später der Versuchung begegnen, das Team oder einzelne Mitglieder zu micro-managen. Da das Team sich aber selbst organisiert, ist das nicht Aufgabe des Scrum Masters. Sokratische Fragestellungen helfen dabei, das Team anzuleiten ohne es tatsächlich zu leiten. Es ist für die Arbeit im Scum-Framework wichtig, dass der Scrum Master immer als helfender und verlässlicher Bestandteil des Scrum Teams wahrgenommen wird und nicht als eine Art Chef mit anderem Namen.

Für Projektmanager sind die Aufgaben des Scrum Masters oft schwer umzusetzen, da hier ein Umdenken erforderlich ist. Das frühere Aufgabenspektrum eines Projektmanagers findet sich nicht in den Aufgaben des Scrum Masters oder des Product Owners wieder. Vertrauen in die Fähigkeit des Scrum Teams, die beschlossenen Aufgaben umzusetzen ist für Scrum unerlässlich.

Diese Regeln, Vorschriften und Aufgaben des Scrum Masters helfen Ihm dabei das Scrum-Projekt zielgerichtet durchzuführen[11].

3.2.2.2 Product Owner

Der Product Owner ist die Schnittstelle zwischen dem Scrum Team und den Ansprüchen an dem zu entwickelnden Produkt.
Um dieser Tätigkeit nachgehen zu können, unterliegt er gewissen Aufgaben und Verantwortungen.
Der Product Owner pflegt den Product Backlog. Dieses kann er, da er auch die fachliche Auftraggeberseite vertritt. Da der Product Owner weiß, wie das Produkt am Ende aussehen soll, ist er auch für das Priorisieren der Backlog Items zuständig.
Am Daily Scrum nimmt er nur passiv zur eigenen Informationen teil, steht dem Team aber für Rückfragen zur Verfügung.

Um sicher zu stellen, dass der Product Owner nicht zu viel Kontrolle über das Team ausübt, darf er nicht die Rolle des Chefs des Teams übernehmen.
Die Moderation des Daily Scrums ist ihm ebenso untersagt, wie dabei ungefragt zu reden.
Ist das Sprint Backlog einmal definiert, so darf es nicht mal vom Product Owner verändert werden. Um Interessenskonflikte zu vermeiden, darf er weder Scrum Master noch Team Member sein.

Zudem ist es weniger empfehlenswert, wenn der Product Owner ein direkter Vorgesetzter des Projekt-Teams ist. Hierbei kann es sonst dazu kommen, dass sich das Team evtl. nicht völlig frei entfalten kann, aufgrund einer gewissen Hemmschwelle vor dem Vorgesetzten.
Wichtig ist jedoch, dass er fachliche Kompetenz aufweist, um das Product Backlog klar und deutlich zu definieren[12][13].

3.2.2.3 Team

Ein Team besteht typischerweise aus fünf bis neun Leuten. Dabei werden den Teammitgliedern keine sprechenden Titel wie "Entwickler", "Tester" o.ä. gegeben. Da ein entscheidender Teil von Scrum die freie Wahl von Aufgaben ist, kann jedes Teammitglied entsprechend seiner Fähigkeiten Aufgaben erledigen – egal für welche Aufgabe er ursprünglich eingestellt wurde.

Das Team in Scrum organisiert sich selbst, was zu einem starken Gemeinschaftsgefühl und gegenseitiger Unterstützung in der Gruppe führt[14].

Bei der Auswahl von Mitarbeitern sollte darauf geachtet werden, dass die fachlichen und sozialen Kompetenzen gut durchmischt sind. Ein Team von introvertierten, stark technik orientierten Entwicklern wird beispielsweise keine anwenderfreundliche Software entwickeln. Die Vorgaben für ein Team in Scrum sind also als „cross-functional“ und selbstorganisierend zu bezeichen[15].

Im Scrum-Jargon hat es sich eingebürgert, das Team als „Pigs“ zu bezeichnen, während der Rest der Beteiligten „Chickens“ heißen. Dies geht auf einen in Scrum-Kreisen sehr bekannten Witz zurück, in dem ein Huhn ein Schwein fragt, ob es mit ihm ein Restaurant eröffnen möchte, welches „Ham and Eggs“ heißt. Das Schwein entscheidet sich schließlich jedoch anders, weil es selbst völlig verpflichtet wäre, während des Huhn lediglich involviert wäre[16][15].

3.2.2.4 Stakeholder

Als Stakeholder wird jeder mit besonderem Interesse am Projektergebnis bezeichnet.

Der Stakeholder ist etweder der spätere Nutzer des Erzeugnisses oder er stellt die finanziellen Mittel für das Projekt bereit.
Insgesamt kann er jedoch auch in anderer Art und Weise am Projekt beteiligt sein[17].

Stakeholder des Projektes kann der Auftraggeber selbst sein, sowie das firmeneigene Management, aber auch die Kundenzielgruppe. Bei firmeninterner Softwareentwicklung sind die Stakeholder beispielsweise die späteren User.

Stakeholder nehmen innerhalb von Scrum keinen direkten Einfluss auf das Projekt, aber sie sind wichtig für die Zielsetzung bzw. die Vision. Es kann nützlich sein, Repräsentanten von Stakeholdern zu schaffen, die stellvertretend für eine große Gruppe User Stories bereitstellen und sich ggf. im Sprint Review die fertige Software ansehen und sie konstruktiv kommentieren.

3.2.3 Artefakte

Genau wie die oben genannten Rollen sind Artefakte (oder englisch „artifacts“) durch das Framework vorgegeben. Ein Artefakt meint dabei ein Werkzeug, mit dem der Prozess bearbeitet werden kann.

Die meisten Artefakte dienen der Übersicht und Planung. Dabei setzt sich der Aufbau Matroschka-Artig fort: Der große Product Backlog wird aufgeteilt in den kleineren Sprint Backlog, der die einzelnen Aufgaben genauer definiert. Die Artefakte in Scrum sind so aufgebaut, dass sie Redundanzen möglichst vermeiden und nur so viel Arbeitsaufwand verursachen, wie nötig. Dabei bleibt es den Anwendern überlassen, die Artefakte in Ihrer Funktionalität den Mindestanforderungen entsprechen zu lassen oder ihren Umfang größer zu skalieren.

Für die Umsetzung der Artefakte können ein White-Board, eine Tabellenkalkulation oder spezielle Software verwendet werden – Scrum überlässt auch hier den Anwendern die Autonomie der Entscheidung.


3.2.3.1 Product Backlog

Abb.1: Beispiel für einen Product Backlog
Abb.1: Beispiel für einen Product Backlog

Zu Anfang eines Projektes wird ein Product Backlog erstellt. Dieser Backlog ist eine durch den Product Owner nach dem Geschäftswert priorisierte Liste der Anforderungen an die Software [18]. Die Anforderungen werden in Product Backlog Items (PBI) zusammengefasst. Jedes Item ist klein genug, um während eines Sprints realisiert zu werden. Die verschiedenen PBI bilden später die Sprint Backlogs[19].

Der Product Backlog fällt in die Verantwortlichkeit des Product Owners. Grundlegend befragt der Product Owner die verschiedenen Stakeholder des Projektes nach Ihren Anforderungen, sammelt diese und priorisiert sie.

Dabei ist der Product Backlog keine Dokumentation der Anforderungen im Sinne eines Pflichtenhefts, sondern ein sich veränderndes Protokoll der Business-Anforderungen. Obwohl auch technische Anforderungen seitens des Teams in den Product Backlog mit aufgenommen werden können, sollten die Items von den Stakeholdern, am besten den späteren Benutzern der Software, kommen[18].

Der Product Backlog hat insbesondere bei sehr komplexen Projekten das Potential, sehr umfangreich und arbeitsintensiv zu werden. Es ist generell möglich, im Product Backlog bereits eine Releaseplanung anzulegen, außerdem Kosten und Bugs zu erfassen und auf ausführlichere Dokumentation zu verweisen. Das kann bei sehr langfristigen Projekten sinnvoll sein und hängt davon ab, was der Product Owner bevorzugt.

Die Items des Product Backlogs, also die eigentlichen Anforderungen an die Software, können einfach Sätze sein. Cohn bevorzugt aber das Sammeln sog. "Stories" oder Use Cases (ZITAT). Das sind Beschreibungen der Anwendungsfälle durch den User. Diese nicht technischen Beschreibungen folgen der Fragestellung "Was soll passieren, wenn...".

Das Team entscheidet zu Beginn des Sprints, wie diese Beschreibungen in Software umzusetzen sind. Es liegt aber in der Hand des Product Owners, den Kunden oder Usern derartige Fragen zu stellen, dass der Anwendungsfall als verständliche Story in ein Item umgesetzt werden kann.

3.2.3.2 Sprint Backlog

Abb.2: Beispiel eines Sprint Backlogs
Abb.2: Beispiel eines Sprint Backlogs

Der Sprint Backlog besteht aus einem oder mehreren Items aus dem Product Backlog. Diese Items werden in Aufgaben von höchstens sechzehn Stunden zusammengefasst oder unterteilt. Er wird am Anfang eines Sprints während des Sprint Planungsmeetings erstellt.

Der Sprint Backlog ist ein Artefakt des Teams. Die aus den PBI resultierenden Aufgaben werden ggf. vom Product Owner noch näher erläutert, aber die Einschätzung für die Zeit und das Hinzufügen eventuell notwendiger technischer Aufgaben ist eine Praxis des Teams.

Die Aufgaben des Sprint Backlogs sollten sicher vom ganzen Team verstanden worden sein, damit klar ist, was im anstehenden Sprint zu tun ist[20][21].

3.2.3.3 Burn Down Chart

Abb.3: Burndown Chart
Abb.3: Burndown Chart

Um den Fortschritt visuell darzustellen, gibt es die sogenannten Burndown Charts. Der Name leitet sich von der Funktion ab, da hier ein fallender Graph dargestellt sein soll. Es gibt zwei Arten von Burndown Charts, welche sich zwischen Task und Product Borndown Charts unterscheiden.

Bei ersteren wird tagesaktuell die Summe der zu erledigenden Aufgaben abgebildet. Hier kommt es jedoch auch vor, dass der Graph ansteigt, wenn neue Aufgaben hinzu kommen oder bestehende Aufgaben weiter unterteilt und daraus neue Aufgaben erzeugt werden.
An dieser Stelle ist auch zu erkennen, ob die Aufgabendefinition fehlerhaft ist, wenn der Graph tendenziell eher ansteigt.

Die zweite Variante dient der Darstellung offener Backlog Items. Sobald ein Item samt seiner Aufgaben vollständig abgearbeitet ist, wird dieser von der Liste gestrichen. Dadurch ergibt sich ein kontinuierlich fallender Graph. Am letzten Tag des Sprints sollte der Graph bei null angekommen sein.
Es ist ein großer Vorteil, dass alle Projektbeteiligten direkt erkennen können, wie der Status ist, bzw. wie viele offene Punkte es gibt[22].

3.2.3.4 Impediment Backlog

"Impediment" heißt auf Deutsch "Hindernis", folglich wird der Impediment Backlog auch als Hindernissliste bezeichnet. Hierin werden Hindernisse aufgeführt, die das Team bei der Bearbeitung seiner Aufgaben oder dem Erreichen des Sprint Ziels beeinträchtigen. Solche Hindernisse sollen während der täglichen Scrum Meetings oder während der Sprint Retrospektive am Ende des Sprints besprochen werden. Der Scrum Master ist dabei für die Sammlung der Hemmnisse im Impediment Backlog und für eine anschließende zügige Behebung ebendieser zuständig.

3.2.4 Meetings

In Scrum gibt es verschiedene Arten von Meetings, welche alle einem bestimmten Zweck dienen und im Softwareentwicklungsprozess zu unterschiedlichen Zeitpunkten stattfinden. Meetings sind ein essentieller Bestandteil von Scrum, da so alle Teammitglieder auf dem laufenden gehalten werden und auch die Arbeit, durch die regelmäßigen Meetings kontinuierlich vorrangetrieben wird. Weiterhin dienen die Meetings dazu, dass alle Teammitglieder einen Überblick über das gesamte Projekt erhalten und sich nicht nur auf ihren eigenen Projektbereich fixieren. Durch die Meetings kann so auch weiterer Gesprächsbedarf entstehen, der dann später in Einzelgesprächen gedeckt werden kann.

3.2.4.1 Sprint Planung

Zu Beginn eines Sprints findet ein Sprint-Planungsmeeting statt. Dieses Meeting hat eine vom Scrum Framework vorgezeigte Dauer und Gliederung: zwei Teile die jeweils vier Stunden nicht überschreiten sollten. Im ersten Teil des Meetings, an dem das gesamte Team teilnimmt, beschreibt der Product Owner das PBI mit der jeweils höchsten Priorität[23]. Es wird dann vom Team eingeschätzt, ob das Item im kommenden Sprint umgesetzt werden kann.

Im ersten Teil des Sprint Planungsmeetings wird auch ein klares Ziel des Sprints definiert, auf das das gesamte Team sich einigt. Es wird die Dauer des Sprints festgelegt. Ein Sprint hat normalerweise eine Dauer von vier Wochen, höchstens aber einem Kalendermonat. Bei kleineren Projekten oder weniger umfangreichen Anforderungen kann ein Sprint auch kürzer sein. Die Länge des Sprints hängt von den bisherigen Erfahrungen und der Einschätzung des Teams ab, das die Länge des Sprints entscheiden sollte[24]. Außerdem wird beschlossen, wann und wo das tägliche Sprintmeeting stattfindet, der sog. Daily Scrum. Innerhalb dieses Meetings wird auch definiert, was genau ein "fertig" eigentlich meint: Wann ist das Produkt, das während eines Sprints erstellt wird, fertig zu nennen und welche Merkmale muss es dafür aufweisen? Also beispielsweise: Ist es getestet, ist es dokumentiert, entspricht es den Anforderungen etc..

Zusammengefasst ist das Ziel des ersten Teils des Planungsmeetings, den Umfang an Arbeit einzuschätzen und festzulegen, welche Arbeit getan wird und wie lange sie dauert. Sobald diese Punkte beschlossen wurden, kann der Product Owner den Sprint nicht mehr verändern, Arbeit hinzufügen oder den Sprint verlängern.

Im zweiten Teil des Planungsmeetings wird der Sprint Backlog erstellt. Der Sprint Backlog bricht das im ersten Teil des Meetings ausgewählte PBI in detaillierte Aufgaben auf. Es wird die geschätzte Dauer der Aufgaben in Stunden festgelegt. Dabei sollte eine Aufgabe möglichst innerhalb eines Tages erledigt werden können.

Scrum zeichnet sich durch sich selbst-organisierende Teams aus. Das bedeutet auch, dass Aufgaben innerhalb eines Sprints nicht vergeben werden. Stattdessen suchen sich die Teammitglieder ihre jeweiligen Aufgaben selbst aus und stimmen diese untereinander ab. Es liegt in der Verantwortlichkeit des Scrum Masters, das Team an dieser Stelle anzuleiten ohne ihm seine Selbstständigkeit zu nehmen.

3.2.4.2 Daily Scrum

Der Daily Scrum ist ein tägliches, fünfzehn minütiges Meeting an dem das gesamte Team unter der Leitung des Scrum Masters teilnimmt. Ziel des Meetings ist die Statusabfrage.

Jedes Teammitglied muss während dieses Meetings kurz und bündig die folgenden Fragen beantworten:

  • Was habe ich seit dem letzten Meeting getan?
  • Was werde ich vor dem nächsten Meeting tun?
  • Gibt es dabei Probleme?

An dieser Stelle können übernommene Aufgaben und deren Status im Scrum Backlog verzeichnet werden. Sollten Teammitglieder auf Hindernisse oder Probleme bei der Aufgabenbewältigung stoßen, ist es wichtig, dass diese durch den Scrum Master im Impediment Backlog verzeichnet werden[25].

Da der Daily Scrum täglich durchgeführt wird, ist es wichtig, dass der Scrum Master auf Struktur und Genauigkeit besteht. Das Daily Scrum ist keine Diskussionsplattform – es sollten während des Daily Scrum keine Aufgaben oder Lösungsvorschläge diskutiert werden. Gibt es Diskussionsbedarf, sollte der Scrum Master diesen nach dem Meeting zwischen den betroffenen Teammitgliedern anleiten oder die betroffenen Teammitglieder sollten selbst nach dem Meeting ein Gespräch vereinbaren.

Wichtig ist auch, dass der Daily Scrum wertfrei abläuft. Weder sollte der Scrum Master durch Gestik, Mimik oder Aussagen einzelne Mitarbeiter bewerten, noch zulassen dass andere Teammitglieder sich dementsprechend äußern[26]. Andernfalls läuft der Scrum Master Gefahr, dass sein Team den Daily Scrum als Ballast betrachtet und sich nicht mehr ehrlich und unbefangen über den Stand seiner Arbeit äußert. Ist eine Atmosphäre geschaffen, in der die Mitarbeit sich nicht mehr wertgeschätzt sondern im Gegenteil bewertet fühlen, wird gegen die Grundsätze des Agilen Manifests verstoßen[2].

3.2.4.3 Sprint Review

Am Ende eines Sprints steht das auf vier Stunden begrenzte Sprint Review Meeting. An dieser Besprechung nimmt das Team, der Scrum Master und Product Owner teil, sowie ggf. interessierte Kunden. Es wird die fertige Software bzw. der fertige Softwareteil mit seinen Funktionen präsentiert. Der Product Owner entscheidet, ob das Ziel des Sprints erreicht wurde. Sollte das Ziel nicht erreicht worden sein oder sollten sich aus dem Sprint neue Anforderungen ergeben haben, wird der Product Backlog angepasst und die PBIs für spätere Sprints entsprechend angepasst[27].

Änderungen können sich ergeben, weil Funktionen dem Product Owner nicht zusagen, weil sich aus der Entwicklung nicht vorhersehbare oder nicht vorhergesehene Probleme ergeben haben oder Umwelteinflüsse die Umgebung des Projektes verändern.

Wichtig für die Durchführung des Sprint Reviews ist es, auch hier auf eine möglichst wertneutrale Umgebung zu achten. Der Sprint Review ist dazu da, zu bewerten ob das Ziel des Sprints erreicht wurde. Ist dies nicht der Fall, sollte davon abgesehen werden, einzelne Teammitglieder oder das ganze Team zur Verantwortung zu ziehen. Ist eine „Manöverkritik“ gemeinsam mit dem Product Owner sinnvoll, kann sie während des Reviews durchgeführt werden, ansonsten sollte konstruktive Kritik am Produkt Vorrang haben[28]. Für eine Besprechung mit dem Team ist das nachfolgende Retrospective Meeting, das ohne den Product Owner und ohne die Kunden durchgeführt wird, vorgesehen.

3.2.4.4 Retrospective Meeting

Das Retrospective Meeting folgt abschließend nach dem Sprint Review. Es ist auf drei Stunden begrenzt[29] und dient der Reflexion des vergangenen Sprints mit Hinblick auf die Verbesserung des kommenden Sprints. Die Fragestellung, unter der das Meeting stehen sollte ist: Was lief gut während des Sprints? Was könnte verbessert werden?[30] An dem Meeting nehmen das Team und der Scrum Master teil. Der Product Owner kann teilnehmen, muss aber nicht. Allerdings sollte er sich für Rückfragen bereithalten, beispielsweise telefonisch. Das Retrospective Meeting oder "Die Retrospektive" kann auch genutzt werden, um Differenzen innerhalb des Teams zu lösen oder aus dem Product Backlog entstehende Fragen zu klären. Da sich der Product Backlog verändert, kann eine Klärung immer wieder wichtig sein und sollte ggf. vom Scrum Master angeleitet werden.

3.2.5 Release Planung

"Estimating and planning are not just about determining an appropriate deadline or schedule. Planning—especially an ongoing iterative approach to planning—is a quest for value."[31]

Eine Releaseplanung ist für jedes Projekt unerlässlich. Darin unterscheidet sich auch Scrum nicht vom herkömmlichen Projektmanagement.

Es gibt keinen von Scrum vorgegebenen Weg zur Releaseplanung.

Bei der Release Planung erarbeiten Product Owner und das Team gemeinsam die Aufwandseinschätzungen für die Anforderungen des Product Backlogs. Diese Einschätzungen dienen als Basis für die spätere Priorisierung der einzelnen Anforderungen und somit auch für die weitere Release- und Sprintplanung [32]. Zur Aufwandseinschätzung gibt es verschiedene Methoden. Eine dieser Methoden, bei welcher die Komplexität der verschiedenen Anforderungen auf die Fibonacci Zahlenfolge abgebildet wird, ist das so genannte "Planning Poker". "Hier werden Aufwandskategorien definiert, die dann den Items oder den Tasks zugeordnet werden. Die Aufwandskategorien werden zunächst fachlich beschrieben, zum Beispiel »sehr geringer Aufwand«, »geringer Aufwand«, »neutraler Aufwand«, »höherer Aufwand«, »sehr hoher Aufwand«, »extrem hoher Aufwand«. Diesen Kategorien teilt man dann die Zahlen zum Beispiel der Fibonacci Reihe zu, da hier die Abstände zwischen den Zahlen immer größer werden."[33]

Bei der Durchführung des Planning Pokers bekommen alle Teammitglieder einen Satz von Karten, beispielsweise entsprechend der Fibonaccireihe bis zu einer bestimmten Zahl. Es werden dann nacheinander die einzelnen Aufgaben bewertet, dabei "spielt" jedes Teammitglied die Karte mit der Zahl aus, die seinem Empfinden nach am ehesten dem Aufwand entspricht. Nach jeder Runde werden die Zahlen verglichen und besprochen und die Bewertung wiederholt, solange bis die Bewertungen nahezu übereinstimmen.

Wichtig bei diesem Prozess ist die Diskussion der Aufgaben, die nach sich zieht, dass alle Teammitglieder genauestens über die Aufgaben bescheid wissen.

Je nachdem, ob bei einem Projekt die Funktionalität oder der Liefertermin im Vordergrund stehen, wird hiernach die Release Planung erstellt. Um Unsicherheiten, welche durch große Leistungs- und Zeitumfänge entstehen können, möglichst zu umgehen, werden bei der Planung Zeit-Puffer eingeplant. Wenn beispielsweise ein bestimmter Termin für ein Release angestrebt wird, wird abgewägt wie viele Sprints bis zu diesem Termin vervollständigt werden können. Es wird dann ein entsprechender Zeit-Puffer zwischen den letzten Sprint und den Releasetermin gelegt.

3.3 Zusammenfassung Projektverlauf

Abb.4: Der Scrum Prozess
Abb.4: Der Scrum Prozess

Zusammenfassend startet ein Scrum mit der Vision für das Projekt. Die Vision gibt die Marschrichtung vor. Danach erstellt der Product Owner den Product Backlog, verifiziert ihn gegenüber dem Kunden bzw. dem Auftraggeber und bespricht ihn mit dem Team. Diese Besprechung kann im Sprint-Planungsmeeting stattfinden oder in einem eigens angesetzten Workshop. Der Product Backlog wird vom Product Owner priorisiert. Entsprechend dieser Prioritäten wird der Sprint Backlog erstellt. Dieser Backlog gibt die verschiedenen Punkte des Product Backlogs als umsetzbare Aufgaben aufgeschlüsselt wieder. Diese Aufgaben sollten innerhalb eines Sprints, der nicht länger als vier Wochen dauern darf, erledigt werden können. Das Sprint-Planungsmeeting generiert außerdem das Sprint-Ziel, auf das das gesamte Team sich einigt. Ab Start des Sprints dürfen die Anforderungen an den Sprint nicht mehr verändert werden. Innerhalb des Sprints findet zu einem festen Zeitpunkt an einem festgelegten Ort das Daily Scrum Meeting statt. Das Meeting darf die Dauer von 15 Minuten nicht überschreiten und folgt dem Ziel, Probleme zu erkennen und alle Teammitglieder über den Stand des Projektes zu informieren. Am Ende eines Sprintzyklus steht potentiell auslieferbare Software. Die Software wird beim Review Meeting den Stakeholdern gezeigt. An dieser Stelle sollte darauf geachtet werden, dass die Mitarbeiter seitens der Stakeholder (Management, Kunden) nicht unter Erfolgsdruck gesetzt werden. Dies ist Aufgabe des Scrum Masters, der auch innerhalb des gesamten Projektes darauf achtet, dass dem Team keine Hindernisse beim Streben nach seinem gesetzt Ziel im Weg stehen. Mit dem Retrospective Meeting wird ein Sprint abgeschlossen. Zwischen zwei Sprints gibt es keine Pause. Endet der Sprint an einem Montag geht es am Dienstag mit dem Planungsmeeting für den nächsten Sprint weiter.

Dieser Vorgang wiederholt sich so lange, bis der Product Backlog abgearbeitet ist, potentiell unendlich.

3.3.1 Mitarbeiter

Mitarbeiter, die vorher noch nicht mit Scrum gearbeitet haben, müssen vorbereitet werden und es sollten ggf. Schulungen durchgeführt werden, damit effizient mit Scrum gearbeitet werden kann. Es kann sinnvoll sein, Kennenlern-Workshops abzuhalten, ehe mit dem ersten Sprint begonnen wird. Innerhalb des Teams muss auf Vertrauen geachtet werden. Eine Kultur von gegenseitigem Respekt und Hilfsbereitschaft im Team herzustellen ist gesund für das Projekt. Bei der Umstellung vom herkömmlichen Projektmanagement hin zu Scrum und damit Agilität und Eigenverantwortlichkeit, kann es zu Problemen kommen. Zwar gelten für den Projektleiter bzw. Scrum Master noch die gleichen sozialen Vorgaben wie vorher auch, aber er muss vorallem darauf achten, die Mitarbeiter nur anzuleiten, keinesfalls aber zu leiten. Ist kein Vertrauen zwischen den einzelnen Teammitgliedern vorhanden, z.B. aufgrund einer "Terrorherrschaft" des eines Teammitgliedes, kann es vorkommen, dass Informationen vorenthalten werden oder die Selbstorganisation nicht mehr funktioniert. Im schlimmsten Fall kann dies dann zum Scheitern des gesamten Projektes führen. Grundsätzlich ist deshalb jeder einzelne Mitarbeiter im Team wichtig und es sollte immer eine positive Grundstimmung zum effektiven Arbeiten aufrecht erhalten werden.

Das Teamgefühl, nicht nur innerhalb des Entwicklerteams sondern im ganzen Scrum Team, ist wichtig und wird gefördert. Es sollte Möglichst ein Klima herrschen, in dem alle Teammitglieder sich als gleichwertig empfinden und gemeinschaftlich auf die beschlossenen Ziele hinarbeiten.

3.3.2 Umgang mit Bugs

Zunächst muss definiert werden, was einen Bug ausmacht.
Dazu gibt es unterschiedliche Ansätze:

  • Fehler in dem entwickelten Produkt während der Entwicklungsphase.
  • Fehler mit dem fertigen Produkt
  • Probleme mit der Entwicklungsumgebung, ob Soft-/Hardware oder der räumlichen Umgebung.
    • [34]

Es gibt in Scrum keine dedizierte Testphase. Stattdessen findet während eines Sprints alles gleichzeitig statt. Es gibt auch keine dedizierten Tester, die Bugs tracken könnten. Es ist daher angebracht ein Bugtrackingtool zu verwenden, das allen Teammitgliedern zugänglich ist. Bugs sollten innerhalb eines Sprints behoben werden. Sollte dies nicht gelingen, müssen sie im nächsten Sprint behoben werden und so weiter.

Der Impediment Backlog ist nicht das Mittel zum Tracken von Bugs. Allerdings sollten Team und Scrum Master darauf achten, dass Bugs nicht "verschleppt" werden und sie ggf. im nächsten Sprint als Aufgabe definieren.

4 Schlussbetrachtung

Ein Betrieb, der von etablierteren Vorgehensmodellen auf Scrum umstellen möchte, sollte sich einen erfahrenen Scrum Master suchen. Ohne dessen Anleitung des Teams und Unterstützung des Product Owners kann das Gerüst schnell wichtiger werden als das Projekt selbst. Genau das sollte aber im Rahmen Agiler Softwareentwicklung vermieden werden.

Scrum lässt viel Gestaltungsspielraum zu. Teammitglieder, die vorher mit klassischen Methoden gearbeitet haben, könnten dazu neigen, jeden Schritt dokumentieren zu wollen und sich auch in der Interaktion mit anderen Teammitgliedern immer wieder auf Regeln und Dokumente zu beziehen. Dies ist bei Scrum weder erwünscht noch notwendig. Scrum baut statt dessen auf Kommunikation und Gruppendynamik auf. Eine "gesunde" Gruppe wird miteinander kommunizieren und Probleme auf direktem Weg angehen. Die Gruppe "gesund" zu halten ist Aufgabe des Scrum Masters, weswegen er gerade für neu gegründete Gruppen und Scrum-Anfänger immanent ist.

Unschlagbarer Vorteil von Scrum ist das wenigstens theoretisch fertige Softwarepaket am Ende eines Sprints: Der Kunde hat so die Möglichkeit zu evaluieren, ob seine Anforderungen der Realität entsprechen bzw. richtig umgesetzt werden.

Bei klassischen Methoden explodiert der Arbeitsaufwand gegen Ende eines Projekts oft über ein erträgliches Maß hinaus. Scrum hat im Vergleich dazu den Vorteil, dass ein Team nach drei bis vier Sprints weiß, wie viel es innerhalb eines Sprints umsetzen kann. Ab diesem Zeitpunkt kann es relativ genaue Aussagen über die kommenden Sprints treffen und die Planung kann dementsprechend angepasst werden. Da außerdem die Anforderungen eines Sprints innerhalb des Sprints nicht verändert werden dürfen, bleibt der Aufwand für die Mitarbeiter immer gleich. Man könnte also sagen, dass Scrum wenig Raum für Frustration durch Überstunden, unklare Anforderungen oder drängelndes Management bietet - Problematiken mit denen herkömmliche Vorgehensmodelle oft zu kämpfen haben.

Unter der Voraussetzung gut ausgebildeter Mitarbeiter, die dem Team helfen sich in dem unbekannten Framework Scrum zu erfolgreichen Projekten führen, die in der Durchführung schlanker und adaptiver sind. Vor allem aber kann Scrum zur Freude an Arbeit führen, was zur Erhöhung der Produktivität und letztlich zur Steigerung des ROI führt.

5 Anhang

5.1 Abkürzungsverzeichnis

PBI Product Backlog Item
ROI Return of Investment

5.2 Abbildungsverzeichnis

Abb.1: Beispiel für einen Product Backlog, http://www.goodagile.com/scrumprimer/scrumprimer.pdf , 16.06.2011 9:38

Abb.2: Beispiel eines Sprint Backlogs, http://www.goodagile.com/scrumprimer/scrumprimer.pdf ,16.06.2011 9:42

Abb.3: Burndown Chart , http://stuq.nl/software/trac/scrumburndownplugin , 16.06.2011 9:20

Abb.4: Scrum Prozess, Mountain Goat Software, Firmenwebseite, http://www.mountaingoatsoftware.com/system/asset/file/17/ScrumLargeLabelled.png 10.06.2011 10:40

5.3 Terminologie

Artefakt Vorgegebenes Werkzeug innerhalb des Projektverlaufs.
Scrum Entlehnt aus dem Rugby Sport meint das Wort eine Unterbrechung des Spielablauf, nach der das Spiel zurückgesetzt und fortgesetzt wird.
Sprint Inkrementelle, produktive Periode an deren Ende potentiell brauchbare Software produziert wurde.

5.4 Fußnoten

  1. ↑ Schwaber, Ken: Agile Project Management with Scrum, Microsoft Press 2004, aus der Einleitung
  2. ↑ 2,0 2,1 vgl. http://agilemanifesto.org/iso/de/
  3. ↑ vgl. http://www.gettingagile.com/2008/11/22/a-kaizen-mindset/
  4. ↑ vgl. http://hbr.org/product/new-new-product-development-game/an/86116-PDF-ENG
  5. ↑ vgl. DeGrace, Peter; Stahl, Leslie Hulet 01.10.1990, Wicked problems, righteous solutions, Prentice Hall
  6. ↑ Schwaber, Ken; Beedle, Mike (2002), Agile software development with Scrum, Prentice Hall
  7. ↑ vgl. http://www.scrum-kompakt.de/grundlagen-des-projektmanagements/vorgehensmodelle-in-der-softwareentwicklung/
  8. ↑ vgl. http://www.ordix.de/ORDIXNews/3_2007/Projektmanagement/agile_softwareentwicklung.html
  9. ↑ vgl. http://www.microtool.de/blog/post/Die-Produkt-Vision-als-Leitfaden-eines-Projektes.aspx, Absatz "Was ist eine Vision bei Scrum?"
  10. ↑ vgl. http://www.microtool.de/blog/post/Die-Produkt-Vision-als-Leitfaden-eines-Projektes.aspx
  11. ↑ vgl. http://scrum-master.de/Scrum-Rollen/Scrum-Rollen_ScrumMaster
  12. ↑ vgl. http://scrum-master.de/Scrum-Rollen/Scrum-Rollen_Product_Owner
  13. ↑ Koschek, Holger: Geschichten vom Scrum, dpunkt.verlag GmbH 2010, Seite 66
  14. ↑ vgl. http://www.mountaingoatsoftware.com/scrum/team
  15. ↑ 15,0 15,1 vgl. Deemer et al.: The Scrum Primer Version 1.2, S.6
  16. ↑ vgl. http://scrum-fibel.de/rollen/pigs%20chickens.html
  17. ↑ http://scrum-master.de/Scrum-Glossar/Stakeholder
  18. ↑ 18,0 18,1 vgl. Andrew Pham / Phuong-Van Pham: Scrum in Action, 1. Aufl., Boston 2011, S. 7
  19. ↑ vgl. http://www.scrumalliance.org/articles/47-how-scrum-works
  20. ↑ vgl. http://scrum-fibel.de/artefakte/sprint%20backlog.html
  21. ↑ vgl. http://scrummethodology.com/scrum-sprint/
  22. ↑ Koschek, Holger: Geschichten vom Scrum, dpunkt.verlag GmbH 2010, Seite 108f
  23. ↑ vgl. http://scrum-fibel.de/prozess/sprint%20planung.html
  24. ↑ vgl. http://scrummethodology.com/scrum-sprint/
  25. ↑ vgl. http://scrum-fibel.de/prozess/daily%20scrum.html
  26. ↑ vgl. http://www.scrumalliance.org/articles/62-the-daily-meeting-trap-
  27. ↑ vgl. http://scrum-fibel.de/prozess/sprint%20review.html
  28. ↑ vgl. http://www.scrumalliance.org/articles/48-successful-sprint-reviews
  29. ↑ vgl. http://en.wikipedia.org/wiki/Scrum_%28development%29#Meetings
  30. ↑ vgl. http://www.scrumalliance.org/articles/39-glossary-of-scrum-terms
  31. ↑ Mike Cohn, Agile Estimating and Planning, S. 5
  32. ↑ vgl. http://scrum-fibel.de/prozess/release%20planung.html
  33. ↑ vgl. http://www.scrum-kompakt.de/anforderungsanalyse-bei-scrum/schatzen-von-anforderungen-und-aufgaben/, Absatz "Planning Poker"
  34. ↑ http://www.phphatesme.com/blog/projektmanagement/viehzeug-in-scrum-bugs-vom-product-backlog-trennen-oder-nicht/


5.5 Literatur- und Quellenverzeichnis

5.5.1 Internet-Quellen

Josef Scherer / Artikel "Sprint Planung" , http://scrum-fibel.de/prozess/sprint%20planung.html , 16.06.2011 16:00

itemis AG / Artikel "Anforderungsanalyse bei Scrum" sowie weitere Unterkapital , http://www.scrum-kompakt.de/anforderungsanalyse-bei-scrum/ , 16.06.2011 15:22

Microsoft Deutschland GmbH / Artikel "Scrum" , http://msdn.microsoft.com/de-de/library/dd997796.aspx , 16.06.2011 15:17

Josef Scherer / Artikel "Impediment Backlog" , http://scrum-fibel.de/artefakte/impediment%20backlog.html , 16.06.2011 9:57

Torsten Horn / Artikel "Scrum", Unterpunkt "Hindernisliste ("Impediment Backlog")" , http://www.torsten-horn.de/techdocs/scrum.htm , 16.06.2011 10:07

itemis AG / Artikel "Vorgehensmodelle in der Softwareentwicklung" , http://www.scrum-kompakt.de/grundlagen-des-projektmanagements/vorgehensmodelle-in-der-softwareentwicklung/ , 15.06.2011 21:02

SMART Technologies / Artikel "Stay on Track with Scrum Meetings" , http://www.effectivemeetings.com/teams/teamwork/scrum.asp , 10.06.2011 13:01

Kriegisch, Alexander / Artikel "Daily Scrum Meeting" , http://scrum-master.de/Scrum-Meetings/Daily_Scrum_Meeting , 10.06.2011 13:16

Kriegisch, Alexander / http://scrum-master.de

Wolf, Matthias / Diplomarbeit "Sicherstellung von Qualität in der agilen Softwareentwicklung" 30.09.2009, http://tmi.pst.ifi.lmu.de/thesis_results/0000/0040/DA-WOLFM-QUALITAET-AGIL.pdf , 01.06.2011 15:42

Ingo Vogt (ORDIX AG) / "Agile Softwareentwicklung" März 2007, http://www.ordix.de/ORDIXNews/3_2007/Projektmanagement/agile_softwareentwicklung.html , 26.05.2011 9:55

Louie, Kelley / Artikel „How Scrum Works“ 05.09.2005, http://www.scrumalliance.org/articles/47-how-scrum-works , 09.06.2011 15:54

CollabNet Inc. / Artikel "Scrum Sprint", http://scrummethodology.com/scrum-sprint/ 09.06.2011 15:53

Magno, Alexandre / Artikel "The Daily Meeting Trap" 06.08.2007, http://www.scrumalliance.org/articles/62-the-daily-meeting-trap- , 09.06.2011 16:15

Manifest für Agile Softwareentwicklung, http://agilemanifesto.org/iso/de/ , 09.06.2011 16:26

Scherer, Josef / Artikel "Sprint Review", http://scrum-fibel.de/prozess/sprint%20review.html , 09.06.2011 16:48

Scherer, Josef / Artikel "Sprint Backlog", http://scrum-fibel.de/artefakte/sprint%20backlog.html 09.06.2011 10:28

Schatz, Bob / Artikel „Successful Scrum Reviews“ 21.05.2007 http://www.scrumalliance.org/articles/48-successful-sprint-reviews , 09.06.2011 16:50

Szalvay, Victor / Artikel "Glossary of Scrum Terms", 12.03.2007, http://www.scrumalliance.org/articles/39-glossary-of-scrum-terms , 09.06.2011 21:42

Wikimedia Foundation Inc., Englische Wikipedia, http://en.wikipedia.org/wiki/Scrum_%28development%29#Meetings , 09.06.2011 21:34

Deemer, Peter / Benefield, Gabrielle / Larman, Craig / Vodde, Bas: Artiel "The Scrum Primer", http://www.goodagile.com/scrumprimer/scrumprimer.pdf 10.06.2011 11:50

Sterling, Chris / Artikel "A Kaizen Mindset", http://www.gettingagile.com/2008/11/22/a-kaizen-mindset/ , 16.06.2011 21:32

5.5.2 Monographien

Andrew Pham / Phuong-Van Pham: Scrum in Action, 1. Aufl., Boston 2011

Cohn, Mike: Agile Estimating and Planning, 1. Aufl., Massachusetts 2005

Schwaber, Ken: Agile Project Management with Scrum, Microsoft Press, Redmont 2004

Koschek, Holger: Geschichten vom Scrum, dpunkt.verlag GmbH, 2010

Von „http://winfwiki.wi-fom.de/index.php/Einf%C3%BChrungshandbuch_SCRUM“
Persönliche Werkzeuge