Scrum

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche
Dieser Artikel beschreibt ein Projektmanagement-Framework. Zum gleichnamigen Gedränge im Rugby siehe Gedränge (Rugby).

Scrum (englisch für Gedränge) ist ein Vorgehens-Framework für das Projektmanagement.

Einleitung[Bearbeiten]

Scrum wurde ursprünglich in der Softwaretechnik entwickelt, ist aber unabhängig davon. Scrum wird in der Zwischenzeit in vielen anderen Domänen eingesetzt.[1] Scrum ist eine Umsetzung von Lean Development für das Projektmanagement.[2][3]

Scrum wird als Framework und bewusst nicht als Vorgehensmodell bezeichnet, da es nur aus wenigen Regeln besteht. Diese Regeln definieren fünf Aktivitäten, drei Artefakte und drei Rollen, die den Kern von Scrum ausmachen. Die Regeln sind im Agile Atlas[4] oder Scrum Guide[5] definiert. Das Scrum-Framework muss durch Techniken konkret ausgestaltet werden, um Scrum tatsächlich umsetzen zu können. Die Techniken für die Umsetzung der Aktivitäten, Artefakte und Rollen finden sich in den Büchern zu Scrum (siehe Literatur). Diese Trennung vom Kern von Scrum und den Umsetzungstechniken wurde gewählt, um einerseits die zentralen Elemente und Wirkungsmechanismen klar zu definieren (sonst ist es kein Scrum), und andererseits große Freiheiten bei der individuellen Ausgestaltung zu lassen.

Der Ansatz von Scrum ist empirisch, inkrementell und iterativ. Er beruht auf der Erfahrung, dass die meisten modernen Entwicklungsprojekte zu komplex sind, um einen vollumfänglichen Plan erstellen zu können. Dies liegt daran, dass komplexe Aufgaben dadurch charakterisiert sind, dass sowohl ein wesentlicher Teil der Anforderungen als auch der Lösungsansätze zu Beginn unklar sind. Diese Unklarheit lässt sich bei komplexen Aufgaben beseitigen, indem iterativ und inkrementell Zwischenergebnisse geschaffen werden. Anhand dieser konkreten Zwischenergebnisse lassen sich die fehlenden Anforderungen und Lösungstechniken wirtschaftlicher klären als durch eine abstrakte Klärungsphase ohne Zwischenergebnisse. In Scrum wird neben dem Produkt auch die Planung iterativ und inkrementell entwickelt. Der langfristige Plan (das Product Backlog) wird kontinuierlich detailliert und verbessert. Statt einem vollumfänglichen Plan wird in Scrum ein Detailplan (das Sprint Backlog) nur für den jeweils nächsten Zyklus (dem Sprint) erstellt. Damit wird die Projektplanung auf das wesentliche fokussiert, um dadurch im Gegenzug eine hohe Planungsdisziplin zu ermöglichen.[6]

Die empirische Verbesserung beruht dabei auf drei Säulen: [7]

  1. Transparenz: Der Fortschritt und die Hindernisse eines Projektes werden regelmäßig und für alle sichtbar festgehalten.
  2. Überprüfung: In regelmäßigen Abständen werden Produktfunktionalitäten geliefert und sowohl das Produkt als auch das Vorgehen beurteilt.
  3. Anpassung: Die Anforderungen an das Produkt, die Pläne und das Vorgehen werden nicht ein für alle Mal festgelegt, sondern kontinuierlich detailliert und angepasst (just-in-time).

Scrum reduziert die Komplexität der Aufgabe nicht, strukturiert sie aber in kleinere und weniger komplexe „Häppchen“, den Inkrementen.

Ziel ist die schnelle, kostengünstige und qualitativ hochwertige Entwicklung von Produkten entsprechend einer formulierten Vision. Die Umsetzung der Vision in das fertige Produkt erfolgt nicht durch die Aufstellung möglichst detaillierter Anforderungslisten (vgl. Lastenheft/Pflichtenheft), die dann phasenweise umgesetzt werden. In Scrum werden die Anforderungen in Form klarer Eigenschaften aus der Anwendersicht formuliert. Die Liste dieser Anforderungen ist das Product Backlog. Diese Anforderungen werden Stück für Stück in zwei bis vier Wochen langen Intervallen, sogenannten Sprints, iterativ und inkrementell umgesetzt. Am Ende eines jeden Sprints steht bei Scrum die Lieferung eines fertigen Teilprodukts (das Product Increment). Das Produktinkrement sollte in einem Zustand sein, dass es an den Kunden ausgeliefert werden kann (potentially shippable product). Im Anschluss an den Zyklus werden Produkt, Anforderungen und Vorgehen überprüft und im nächsten Sprint weiterentwickelt.[8]

Scrum ist für Teams mit einer Größe von 3 bis 9 Personen konzipiert.[9] Größere Entwicklungsprojekte oder größere Entwicklungsabteilungen benötigen ein weitergehendes Framework, das die Koordination mehrerer Teams organisiert. Wenn diese Koordination den gleichen Prinzipien wie Scrum folgt (empirische Kontrolle, iterativ und inkrementell), dann spricht man von Scaled Agile Frameworks. Diese bauen alle auf Scrum auf.[10][11]

Geschichte und Grundlegendes[Bearbeiten]

Die Anfänge von Scrum lassen sich auf Ikujirō Nonaka[12][13][14] zurückverfolgen. Damals schuf Jeff Sutherland[15] in einem Projekt für die Guiness Peat Aviation eine neue Rolle für die damaligen Projektleiter. Diese wurden zu Teammitgliedern, und ihre Rolle war eher die eines Moderators als die eines Managers. Ken Schwaber veröffentlichte auf der OOPSLA 1995 den ersten Konferenzbeitrag über Scrum. Darin schrieb Schwaber: „Scrum akzeptiert, dass der Entwicklungsprozess nicht vorherzusehen ist. Das Produkt ist die bestmögliche Software unter Berücksichtigung der Kosten, der Funktionalität, der Zeit und der Qualität.“[16]

2001 veröffentlichten Ken Schwaber und Mike Beedle[17] mit „Agile Software Development with Scrum“ das erste Buch über Scrum. 2003 folgte Schwabers „Agile Project Management with Scrum“. 2003 war auch das Jahr, in dem die ersten zertifizierten Scrum Master von Schwaber ausgebildet wurden. 2007 erschien schließlich Ken Schwabers drittes Buch, „The Enterprise and Scrum“. Darin geht es nicht mehr bloß um die Einführung von Scrum in Software-Entwicklungsteams, sondern um die Ausweitung auf das gesamte Unternehmen. Schwaber betont in dem Buch, dass Scrum Probleme nicht lösen kann, sehr wohl aber diese aufzudecken und zu lokalisieren vermag. Scrum kann daher als Aufforderung zum unternehmensweiten Umdenken verstanden werden.[18]

Parallelen zu Scrum finden sich in der so genannten Schlanken Produktion (engl. lean production), die ihren Ursprung in japanischen Unternehmen hat und eine bessere Wertschöpfung unter anderem durch stärkeres Teamworking anstrebt. Nonaka und Takeuchi führen den Erfolg solcher Unternehmen letztlich auf ein gelungenes Wissensmanagement zurück. Im westlichen Verständnis sei die Ressource „Wissen“ im Unternehmen auf Worte und Zahlen begrenzt. Wissen kann nach diesem Verständnis erworben oder antrainiert werden. Japanische Firmen hingegen sehen in dieser Art von Wissen nur die Spitze eines Eisbergs. Für sie ist Wissen in erster Linie implizit („tacit“). Dieses implizite Wissen ist subjektiv und intuitiv, es enthält unser Bild der Realität und unsere Vision für die Zukunft. Während explizites Wissen sich leicht darstellen und verarbeiten lässt, ist dies bei implizitem Wissen deutlich schwerer. Unternehmen wie Toyota oder Canon profitieren vom impliziten Wissen ihrer Mitarbeiter, indem sie hohen Wert auf die Interaktion zwischen ihren Mitarbeitern legen.[19]

Scrum lässt sich in diesem Zusammenhang als Gegenentwurf zur Befehls-und-Kontroll-Organisation verstehen, in der Mitarbeiter möglichst genaue Arbeitsanweisungen zu erhalten haben. Statt dessen baut Scrum auf hoch qualifizierte, interdisziplinär besetzte Entwicklungsteams, die zwar eine klare Zielvorgabe bekommen, für die Umsetzung jedoch allein zuständig sind. Dadurch bekommen die Entwicklungsteams den nötigen Freiraum, um ihr Wissens- und Kreativitätspotenzial in Eigenregie zur Entfaltung zu bringen.[20]

Scrum verkörpert die Werte der agilen Software-Entwicklung, die 2001 im Agilen Manifest von Ken Schwaber, Jeff Sutherland und anderen formuliert wurden:[21]

  1. Menschen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
  2. Funktionierende Software ist wichtiger als umfassende Dokumentation.
  3. Zusammenarbeit mit dem Kunden ist wichtiger als die ursprünglich formulierten Leistungsbeschreibungen.
  4. Eingehen auf Veränderungen ist wichtiger als Festhalten an einem Plan.

Rollen[Bearbeiten]

Das Scrum Framework kennt drei Rollen mit jeweils verschiedenen Verantwortungen: Product Owner, Entwicklungsteam und Scrum Master. Die Gesamtheit dieser Rollen wird als Scrum Team bezeichnet. Ein Scrum Team tritt mit vielen weiteren Rollen in der Organisation in Kontakt. Diese Rollen werden als Stakeholder (Beteiligte) bezeichnet. Fortschritt und Artefakte sind für alle Stakeholder transparent. Stakeholder dürfen bei den meisten Aktivitäten zuhören.[22][23]

Verschiedene Autoren haben argumentiert, dass weitere Rollen erwähnt werden sollten, wenn man Scrum als Management Framework verstehen will.[24] Da sich Scrum jedoch auf das Team fokussiert und kein Management Framework ist, sind diese Rollen bewusst nie in das Scrum Framework aufgenommen worden. Die drei Rollen haben sich als ausreichend für die Organisation eines Teams erwiesen. Für die Organisation größerer Einheiten und mehrerer Teams gibt es spezielle Frameworks wie das Scaled Agile Framework[25] oder Large Scaled Scrum[26]. Diese Frameworks definieren weitere Rollen, die in großen agilen Entwicklungsorganisationen benötigt werden.

Product Owner[Bearbeiten]

Der Product Owner ist für die Eigenschaften und den wirtschaftlichen Erfolg des Produkts verantwortlich. Seine Verantwortung beinhaltet die Konzeption und Mitteilung einer klaren Produktvision. Außerdem erstellt, periodisiert und erläutert er die zu entwickelnden Produkteigenschaften, und er entscheidet darüber, welche Eigenschaften am Ende eines Sprints fertiggestellt wurden. Der Product Owner gestaltet das Produkt mit dem Ziel, den wirtschaftlichen Nutzen für das eigene Unternehmen zu maximieren. Der Product Owner ist eine Person, kein Komitee. Ihm allein obliegt die Entscheidung über das Produkt, seine Eigenschaften und die Reihenfolge der Implementierung. So balanciert er Eigenschaften, Auslieferungszeitpunkte und Kosten.[27][28]

Zur Festlegung der Produkteigenschaften verwendet der Product Owner das Product Backlog. Darin trägt er in Zusammenarbeit mit dem Entwicklungsteam und den Stakeholdern die beabsichtigten Produkteigenschaften ein. Für die Formulierung der Anforderungen wird häufig die User Story Technik genutzt. Der Produkt Owner ordnet, detailliert, und aktualisiert das Product Backlog regelmäßig im Product Backlog Refinement.[29]

Als Produktverantwortlicher hält der Product Owner regelmäßig Rücksprache mit den Stakeholdern (z. B. Anwender oder Kunden), um deren Bedürfnisse und Wünsche zu verstehen. Die definitiven Entscheidungen über die Produkteigenschaften trifft aber der Product Owner. Dabei muss der er die Interessen und Anforderungen unterschiedlicher Stakeholder verstehen und abwägen.

Bei der Implementierung von Scrum passiert es häufig, dass Product Owner nicht bevollmächtigt sind, die notwendigen Entscheidungen verbindlich zu treffen. Ein weiteres Problem aus der Praxiserfahrung ist die Überlastung der Product Owner mit fremden Aufgaben.[30]

Entwicklungsteam[Bearbeiten]

Das Entwicklungsteam ist für die Lieferung der Produktfunktionalitäten in der vom Product Owner gewünschten Reihenfolge verantwortlich. Zudem trägt es die Verantwortung für die Einhaltung der vereinbarten Qualitätsstandards. Das Entwicklungsteam organisiert sich selbst, lässt sich insbesondere von niemandem, auch nicht vom Scrum Master, vorschreiben, wie es Backlogeinträge umzusetzen hat.[31] Ebenso sollte ein Entwicklungsteam in der Lage sein, das Ziel eines jeweiligen Sprints ohne größere Abhängigkeiten von außen zu erreichen. Deshalb ist eine interdisziplinäre Besetzung des Entwicklungsteams wichtig (z. B. ein Team mit Architekt, Entwickler, Tester, Dokumentationsexperte, Datenbankexperte, und so weiter). In Scrum tritt das Entwicklungsteam immer als Team auf – gute und schlechte Ergebnisse werden nie auf einzelne Teammitglieder, sondern immer auf das Entwicklungsteam als Einheit zurückgeführt. Das ideale Teammitglied ist sowohl Spezialist als auch Generalist, damit es Teamkollegen beim Erreichen des gemeinsamen Ziels helfen kann.[32]

Ein Entwicklungsteam besteht aus mindestens drei, höchstens neun Mitgliedern; es muss einerseits groß genug sein, alle benötigten Kompetenzen zu vereinigen, andererseits steigt mit wachsender Teamgröße der Koordinierungsaufwand.[33]

Zu den weiteren Aufgaben eines Entwicklungsteams zählt die Schätzung des Umfangs der Einträge im Product Backlog (im Product Backlog Refinement). Außerdem bricht das Entwicklungsteam in der Sprint Planung die für einen Sprint ausgewählten Einträge aus dem Product Backlog in Arbeitsschritte (so genannte Tasks) herunter, deren Bearbeitung in der Regel nicht länger als einen Tag dauert. Das Ergebnis ist das Sprint Backlog.

In der Implementierungsphase haben Team-Mitglieder bisweilen Schwierigkeiten, die interdisziplinären Anforderungen zu akzeptieren. So kann z. B. ein Entwickler nicht verstehen, warum er nun auch noch die Arbeit eines Testers leisten soll. Hinter diesen Anforderungen steht jedoch der Gedanke, dass ein starkes Entwicklungsteam den mannigfachen Unwägbarkeiten eines Projektes wesentlich besser gewachsen ist als eine Sammlung individueller Talente. Falls beispielsweise jemand mit einer Aufgabe nicht zurechtkommt, kann ein anderer aushelfen und so die Einhaltung des Sprint-Ziels gewährleisten. Und fällt jemand für einige Zeit aus, ist ein interdisziplinär aufgestelltes Entwicklungsteam besser in der Lage, die fehlende Expertise zu kompensieren.

Scrum Master[Bearbeiten]

Der Scrum Master ist dafür verantwortlich, dass Scrum gelingt. Dazu arbeitet er mit dem Entwicklungsteam zusammen, gehört aber meist selber nicht zu ihm. Er führt die Scrum-Regeln ein und überprüft deren Einhaltung, er moderiert die Meetings und kümmert sich um die Behebung von Störungen und Hindernissen. Dazu gehören Probleme bei der Einhaltung des Scrum Prozesses, im Entwicklungsteam (z. B. mangelnde Kommunikation und Zusammenarbeit, persönliche Konflikte) und im Scrum-Team (z. B. in der Zusammenarbeit zwischen Product Owner und Entwicklungsteam) sowie Störungen von außen (z. B. Aufforderungen der Fachabteilung zur Bearbeitung zusätzlicher Aufgaben während eines Sprints).[34]

Ein Scrum Master ist gegenüber dem Entwicklungsteam eine dienende Führungskraft. Er gibt einzelnen Team-Mitgliedern keine Arbeitsanweisungen, noch beurteilt er diese oder belangt sie disziplinarisch.[35] Der Scrum Master ist als Coach aber für den Prozess und die Beseitigung von Hindernissen verantwortlich. Unterschiedliche Teams und Situationen erfordern vom Scrum Master ein Situatives Führen.[36]

Zu Beginn einer Scrum-Implementierung ist der Scrum Master eine Vollzeitstelle, da die Umstellung der Abläufe, das Zusammenwachsen des Teams und das Einlernen der Rollen meist sehr aufwändig sind. Hierfür ist ein erfahrener Scrum Master wichtig, da er das Scrum Team in Scrum ausbildet. Ist Scrum erst einmal etabliert, kann der Scrum Master seine Rolle als Change-Manager wahrnehmen. Er hat dann die Zeit und auch die nötige Erfahrung, um Scrum im Unternehmen bekannt zu machen und die Akzeptanz dafür zu steigern.[37]

Zusammenspiel[Bearbeiten]

Das Entwicklungsteam organisiert sich selbst. Weder der Product Owner noch der Scrum Master geben vor, welches Teammitglied wann was macht und wer mit wem zusammenarbeitet. Der Scrum Master hat die Pflicht, darauf zu achten, dass keiner in diesen Selbstorganisationsprozess eingreift und das Team stört oder Verantwortlichkeiten an sich nimmt, die ihm nicht zustehen. Umgekehrt hat der Scrum Master aber auch darauf zu achten, dass alle Scrum Rollen die Pflichten, die ihnen der Prozess zuweist, auch leben.

Stakeholder[Bearbeiten]

Stakeholder sind Rollen außerhalb von Scrum. Diese Rollen werden nicht durch Scrum definiert. Die folgenden Rollen können aber helfen, die unterschiedliche Stakeholder und deren Aufgaben zu differenzieren.

Customer[Bearbeiten]

Mit Customer (Kunde) ist der Auftraggeber gemeint, dem das Produkt nach Fertigstellung zur Verfügung gestellt wird. Der Kunde kann je nach Situation sowohl die interne Fachabteilung als auch extern sein. Es ist Aufgabe des Product Owners, seinen Kunden durch Lieferung des Wunschproduktes zu begeistern. Deshalb sollten Product Owner und der Kunde für die Dauer des Projektes im engen Austausch stehen.[38] Vor Beginn der Entwicklung sollte der Product Owner ein möglichst genaues Verständnis von der Wunschvorstellung seines Kunden gewinnen. Und der Kunde sollte schon nach den ersten Sprints Gelegenheit haben, sich die neuen Funktionalitäten anzuschauen und hierzu Feedback zu geben. Schließlich ist Scrum explizit darauf ausgerichtet, dass die gewünschten Produktfunktionalitäten während der Entwicklungsphase detailliert, validiert und angepasst werden.

User[Bearbeiten]

Die Rolle des Users (Anwender) umfasst diejenigen Personen, die das Produkt benutzen. Der Anwender kann, muss aber nicht zugleich der Kunde sein. Die Rolle des Anwenders ist für das Scrum Team von besonderer Bedeutung, denn nur der Anwender kann das Produkt aus der Perspektive des Benutzers beurteilen, der die eigentliche Zielgruppe darstellt. Stakeholder wie Anwender oder Kunden sollten beim Sprint Review und beim Product Backlog Refinement hinzugezogen werden, um das Produkt ausprobieren zu lassen und Feedback darüber einzuholen.[39]

Management[Bearbeiten]

Das Management gehört ebenso wenig zum Scrum-Team wie der User und der Customer. Doch trägt es Verantwortung dafür, dass die Rahmenbedingungen für gelingendes Scrum stimmen. Dazu gehören die Bereitstellung von materiellen Ressourcen (Räumlichkeiten, Arbeitsmittel), aber auch genereller die Unterstützung für den eingeschlagenen Kurs. Das Management ist dafür verantwortlich, das Scrum-Team vor externen Arbeitsanforderungen zu schützen, adäquate personelle Besetzungen zu finden sowie den Scrum Master dabei zu unterstützen, Hindernisse auszuräumen.[40]

Sprint[Bearbeiten]

Ein Sprint ist ein Arbeitsabschnitt, in dem ein Inkrement einer Produktfunktionalität implementiert wird. Er beginnt mit einem Sprint Planning und endet mit Sprint Review und Sprint Retrospektive. Ein Sprint folgt unmittelbar auf den vorherigen. Während eines Sprints sind keine Änderungen erlaubt, die das Sprintziel beeinflussen.[41]

Ein Sprint ist ein Zeitenfenster von ein bis vier Wochen (kürzer ist besser). Alle Sprints sollten idealerweise die gleiche Länge haben, um so dem Projekt einen Takt zu geben. Ein Sprint wird niemals verlängert – er ist zu Ende wenn die Zeit um ist.[42]

Ist das Ziel eines Sprints nicht mehr zu erreichen, beispielsweise weil das Team die Komplexität falsch eingeschätzt hat oder der Produkt Owner das Produktinkrement so nicht mehr will, dann kann der Sprint vom Entwicklungsteam oder vom Product Owner abgebrochen werden. In diesem Fall wird der aktuelle Sprint mit einer Sprint Retrospektive beendet und der neue Sprint ganz normal mit Sprint Planning begonnen.[43]

Aktivitäten[Bearbeiten]

Der Scrum-Prozess

In Scrum spricht man von Ereignissen oder Aktivitäten statt von Meetings, um klar zu stellen, dass es sich um Arbeit und nicht um Sitzungen handelt. Alle Aktivitäten von Scrum haben feste Zeitfenster (Timeboxen), die nicht überschritten werden sollen.

Sprint Planning[Bearbeiten]

Im Sprint Planning werden zwei Fragen beantwortet:

  • Was kann im kommenden Sprint entwickelt werden?
  • Wie wird die Arbeit im kommenden Sprint erledigt?

Die Sprint Planung wird daher häufig in zwei Teile geteilt.

Die Sprint-Planung dauert in Summe maximal 2 Stunden je Sprint-Woche (also z. B. max. acht Stunden für einen 4-Wochen-Sprint).[44]

Sprint Planning Teil 1: Was kann im Sprint entwickelt werden?[Bearbeiten]

Der Product Owner stellt dem Entwicklungsteam die im Product Backlog festgehaltenen Produkteigenschaften vor (in der zuvor priorisierten Reihenfolge). Das Product Backlog sollte im Sprint zuvor im Product Backlog Refinement so weit vorbereitet worden sein, dass es geordnet, gefüllt und die Einträge für den nächsten Sprint geschätzt sind.

Das gesamte Scrum Team arbeitet im ersten Teil der Planung daran, ein gemeinsames Verständnis für die im Sprint zu erledigende Arbeit zu entwickeln. Dabei werden die Eigenschaften und die Akzeptanzkriterien besprochen (z. B. Einsatz oder Usability). Außerdem einigt sich der Product Owner mit dem Entwicklungsteam auf die grundsätzlichen Kriterien, die am Ende des Sprints darüber entscheiden, ob die neue Funktionalität fertig ist oder nicht (siehe Definition of Done). Ziel ist die Fertigstellung eines potentiell auslieferbaren Produkts: ein Produktinkrement, das hinreichend getestet und integriert ist, um für den Benutzer freigegeben werden zu können.

Anschließend prognostiziert das Entwicklungsteam die Anzahl der Product Backlog Einträge, die es im nächsten Sprint liefern kann. Die Entscheidung, wie viele Einträge im nächsten Sprint umgesetzt werden, liegt alleine beim Team, während die Entscheidung über die Reihenfolge alleine beim Product Owner liegt. Dadurch müssen beide konstruktiv zusammen arbeiten. Aus den ausgewählten Product Backlog Einträgen formuliert das Scrum Team gemeinsam ein zu erreichendes Sprintziel.[45][46]

Die ursprüngliche Beschreibung von Scrum verwendete den Begriff „Commitment“ (Verpflichtung) statt „Forecast“ (Prognose); dies wurde angepasst, weil dieses Verständnis häufig zu Fehlentwicklungen zulasten der Qualität führt.[47]

Sprint Planning Teil 2: Wie wird im Sprint entwickelt?[Bearbeiten]

Im zweiten Teil der Sprint Planung plant das Entwicklungsteam im Detail, welche Aufgaben („Tasks“) zum Erreichen des Sprint Ziels und zur Lieferung der prognostizierten Product Backlog Einträge notwendig sind. Die Aufgaben sollten dabei nicht länger als einen Tag dauern. Diese Planung macht des Entwicklungsteam (wobei der Product Owner für Fragen in Reichweite sein sollte). Oftmals bilden sich zur Beantwortung der Wie-Frage Kleingruppen, in denen jeweils verschiedene Aspekte (z. B. Architektur, Datenelemente, Lücken) geklärt werden.

Ergebnis ist das Sprint Backlog. Das Sprint Backlog ist der detaillierte Plan für den nächsten Sprint. Es enthält die für den Sprint geplanten Product Backlog Einträge und die Aufgaben zu deren Umsetzung. Häufig wird dafür ein Taskboard als Technik verwendet.

Daily Scrum[Bearbeiten]

Zu Beginn eines jeden Arbeitstages trifft sich das Entwicklerteam zu einem max. 15-minütigen Daily Scrum, bei dem Scrum Master und Product Owner häufig ebenfalls anwesend, jedoch nicht aktiv beteiligt sind, falls sie nicht selbst Backlogelemente bearbeiten. Zweck des Daily Scrums ist der Informationsaustausch. Im Daily Scrum werden keine Probleme gelöst – vielmehr geht es darum, sich einen Überblick über den aktuellen Stand der Arbeit zu verschaffen. Dazu hat sich bewährt, dass jedes Teammitglied mit Hilfe des Taskboards sagt, was es seit dem letzten Daily Scrum erreicht hat, was es bis zum nächsten Daily Scrum erreichen möchte, und was dabei im Weg steht.

Beim Daily Scrum kann offensichtlich werden, dass die Erledigung eines Task länger als geplant, also länger als einen Tag dauert. Dann ist es sinnvoll, den Task in kleinere Aufgaben aufzuteilen, die dann auch von anderen Mitgliedern des Entwicklungsteams übernommen werden können.

Treten beim Daily Scrum inhaltliche Fragen auf, die sich nicht innerhalb der strikten 15-Minuten-Vorgabe beantworten lassen, werden sie entweder notiert und dem Scrum Master übergeben (z. B. bei der Beseitigung von Hindernissen) oder ihre Beantwortung auf ein späteres Meeting, häufig direkt im Anschluss, verlegt.[48][49]

Sprint Review[Bearbeiten]

Das Sprint Review steht am Ende des Sprints. Hier überprüft das Scrum Team das Inkrement, um das Product Backlog bei Bedarf anzupassen. Das Entwicklungsteam präsentiert seine Ergebnisse und es wird überprüft, ob das zu Beginn gesteckte Ziel erreicht wurde. Das Scrum Team und die Stakeholder besprechen die Ergebnisse und was als nächstes zu tun ist.[50][51] Das Sprint Review wird daher auch als „Produkt-Besser-Mach-Ereignis“ bezeichnet.

Im Sprint Review ist die Beteiligung von Stakeholdern wie Kunden und Anwendern wichtig, da diese die fertige Funktionalität des Inkrements benutzen und validieren können. Hieraus ergibt sich wichtiges Feedback für die weitere Produktgestaltung. Es kann sogar passieren, dass die Funktionalität technisch einwandfrei umgesetzt wurde (sie erfüllt alle Abnahmekriterien) und dennoch aus der Perspektive des Benutzers unbrauchbar ist (z. B. weil ein Button an einer kaum auffindbaren Stelle platziert wurde). Häufig entsteht während des Reviews ein lebhafter Dialog, in dem den Anwesenden neue Funktionalitäten einfallen.

Das Ergebnis vom Sprint Review ist das vom Product Owner notierte Feedback der Stakeholder. Dies ist eine notwendige Information bei der weiteren Gestaltung des Product Backlogs im nächsten Product Backlog Refinement.

Es ist Aufgabe des Product Owners, die entwickelten Funktionalitäten zu begutachten und anhand der im Sprint Planning 1 festgelegten Bedingungen zu entscheiden, ob sie abgenommen werden können oder nicht. Dabei sollten keine Kompromisse eingegangen werden: Ein Team hat auch dann sein Ziel verfehlt, wenn es eine „fast fertige“ (aber z. B. noch nicht getestete) Funktionalität liefert. In diesem Fall kehren die nicht fertiggestellten User Stories in das Product Backlog zurück und werden vom Product Owner neu priorisiert. Die Abnahme ist aber nicht primärer Gegenstand vom Sprint Review, bei dem es vorranging um das Feedback der Stakeholder geht. Die Abnahme der Funktionalitäten des Produktinkrements wird daher häufig im Rahmen des Sprints umgesetzt.

Die Sprint-Review dauert maximal 1 Stunde je Sprint-Woche (also z. B. max. vier Stunden für einen 4-Wochen-Sprint).

Sprint Retrospektive[Bearbeiten]

Die Sprint Retrospektive steht ganz am Ende eines Sprints. Hierbei überprüft das Scrum Team seine bisherige Arbeitsweise, um sie in Zukunft effizienter und effektiver zu machen. Der Scrum Master unterstützt das Scrum Team nach guten Praktiken zu suchen und Verbesserungsmaßnahmen zu identifizieren, die im nächsten Sprint umgesetzt werden. Die Retrospektive ist eine Aktivität für das Scrum Team (incl. dem Product Owner).[52][53]

Die Sprint Retrospektive wird niemals ausgelassen, da gerade bei Problemen die Retrospektive hilft, diese in den Griff zu bekommen.

Die Retrospektive sollte in einem geschützten Raum ablaufen, um ein Gefühl der Sicherheit zu vermitteln. Dies ist notwendig, damit das Team seine Arbeitsweise offen und ehrlich überprüfen kann. Stakeholder dürfen daher nur auf Einladung dazukommen. Als Struktur für die Sprint Retrospektive haben sich fünf Phasen bewährt.

Die Verbesserungsmaßnahmen werden dokumentiert und geplant. Hierfür gibt es unterschiedliche Techniken. Einige Teams nutzen eine eigene Liste mit Hindernissen und Verbesserungsmaßnahmen (das Impediment Backlog), andere Teams nehmen Hindernisse und die entsprechenden Aktivitäten in das Sprint Backlog auf.[54]

Die Sprint Retrospektive dauert maximal 45 min. je Sprint-Woche (also z. B. max. drei Stunden für einen 4-Wochen-Sprint).

Product Backlog Refinement[Bearbeiten]

Das Product Backlog Refinement (früher auch „Grooming“ genannt) ist das Hinzufügen von Details, Schätzungen und einer Ordnung zu Einträgen im Product Backlog. Im Gegensatz zu den anderen Aktivitäten ist das Product Backlog Refinement ein fortlaufender Prozess, bei dem der Product Owner und das Entwicklungsteam gemeinsam das Product Backlog mit seinen Details und Schätzungen zu Product Backlog-Einträgen und deren Ordnung im Product Backlog weiterentwickeln.[55][56]

Das Product Backlog Refinement umfasst meist mehrere Ereignisse im Sprint, in dem das Product Backlog bearbeitet wird. Hierzu gehört:

  • Ordnen der Einträge;
  • Löschen von Einträgen, die nicht mehr wichtig sind;
  • Hinzufügen von neuen Einträgen
  • Detaillieren von Einträgen
  • Zusammenfassen von Einträgen
  • Schätzen von Einträgen
  • Planung von Releases

Für die Gestaltung des Produkts und des Product Backlogs können auch Stakeholder wertvolle Informationen liefern, indem sie z. B. dem Scrum Team erklären, wie sie sich eine Funktionalität im alltäglichen Gebrauch wünschen. Daher gibt es meistens auch Product Backlog Refinement Ereignisse zusammen mit ausgewählten Stakeholdern.[57]

Das Product Backlog Refinement sollte nicht mehr als 10% der Zeit des Entwicklungsteams in Anspruch nehmen.

Artefakte[Bearbeiten]

Product Backlog[Bearbeiten]

Das Product Backlog ist eine geordnete Auflistung von Allem, was für das Produkt benötigt wird, und es ist die alleinige Quelle für Anforderungen, die zu Anpassung des Produkts führen. Das Product Backlog ist dynamisch und wird ständig weiterentwickelt, um Anforderungen zu identifizieren, mit denen das Produkt angemessen, wettbewerbsfähig und nützlich wird. Alle Arbeit, die das Entwicklungsteam erledigt, muss seinen Ursprung im Product Backlog haben. Der Product Owner ist für die Pflege des Product Backlogs verantwortlich. Er verantwortet die Reihenfolge bzw. Priorisierung der Einträge.[58][59]

Das Product Backlog ist nie vollständig und erhebt auch nicht diesen Anspruch. Zu Beginn eines Projektes enthält es die bekannten und am besten verstandenen Anforderungen. Die Priorisierung der Eintragungen erfolgt unter Gesichtspunkten wie wirtschaftlicher Nutzen, Risiko und Notwendigkeit. Eintragungen mit der höchsten Priorisierung werden als erste im Sprint umgesetzt.[60]

Die im Product Backlog eingetragenen Anforderungen sollten nicht technik-, sondern fachlich- und anwenderorientiert sein. Eine etablierte Möglichkeit, um diese Sichtweise zu unterstützen, ist die Formulierung der Produkteigenschaften aus Anwendersicht als User Stories.

Sprint Backlog[Bearbeiten]

Das Sprint Backlog besteht aus den Product Backlog-Einträgen, die für den Sprint ausgewählt wurden. Um das Sprint Ziel zu erreichen beinhaltet das Sprint Backlog einen Plan für die Lieferung des Produktinkrements. Das Sprint Backlog ist eine Prognose des Entwicklungsteams bezüglich der möglichen Funktionalität des nächsten Inkrements und der dafür erforderlichen Arbeit.

Das Sprint Backlog ist der immer aktuelle Plan des Entwicklungsteams der für einen Sprint zu erledigenden Aufgaben. Für das Sprint Backlog wird häufig ein Taskboard genutzt, um das Sprint Backlog für alle sichtbar zu machen.

Product Increment[Bearbeiten]

Das Inkrement ist die Summe aller Product Backlog-Einträge, die während des aktuellen und allen vorangegangenen Sprints fertiggestellt wurden. Am Ende eines Sprints muss das neue Inkrement in einem nutzbarem Zustand sein und der Definition of Done entsprechen.[61]

Zusätzliche Artefakte[Bearbeiten]

Zum Kern von Scrum gehören zwei weitere Dinge, die nicht zu den eigentlichen Artefakten dazu gezählt werden, die aber als Teil von Scrum gefordert werden.

Transparenz vom Fortschritt[Bearbeiten]

Zum Kern von Scrum gehört eine Transparenz über den Fortschritt des Produkts und des Sprints – innerhalb und außerhalb des Teams. Während das Produktinkrement den Fortschritt am deutlichsten sichtbar macht, so sind dennoch andere Techniken zur Fortschrittstransparenz notwendig.[62] Im Kern von Scrum wird für die Transparenz vom Fortschritt keine spezifische Technik vorgegeben. Typischerweise werden hierzu Burndown Grafiken verwendet.

Definition of Done[Bearbeiten]

Die „Definition of Done“ ist ein gemeinsames Verständnis des Scrum Teams, unter welchen Bedingungen eine Arbeit als „Fertig“ bezeichnet werden kann. Sie enthält für gewöhnlich Qualitätskriterien, Einschränkungen und allgemeine nicht-funktionale Anforderungen. Mit zunehmender Erfahrung des Scrum Teams entwickelt sich die „Definition of Done“ weiter. Sie enthält dann strengere Kriterien für höhere Qualität.

Dazu gehört beispielsweise das Schreiben von Kommentaren, Unit Tests und Design-Dokumenten. Die DoD wird von den Beteiligten zu Beginn eines Projektes festgelegt, und wird im Laufe der Entwicklung angepasst. Die DoD hilft zu Beginn eines Sprints, die Anzahl und den Umfang der Tasks festzulegen. Es müssen aber nicht alle Aktivitäten der DoD auf jede User Story zutreffen. Am Ende des Sprints dient die DoD neben den Akzeptanzkriterien jedes Product Backlog Eintrags dazu, zu entscheiden, ob ein Product Backlog Eintrag „fertig“' akzeptiert wird.[63]

Techniken[Bearbeiten]

In der Verbindung mit Scrum werden die folgenden Techniken häufig genutzt. Diese Techniken gehören nicht zum Kern von Scrum, und zu allen Techniken gibt es mehrere Alternativen.

User Story[Bearbeiten]

User Stories sind eine Technik zur Beschreibung von Anforderungen aus der Perspektive eines Benutzers unter Verwendung von Alltagssprache. In Scrum werden User Stories zur Formulierung der Product Backlog-Einträge verwendet. Eine User Story beschreibt, welche Produkteigenschaft der Benutzer will und warum er oder sie es will.[64]

User Stories folgen im Allgemeinen diesem Muster:

Als NUTZER will ich ZIEL/WUNSCH, damit NUTZEN.

Bei einem Projekt zur Entwicklung eines städtetauglichen Elektrofahrrads könnte eine User Story demnach folgendermaßen lauten:

Als 30-jährige Geschäftsfrau möchte ich auf dem Weg zur Arbeit nur wenig in die Pedale treten müssen, damit ich nicht verschwitzt in der Firma ankomme.

Es ist Aufgabe des Product Owners und des Teams, im Product Backlog Refinement zu klären, was genau damit gemeint ist, und welches die Akzeptanzkriterien sein sollen. So könnte zum Beispiel vereinbart werden, dass bis zu einer Steigung von maximal 30 % der elektrische Antrieb so stark sein muss, dass der Fahrer nicht mehr als 100 Watt durch sein eigenes Treten beisteuern muss. Zudem muss das Entwicklungsteam mit dem Product Owner klären, ob sich diese User Story überhaupt in einem Sprint erledigen lässt oder ob sie in kleinere Stories heruntergebrochen werden muss.[65] Sobald eine User Story umgeschrieben oder um weitere Information ergänzt wird, werden auch diese Änderungen im Product Backlog festgehalten.[66]

Fragen nach dem „Wie“, also nach der technischen Umsetzung einer User Story, gehören ins Sprint Planning 2 und werden nicht im Product Backlog, sondern im Taskboard mit Hilfe der einzelnen Tasks festgehalten.

Taskboard[Bearbeiten]

Das Taskboard ist eine Technik zur Visualisierung des Sprint Backlogs. Darauf lässt sich jederzeit erkennen, welche Product Backlog Einträge für den Sprint ausgewählt wurden, welche Aufgaben dazu zu bearbeiten sind, und in welchen Bearbeitungszustand diese Aufgaben sind. Das Taskboard ist eine Kanban-Tafel.

Typischerweise besteht das Taskboard aus vier Spalten. In der ersten Spalte „Anforderungen“ werden die Product Backlog Einträge aufgehängt, für die das Entwicklungsteam für diesen Sprint ausgewählt hat (in der vom Product Owner priorisierten Reihenfolge). Die drei weiteren Spalten enthalten die Aufgaben oder Tasks, die zur Umsetzung der jeweiligen Anforderung notwendig sind in ihrem jeweiligen Bearbeitungszustand. Die erste Spalte („Zu Tun“) enthält alle noch zu erledigen Aufgaben, die zweite Spalte diejenigen in Bearbeitung („In Arbeit“), und die dritte Spalte alle erledigten („Fertig“).

Im Daily Scrum erklärt jedes Mitglied des Entwicklungsteams anhand des Taskboards, an welcher Aufgabe es am Vortag gearbeitet hat, und ob diese erledigt wurde. Tasks, die an einem Tag nicht beendet werden konnten oder bei denen Hindernisse den Fortschritt aufhalten, werden markiert (z. B. mit einem roten Punkt). In diesem Fall sollten die Aufgaben zur Beseitigung des Hindernisses in das Taskboard aufgenommen werden. So können Hindernisse schnell identifiziert und die Beseitigungsmaßnahmen transparent gemacht werden.[67]

Impediment Backlog[Bearbeiten]

Das Impediment-Backlog ist eine Technik, mit der Scrum Master öffentlich alle Arbeitsbehinderungen sammelt. Es handelt sich um eine Liste von Hindernissen, Aufgaben zu ihrer Lösung und ihrem aktuellen Status. Eine andere Technik ist es, Behinderungen und die Beseitigungsmaßnahmen auf dem Taskboard mit zu pflegen.

Fünf Phasen einer Retrospektive[Bearbeiten]

Als Struktur einer Sprint Retrospektive haben sich fünf Phasen bewährt[68]: Zuerst werden die Voraussetzungen für eine offene Atmosphäre geschaffen. Die Teilnehmer sollen sich wohl dabei fühlen, offene Punkte zu diskutieren. Dabei gilt, dass jeder die bestmögliche Arbeit geleistet hat, die er oder sie leisten konnte, und zwar unabhängig davon, welche offenen Punkte identifiziert werden. Zweitens werden Informationen gesammelt. Dies geschieht oft, indem man zurückblickt und identifiziert, was gut gelaufen ist und was nicht. Im dritten Schritt werden Erkenntnisse entwickelt. In dieser Phase identifizieren Teams normalerweise, warum Dinge geschehen sind, damit nicht nur Maßnahmen für die Symptome entwickelt, sondern die tatsächlichen Ursachen identifiziert werden. Viertens entscheidet man, was zu tun ist. Das umfasst Entscheidungen über konkrete, sinnvolle, vereinbarte und realistische Schritte, die im nächsten Sprint umgesetzt werden sollen. Zu guter Letzt wird die Retrospektive abgeschlossen.

Für die Gestaltung der fünf Schritte gibt es eine Vielzahl von möglichen Vorgehensweisen (siehe den Weblink zu einer Webseite mit Retrospektiven-Techniken).

Burndown Chart[Bearbeiten]

Beispiel eines Sprint Burndown Charts

Das Burndown Chart dient der Visualisierung bereits geleisteter und noch verbleibender Arbeit. Das Burndown Chart gibt es in zwei Varianten:

  • Als Sprint Burndown wird es zur Verfolgung vom Sprintfortschritt verwendet.
  • Als Release Burndown wird es zur Verfolgung vom Produktfortschritt über mehrere Sprints hinweg verwendet.

Beim Sprint Burndown wird auf der x-Achse der Zeitverlauf in Tagen und auf der y-Achse die Anzahl der noch zu erledigenden Tasks aufgetragen. So ergibt sich eine fallende Linie von offenen Aufgaben, die im Idealfall am Sprintende die Nulllinie trifft. Über das Sprint Burndown ist es möglich, die Erreichung des Sprint-Ziels besser abzuschätzen. Das Entwicklungsteam aktualisiert im Daily Scrum das Sprint Burndown.

Alternativ können beim Sprint Burndown statt der Anzahl der Tasks auch die Summe der geschätzten Aufwände für jeden einzelnen Task (in Stunden) eingetragen werden. Dies erfordert jedoch eine Schätzung der Restaufwände für alle Tasks, so dass diese Variante deutlich mehr Aufwand ist. Da die Genauigkeit (bei Tasks mit einem Aufwand von maximal einem Tag) durch Aufwandsschätzungen nur geringfügig besser wird, hat sich das Zählen der Tasks bei vielen Teams durchgesetzt.

Beim Release Burndown wird auf der x-Achse der Zeitverlauf in Sprints und auf der y-Achse die Anzahl der Umfang der noch zu erledigenden Product Backlog Einträge aufgetragen (z. B. in Story Points). Eine Änderung des Umfangs vom Product Backlog wird unterhalb der x-Achse eintragen. Bei jedem Sprint aktualisiert der Product Owner das Release Burndown auf Grundlage der Geschwindigkeit und der Schätzungen des Entwicklungsteams. Mit Hilfe des Release Burndowns kann der Product Owner Umfang und Liefertermin des aktuelles Releases bestimmen.[69]

Die Grenzen und Nachteile von Scrum[Bearbeiten]

Keine Erfolgsgarantie[Bearbeiten]

Scrum kann genau so wenig wie andere Prozesse und Vorgehensmodelle eine Erfolgsgarantie bieten. Die Anwendung von Scrum erzeugt Transparenz sowie regelmäßige Produktlieferungen. Hindernisse werden sichtbar und das Produkt kann Schritt für Schritt entwickelt und bei Bedarf geändert werden.

Verwertung gewonnener Erkenntnisse[Bearbeiten]

Bei der Verwendung von Scrum muss man sich darauf einstellen, dass die ursprünglichen Einschätzungen permanent über- oder untertroffen werden. Scrum zeigt vom ersten Tag an Abweichungen vom Soll-Zustand an. Ob Scrum dazu führt, dass Produkte schnell, gut, günstig oder qualitativ hochwertig entwickelt werden, hängt davon ab, was das Scrum-Team mit den gewonnenen Erkenntnissen macht. Nach Schwaber kann auch ein Team von Idioten nach Scrum arbeiten.[70] Das Team liefert am Ende jedes Sprints zuverlässig Produktinkremente, hält alle Meetings ab, und verteilt die Rollen nach Scrum. Wenn aber das Scrum-Team die Ergebnisse nicht nutzt, um anders zu arbeiten und Anpassungen vorzunehmen, wird auch das Produkt nicht besser oder früher fertig sein.

Hinderliche Einflüsse bei der Teamzusammensetzung[Bearbeiten]

Die Implementierung von Scrum kann durch verschiedene Faktoren behindert werden. Die Selbstorganisation im Entwicklungsteam beinhaltet den Grundsatz, dass es im Team keine permanente Hierarchie geben darf. Mitglieder, die nicht bereit sind, ihre bisherige Position innerhalb des Entwicklungsteams aufzugeben, können daher zu Konflikten führen. Zudem sollte ein Entwicklungsteam ausreichend interdisziplinär ausgebildet sein, um möglichst viele Aufgaben ohne externe Hilfe zu bearbeiten. Auch bei umfangreichen und vielschichtigen Projekten wird von Scrum gefordert, dass prinzipiell alle Teammitglieder alle Aufgaben eines Sprints bearbeiten können. Somit passt jemand, der sich exklusiv als Tester, Programmierer oder Architekt sieht, nicht optimal in ein Entwicklungsteam nach Scrum: Ein gutes Team kann das berücksichtigen und die Nachteile kompensieren; für ein weniger erfahrenes Team können solche Mitarbeiter aus Scrum-Sicht schwierig sein.

Juristische Erwägungen[Bearbeiten]

Auch vor einem juristischen Hintergrund (z. B. Produkthaftungsgesetz) kann die Anwendung von Scrum im Rahmen von Werkverträgen begrenzt sein. Es besteht eine stärkere Unschärfe über die zu erbringende Leistung und deren Abnahmekriterien als bei traditionellen Vorgehensweisen. Bei Streitigkeiten kann dies dazu führen, dass keine eindeutige Aussage zur Vertragserfüllung getroffen werden kann. In der Fachliteratur werden Vorschläge angeboten, wie Werkverträge für Scrum-Projekte zu gestalten sind.[71][72]

Zertifizierung[Bearbeiten]

Für Scrum gibt es zwei große Organisationen die eine Zertifizierung anbieten.[73]

Scrum Alliance[Bearbeiten]

Die Basiszertifizierungen werden unterteilt in CSM (Certified ScrumMaster), CSPO (Certified Scrum Product Owner) und CSD (Certified Scrum Developer). Für diese Zertifizierungen ist der Besuch eines Seminars eines zertifizierten Trainers erforderlich.[74]

Darauf aufbauend ist die weiterführende Zertifizierung zum CSP (Certified Scrum Professional) möglich, die eine mehrjährige Erfahrung und den Nachweis von 70 Stunden zertifizierten Trainings erfordert. Bis 2013 war anstatt des Trainingsnachweises eine dreistündige Prüfung abzulegen.[74]

Die Seminare werden durch zertifizierte Trainer (CST, Certified Scrum Trainer) gehalten, die dies meist hauptberuflich durchführen. Besonders erfahrene Trainer mit Coaching-Qualifikation erhalten die Zertifizierung zum CSC (Certified Scrum Coach).[74]

Scrum.org[Bearbeiten]

Die Einstiegszertifizierung ist das kostenlose Scrum Open assessment, welches Grundlage für den Professional Scrum Master (PSM I und PSM II), Professional Scrum Developer (PSD I) und Professional Scrum Product Owner (PSPO I und PSPO II) ist.[75]

Tools[Bearbeiten]

Es gibt diverse Tools wie Agilo, Pangoscrum, Redmine (verschiedene Plugins verfügbar), OpenProject, AgileZen, Agile Manager, Tinypm, ThoughtWorks Studios, Jira Agile, Pivotal Tracker, Scrumwise, VersionOne, ScrumWorks Pro, Banana Scrum, Team Foundation Server und ScrumTable, die darauf ausgelegt sind, die Einführung von Scrum und die darin anfallenden Prozesse zu erleichtern.

Literatur[Bearbeiten]

  • Rolf Dräther, Holger Koschek und Carsten Sahling: Scrum – kurz & gut. 1. Auflage, O’Reilly, 2013, ISBN 978-3-86899-833-7
  •  Malte Foegen: Der Ultimative Scrum Guide 2.0. 2. Auflage. wibas, Darmstadt 2014, ISBN 978-3-981-58375-5.
  • Boris Gloger: Scrum-Produkte zuverlässig und schnell entwickeln. 3. Auflage, Hanser Verlag, 2011, ISBN 978-3-446-42524-8
  • Boris Gloger: Scrum: Der Paradigmenwechsel im Projekt- und Produktmanagement. Eine Einführung. In: Informatik Spektrum, Vol. 33, No. 2. 2010.
  • Arndt Hengstler: Gestaltung der Leistungs- und Vertragsbeziehung bei Scrum-Projekten. In: ITRB 2012, 113–116.
  • Holger Koschek: Geschichten vom Scrum: Von Sprints, Retrospektiven und agilen Werten. dpunkt.verlag, 2009, ISBN 978-3-89864-640-6
  • Ken Schwaber: Scrum Development Process, Advanced Development Methods, 131 Middlesex Turnpike Burlington, MA01803
  •  Ken Schwaber: Agiles Projektmanagement mit Scrum. Microsoft Press Deutschland, 4. Oktober 2007 (Originaltitel: Agile Project Management with Scrum, übersetzt von Thomas Irlbeck), ISBN 978-3-86645-631-0.
  •  Ken Schwaber: Scrum im Unternehmen. Microsoft Press Deutschland, 14. April 2008 (Originaltitel: The Enterprise and Scrum), ISBN 978-3-86645-643-3.
  •  Ken Schwaber, Jeff Sutherland: Software in 30 Tagen. dpunkt.verlag, 18. Dezember 2013 (Originaltitel: Software in 30 days), ISBN 978-3864900747.

Weblinks[Bearbeiten]

Einzelnachweise[Bearbeiten]

  1. Scrum Alliance: The State of Scrum, S. 10 (abgerufen am 28. Juni 2014).
  2. Mary Poppendieck, Tom Poppendieck: Lean Software Development: An Agile Toolkit, Addison-Wesley, Upper Saddle River, 2003.
  3. Malte Foegen: Der Ultimative Scrum Guide 2.0, wibas, Darmstadt 2014, S. 50–51.
  4. Scrum Alliance: Agile Atlas, abgerufen am 28. Juni 2014.
  5. Ken Schwaber and Jeff Sutherland: The Scrum Guide, abgerufen am 23. März 2014.
  6. Malte Foegen: Der Ultimative Scrum Guide, wibas, Darmstadt 2014, S. 112–113.
  7. Ken Schwaber and Jeff Sutherland: The Scrum Guide, S. 4.
  8. Boris Gloger: Scrum. Produkte zuverlässig und schnell entwickeln. 3. Auflage, Hanser Verlag, München 2011, S. 12.
  9. Ken Schwaber and Jeff Sutherland: The Scrum Guide, S. 6.
  10. Dean Leffingwell: Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development), Addison-Wesley, Boston 2010.
  11. Craig Larman, Bas Vodde: Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley, Boston 2010.
  12. „The New New Product Development Game“. Cb.hbsp.harvard.edu, 1. Januar 1986.
  13. Nonaka I, Takeuchi H.: The Knowledge-Creating Company. Oxford University Press, 1995.
  14. Peter DeGrace, Leslie Hulet Stahl: Wicked Problems, Righteous Solutions: A Catolog of Modern Engineering Paradigms, 1998.
  15. Jeff Sutherland. Abgerufen am 21. Oktober 2011.
  16. Boris Gloger: Scrum. Produkte zuverlässig und schnell entwickeln. 3. Auflage, Hanser Verlag, München 2011, S. 19.
  17. Mike Beedle. Abgerufen am 21. Oktober 2011.
  18. Ken Schwaber: Scrum im Unternehmen. Microsoft Press Deutschland 2008, S. XI-XII.
  19. Ikujiro Nonaka u. Hirotaka Takeuchi: A Theory of the Firm’s Knowledge-Creation Dynamics. In: Alfred Chandler et al. (Hrsg.): The Dynamic Firm. The Role of Technology, Strategy, Organization, and Regions. Oxford University Press, 2008, S. 215–216.
  20. Boris Gloger: Scrum. Produkte zuverlässig und schnell entwickeln. 3. Auflage, Hanser Verlag, München 2011, S. 27–30.
  21. Scrum Code of Ethics
  22. Scrum Alliance: Agile Atlas, V 2012.12.13, S. 4-6
  23. Ken Schwaber and Jeff Sutherland: The Scrum Guide, S. 4–6.
  24. Boris Gloger, Scrum – Produkte zuverlässig und schnell entwickeln, Hanser, 4. Auflage, 2013
  25. Dean Leffingwell: Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development), Addison-Wesley, Boston 2010.
  26. Craig Larman, Bas Vodde: Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley, Boston 2010.
  27. Ken Schwaber and Jeff Sutherland: The Scrum Guide. Abgerufen am 23. März 2014. Seite 5
  28. Scrum Alliance: Agile Atlas, V 2012.12.13, S. 4.
  29. Boris Gloger: Scrum. Produkte zuverlässig und schnell entwickeln. 3. Auflage, Hanser Verlag, München 2011, S. 78–87.
  30. Roman Pichler: Scrum – Agiles Projektmanagement erfolgreich einsetzen. d.punkt Verlag, Heidelberg 2009, S. 10–13.
  31. Jeff Sutherland, Ken Schwaber: The Scrum Guide (July 2013). Abschnitt The Development Team.
  32. Roman Pichler: Scrum – Agiles Projektmanagement erfolgreich einsetzen. d.punkt Verlag, Heidelberg 2009, S. 15.
  33. Jeff Sutherland, Ken Schwaber: The Scrum Guide (July 2013). Abschnitt Development Team Size
  34. Scrum Alliance: Agile Atlas, S. 5.
  35. Roman Pichler: Scrum – Agiles Projektmanagement erfolgreich einsetzen. d.punkt Verlag, Heidelberg 2009, S. 20–23.
  36. Malte Foegen: Der Ultimative Scrum Guide 2.0, wibas, 2014, S. 62–65.
  37. Boris Gloger: Scrum. Produkte zuverlässig und schnell entwickeln. 3. Auflage, Hanser Verlag, München 2011, S. 88–101.
  38. Boris Gloger: Scrum. Produkte zuverlässig und schnell entwickeln. 3. Auflage, Hanser Verlag, München 2011, S. 101–103.
  39. Scrum Alliance: Agile Atlas, V 2012.12.13, S. 10
  40. Boris Gloger: Scrum. Produkte zuverlässig und schnell entwickeln. 3. Auflage, Hanser Verlag, München 2011, S. 104–107.
  41. Ken Schwaber and Jeff Sutherland: The Scrum Guide, S. 7 f.
  42. Scrum Alliance: Agile Atlas, V 2012.12.13, S. 3
  43. Ken Schwaber and Jeff Sutherland: The Scrum Guide, S. 8.
  44. Ken Schwaber and Jeff Sutherland: The Scrum Guide, S. 9.
  45. Ken Schwaber and Jeff Sutherland: The Scrum Guide, S. 8–9.
  46. Scrum Alliance: Agile Atlas, V 2012.12.13, S. 7–8.
  47. Jose Luis Soria Teruel: Commitment vs. Forecast: A subtle but important change to Scrum. Abgerufen am 18. Januar 2013.
  48. Jeff Sutherland, Ken Schwaber: The Scrum Guide (July 2013). Abschnitt Daily Scrum
  49. Roman Pichler: Scrum. Agiles Projektmanagement erfolgreich einsetzen. dpunkt.verlag, Heidelberg 2009, S. 104–107.
  50. Ken Schwaber and Jeff Sutherland: The Scrum Guide, S. 11.
  51. Scrum Alliance: Agile Atlas, V 2012.12.13, S. 10–11.
  52. Ken Schwaber and Jeff Sutherland: The Scrum Guide, S. 11–12.
  53. Scrum Alliance: Agile Atlas, V 2012.12.13, S. 11.
  54. Malte Foegen: Der Ultimative Scrum Guide 2.0, wibas, Darmstadt 2014, S. 140–141.
  55. Ken Schwaber and Jeff Sutherland: The Scrum Guide, S. 13.
  56. Scrum Alliance: Agile Atlas, V 2012.12.13, S. 6–7.
  57. Malte Foegen: Der Ultimative Scrum Guide 2.0, wibas, Darmstadt 2014, S. 92–93 und 96–97.
  58. Ken Schwaber and Jeff Sutherland: The Scrum Guide, S. 12–13.
  59. Scrum Alliance: Agile Atlas, V 2012.12.13, S. 6.
  60. Jeff Sutherland, Ken Schwaber: The Scrum Guide, S. 12–13.
  61. Scrum Alliance: Agile Atlas, V 2012.12.13, S. 9
  62. Scrum Alliance: Agile Atlas, V 2012.12.13, S. 9
  63. Scrum Alliance: Agile Atlas, V 2012.12.13, S. 9-10
  64. Roman Pichler: Scrum – Agiles Projektmanagement erfolgreich einsetzen. d.punkt Verlag, Heidelberg 2009, S. 46–47.
  65. Malte Foegen: Der Ultimative Scrum Guide 2.0, wibas, Darmstadt 2014, S. 104–105.
  66. Roman Pichler: Scrum – Agiles Projektmanagement erfolgreich einsetzen. d.punkt Verlag, Heidelberg 2009, S. 46–47.
  67. Boris Gloger: Scrum. Produkte zuverlässig und schnell entwickeln. 3. Auflage, Hanser Verlag, München 2011, S. 167–169.
  68. Esther Derby, Diana Larsen: Agile Retrospectives: Making Good Teams Great. Pragmatic Programmers, 2006.
  69. Malte Foegen: Der Ultimative Scrum Guide 2.0, wibas, Darmstadt 2014, S. 148–151.
  70. Ken Schwaber: Scrum et al. (Minute 14) Abgerufen am 12. August 2011.
  71. Tom Arbogast, Craig Larman, Bas Vodde: Practices for Scaling Lean & Agile Development. Addison-Wesley Longman, Amsterdam 2010, ISBN 978-0-32163-640-9, S. 499 ff. (PDF).
  72.  Andreas Opelt, Boris Gloger, Wolfgang Pfarl, Ralf Mittermayr: Der agile Festpreis: Leitfaden für wirklich erfolgreiche IT-Projekt-Verträge. Carl Hanser Verlag, 6. Dezember 2012, ISBN 978-3-44643-226-0.
  73. Horst Peterjohann: Agile Personen-Zertifizierungen: Möglichkeiten und Vergleiche, OBJEKTspektrum 05/2012, Abgerufen am 7. April 2014.
  74. a b c Scrum Alliance, Abgerufen am 29. August 2014
  75. Scrum.org, Assessments & Certifications, Abgerufen am 7. April 2014