Scrum
Scrum (englisch für „Gedränge“) ist ein Vorgehensmodell des Projekt- und Produktmanagements, insbesondere zur agilen Softwareentwicklung. Es wurde ursprünglich in der Softwaretechnik entwickelt, ist aber davon unabhängig. Scrum wird inzwischen in vielen anderen Bereichen eingesetzt.[1] Es ist eine Umsetzung von Lean Development für das Projektmanagement.[2][3]
Geschichte und Grundlegendes
Die Anfänge von Scrum lassen sich auf Ikujirō Nonaka und Hirotaka Takeuchi[4][5][6] zurückverfolgen. Inspiriert von deren Erkenntnissen schuf Jeff Sutherland[7] eine neue Rolle für die Projektleiter. Diese wurden zu Teammitgliedern, und ihre Rolle war eher die eines Moderators als die eines Managers. Zusammen mit Ken Schwaber formalisierte er Scrum ab 1993.[8] Dabei wurde Scrum durch die Theory of Constraints und das Toyota 3M Modell (Muda, Mura, Muri) beeinflusst, die Idee eines Daily Meetings stammt von James Coplien.[9][10] Auf der OOPSLA 1995 wurde dann der erste Konferenzbeitrag über Scrum veröffentlicht. 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.“[11] Der Begriff Scrum stammt aber von Nonaka und Takeuchi, die damit das Gedränge (englisch scrum) im Rugby als Analogie für außergewöhnlich erfolgreiche Produktentwicklungsteams beschrieben. Diese Teams arbeiten als kleine, selbst-organisierte Einheiten und bekommen von außen nur eine Richtung vorgegeben, bestimmen aber selbst die Taktik, wie sie ihr gemeinsames Ziel erreichen.[12]
2002 veröffentlichte Ken Schwaber mit Mike Beedle, einem der ersten Scrum-Anwender, mit Agile Software Development with Scrum das erste Buch über Scrum, 2004 folgte Schwabers Agile Project Management with Scrum.[13] 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.[14] Spätestens seit der ersten jährlichen Umfrage von VersionOne (2006) ist Scrum die gängigste agile Methode.[15]
Parallelen zu Scrum finden sich in der schlanken Produktion (englisch lean production), die ihren Ursprung in japanischen Unternehmen hat. Sie strebt eine bessere Wertschöpfung durch verstärkte Zusammenarbeit an. Nonaka und Takeuchi führen den Erfolg solcher Unternehmen auf ein gelungenes Wissensmanagement zurück. Im westlichen Verständnis sei die Ressource Wissen 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.[16]
Scrum lässt sich in diesem Zusammenhang als Gegenentwurf zur Befehls-und-Kontroll-Organisation verstehen, in der Mitarbeiter möglichst genaue Arbeitsanweisungen erhalten. Stattdessen baut Scrum auf hochqualifizierte, 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.[17]
Scrum verkörpert die Werte der agilen Software-Entwicklung, die 2001 im agilen Manifest von Ken Schwaber, Jeff Sutherland und anderen formuliert wurden:[18]
- Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
- Funktionierende Software ist wichtiger als umfassende Dokumentation.
- Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.
- Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans.
Scrum besteht aus nur wenigen Regeln. Diese beschreiben vier Ereignisse, drei Artefakte und drei Rollen (Verantwortlichkeiten), die den Kern (englisch core) ausmachen. Die Regeln sind im Scrum Guide beschrieben, es gibt eine weitere Kurzdarstellung im Agile Atlas.[19][20] Das Scrum-Framework muss durch Techniken für die Umsetzung der Ereignisse, Artefakte und Rollen konkretisiert werden, um Scrum tatsächlich umsetzen zu können. Der Kern von Scrum wurde von den Umsetzungstechniken getrennt, um einerseits die zentralen Elemente und Wirkungsmechanismen klar zu definieren, andererseits um große Freiheiten bei der individuellen Ausgestaltung zu lassen.
Der Ansatz von Scrum ist empirisch, inkrementell und iterativ. Er beruht auf der Erfahrung, dass viele Entwicklungsprojekte zu komplex sind, um in einen vollumfänglichen Plan gefasst werden zu können. Ein wesentlicher Teil der Anforderungen und der Lösungsansätze ist zu Beginn unklar. Diese Unklarheit lässt sich beseitigen, indem Zwischenergebnisse geschaffen werden. Anhand dieser Zwischenergebnisse lassen sich die fehlenden Anforderungen und Lösungstechniken effizienter finden als durch eine abstrakte Klärungsphase. In Scrum wird neben dem Produkt auch die Planung iterativ und inkrementell entwickelt. Der langfristige Plan (das Product Backlog) wird kontinuierlich verfeinert und verbessert. Der Detailplan (das Sprint Backlog) wird nur für den jeweils nächsten Zyklus (den Sprint) erstellt. Damit wird die Projektplanung auf das Wesentliche fokussiert.[21]
Die empirische Verbesserung fußt auf drei Säulen:[20]
- Transparenz: Fortschritt und Hindernisse eines Projektes werden regelmäßig und für alle sichtbar festgehalten.
- Überprüfung: Projektergebnisse und Funktionalitäten werden regelmäßig abgeliefert und bewertet.
- Anpassung: Anforderungen an das Produkt, Pläne und Vorgehen werden nicht ein für alle Mal festgelegt, sondern kontinuierlich und detailliert angepasst. Scrum reduziert die Komplexität der Aufgabe nicht, strukturiert sie aber in kleinere und weniger komplexe Bestandteile, die Inkremente.
Ziel ist die schnelle und kostengünstige Entwicklung hochwertiger Produkte entsprechend einer formulierten Vision. Die Umsetzung der Vision in das fertige Produkt erfolgt nicht durch die Aufstellung möglichst detaillierter Lasten- und Pflichtenhefte. In Scrum werden die Anforderungen in Form von Eigenschaften aus der Anwendersicht formuliert. Die Liste dieser Anforderungen ist das Product Backlog. Diese Anforderungen werden Stück für Stück in ein bis vier Wochen langen Intervallen, sogenannten Sprints umgesetzt. Am Ende eines 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.[22]
Scrum ist für Teams mit einer Größe von drei bis neun Entwicklern konzipiert.[23] Größere Projekte benötigen ein weitergehendes Framework, das die Koordination mehrerer Teams organisiert. Wenn diese Koordination den gleichen Prinzipien wie Scrum folgt, dann spricht man von Scaled Agile Frameworks.[24][25]
Verantwortlichkeiten
Das Scrum Framework kennt drei Führungsverantwortungen: Product Owner, Entwickler und Scrum Master. Die Gesamtheit dieser Verantwortlichkeiten wird als Scrum-Team bezeichnet. Ein Scrum-Team tritt mit den Beteiligten in Kontakt, den sogenannten Stakeholdern. Fortschritt und Zwischenergebnisse sind für alle Stakeholder transparent. Stakeholder dürfen bei den meisten Ereignissen zuhören.[26][20]
Verschiedene Autoren haben argumentiert, dass weitere Rollen einbezogen werden sollten, wenn man Scrum als Management-Framework verstehen will.[27] Da sich Scrum jedoch auf das Team fokussiert und kein Management-Framework ist, sind diese Rollen nicht in das Scrum Framework aufgenommen worden. Die drei Verantwortlichkeiten 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[28] oder Large Scale Scrum.[29] Diese Frameworks definieren weitere Rollen, die in großen agilen Entwicklungsorganisationen benötigt werden.
Product Owner
Der Product Owner ist für die Eigenschaften und den wirtschaftlichen Erfolg des Produkts verantwortlich. Er gestaltet das Produkt mit dem Ziel, seinen Nutzen zu maximieren. Der Nutzen könnte sich beispielsweise am Umsatz des Unternehmens orientieren. Er erstellt, priorisiert und erläutert die zu entwickelnden Produkteigenschaften, und er urteilt darüber, welche Eigenschaften am Ende eines Sprints fertiggestellt wurden. Er ist eine Person, kein Komitee. Ihm allein obliegt die Entscheidung über das Produkt, seine Eigenschaften und die Reihenfolge der Implementierung. So balanciert sie Eigenschaften, Auslieferungszeitpunkte und Kosten.[30][31]
Zur Festlegung der Produkteigenschaften verwendet der Product Owner das Product Backlog. Darin trägt er in Zusammenarbeit mit dem Entwicklungsteam und den Stakeholdern die Anforderungen an das Produkt ein. Der Product Owner ordnet, priorisiert, detailliert und aktualisiert das Product Backlog regelmäßig im Product Backlog Refinement.[32]
Als Produktverantwortlicher hält der Product Owner regelmäßig Rücksprache mit den Stakeholdern, um deren Bedürfnisse und Wünsche zu verstehen. Dabei muss er die Interessen und Anforderungen unterschiedlicher Stakeholder verstehen und abwägen.
In der Praxis erhalten Product Owner häufig nicht die Vollmacht, die notwendigen Entscheidungen verbindlich zu treffen – abweichend von der Rollenkompetenz, die in Scrum eigentlich vorgesehen ist. Häufig werden Product Owner auch mit fremden Aufgaben überlastet.[33]
Entwickler
Die Entwickler sind für die Lieferung der Produktfunktionalitäten in der vom Product Owner gewünschten Reihenfolge verantwortlich. Zudem tragen sie die Verantwortung für die Einhaltung der vereinbarten Qualitätsstandards. Das Scrum-Team organisiert sich selbst. Es lässt sich von niemandem, auch nicht vom Scrum Master, vorschreiben, wie es Backlogeinträge umzusetzen hat.[20]
Ein Scrum-Team sollte in der Lage sein, das Ziel eines jeweiligen Sprints ohne größere äußere Abhängigkeiten zu erreichen. Deshalb ist eine interdisziplinäre Besetzung des Scrum-Teams wichtig, z. B. mit Architekt, Entwickler, Tester, Dokumentationsexperte und Datenbankexperte. Gute und schlechte Ergebnisse werden nie auf einzelne Teammitglieder, sondern immer auf das Scrum-Team als Einheit zurückgeführt. Das ideale Teammitglied ist sowohl Spezialist als auch Generalist, damit es Teamkollegen beim Erreichen des gemeinsamen Ziels helfen kann.[34]
Ein Scrum-Team besteht aus höchstens zehn Mitgliedern. Es muss einerseits groß genug sein, alle benötigten Kompetenzen zu vereinigen, andererseits steigt mit wachsender Teamgröße der Koordinierungsaufwand.[23]
Zu den weiteren Aufgaben eines Scrum-Teams zählt die Schätzung des Umfangs der Einträge im Product Backlog (im Product Backlog Refinement). Außerdem bricht das Scrum-Team in der Sprint Planung die für einen Sprint ausgewählten Einträge aus dem Product Backlog in Arbeitsschritte, sogenannte Tasks, herunter, deren Bearbeitung in der Regel nicht länger als einen Tag dauert. Das Ergebnis ist das Sprint Backlog.
Team-Mitglieder haben bisweilen Schwierigkeiten, die interdisziplinären Anforderungen zu akzeptieren. So mag beispielsweise ein Entwickler nicht verstehen, warum er auch die Arbeit eines Testers leisten soll. Dahinter steht jedoch der Gedanke, dass ein starkes Team den Unwägbarkeiten eines Projektes wesentlich besser gewachsen ist als eine Sammlung individueller Talente. Falls jemand mit einer Aufgabe nicht zurechtkommt, kann ein anderer helfen, das Sprint-Ziel zu erreichen. Fällt jemand für einige Zeit aus, so ist ein interdisziplinäres Team besser in der Lage, die fehlende Expertise zu kompensieren.
Scrum Master
Der Scrum Master ist dafür verantwortlich, dass Scrum als Rahmenwerk gelingt. Dazu arbeitet er mit dem Entwicklungsteam zusammen, gehört aber selbst nicht dazu. Er führt die Scrum-Regeln ein, überprüft deren Einhaltung und kümmert sich um die Behebung von Störungen und Hindernissen. Dazu gehören mangelnde Kommunikation und Zusammenarbeit sowie persönliche Konflikte im Entwicklungsteam, Störungen in der Zusammenarbeit zwischen Product Owner und Entwicklungsteam sowie Störungen von außen, beispielsweise Aufforderungen der Fachabteilung zur Bearbeitung zusätzlicher Aufgaben während eines Sprints.[35] Der Scrum Master moderiert die Sprint Retrospektive und oft auch das Sprint Planning und Backlog Refinement.
Ein Scrum Master ist gegenüber dem Entwicklungsteam eine dienende Führungskraft.[36] Er gibt einzelnen Team-Mitgliedern keine Arbeitsanweisungen. Weder beurteilt er sie, noch belangt er sie disziplinarisch.[37] Der Scrum Master ist als Coach für den Prozess und die Beseitigung von Hindernissen verantwortlich. Unterschiedliche Teams und Situationen erfordern vom Scrum Master ein situatives Führen.[38]
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 aufwändig sind. Er bildet das Team in Scrum aus. 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 dessen Akzeptanz zu steigern.[39]
Stakeholder
Stakeholder sind Rollen außerhalb von Scrum. Die folgenden Rollen können helfen, die unterschiedlichen Stakeholder und deren Aufgaben zu differenzieren.
Kunden
Den Kunden wird das Produkt nach Fertigstellung zur Verfügung gestellt. Kunden können je nach Situation sowohl interne Fachabteilungen als auch externe Personen oder Gruppen sein. Es ist Aufgabe des Product Owners, seine Kunden durch Lieferung des Wunschproduktes zu begeistern. Deshalb sollten Product Owner und Kunden für die Dauer des Projektes im engen Austausch stehen.[40] Vor Beginn der Entwicklung sollte der Product Owner ein möglichst genaues Verständnis von der Wunschvorstellung seiner Kunden gewinnen. Die Kunden sollten schon nach den ersten Sprints Gelegenheit haben, sich die neuen Funktionalitäten anzuschauen und hierzu Feedback zu geben.
Anwender
Anwender sind diejenigen Personen, die das Produkt benutzen. Ein Anwender kann, muss aber nicht zugleich 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 Nutzers beurteilen. Anwender und Kunden sollten beim Sprint Review und beim Product Backlog Refinement hinzugezogen werden, um das Produkt zu erproben und Feedback zu geben.[41]
Management
Das Management trägt Verantwortung dafür, dass die Rahmenbedingungen stimmen. Dazu gehören die Bereitstellung von Räumen und Arbeitsmitteln, aber auch generell 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.[42]
Sprint
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 -Retrospektive. Sprints folgen unmittelbar aufeinander. Während eines Sprints sind keine Änderungen erlaubt, die das Sprintziel beeinflussen.[43]
Ein Sprint umfasst ein Zeitfenster von ein bis vier Wochen. 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.[44]
Ein Sprint kann vorzeitig vom Product Owner abgebrochen werden, wenn das Sprint-Ziel nicht mehr erreicht werden soll, beispielsweise weil sich die Zielvorgaben von Stakeholdern oder generell Marktbedingungen ändern. In diesem Fall wird der aktuelle Sprint mit einer Sprint-Retrospektive beendet und der neue Sprint ganz normal mit Sprint Planning begonnen. Der Scrum-Guide beschreibt Sprint-Abbrüche als Ressourcen-intensiv und unüblich.[45]
Ereignisse
In Scrum spricht man von Ereignissen oder Events statt von Meetings, um klarzustellen, dass es sich um Arbeit handelt. Alle Ereignisse von Scrum haben feste Zeitfenster (Timeboxen), die nicht überschritten werden sollen.
Sprint Planning
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. Sie dauert in Summe maximal 2 Stunden je Sprint-Woche, beispielsweise maximal acht Stunden für einen 4-Wochen-Sprint.[46]
Teil 1: Festlegung des Was
Der Product Owner stellt dem Entwicklungsteam die im Product Backlog festgehaltenen Produkteigenschaften in der zuvor priorisierten Reihenfolge vor. 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, beispielsweise die Gebrauchstauglichkeit. Außerdem einigt sich der Product Owner mit dem Entwicklungsteam auf die 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 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. Deshalb müssen beide konstruktiv zusammenarbeiten. Aus den ausgewählten Product-Backlog-Einträgen formuliert das Scrum-Team gemeinsam ein Sprintziel.[47][48]
Die ursprüngliche Beschreibung von Scrum verwendete den Begriff Commitment (Verpflichtung) statt Forecast (Prognose); dies wurde angepasst, weil es häufig zu Fehlentwicklungen zulasten der Qualität führte.[49]
Teil 2: Festlegung des Wie
Im zweiten Teil der Sprint Planung plant das Entwicklungsteam im Detail, welche Aufgaben (Tasks) zum Erreichen des Sprintziels und zur Lieferung der prognostizierten Product-Backlog-Einträge notwendig sind. Diese Planung macht das Entwicklungsteam, wobei der Product Owner für Fragen in Reichweite sein sollte. Oftmals bilden sich zur Beantwortung der Wie-Frage Kleingruppen, in denen verschiedene Aspekte wie z. B. Architektur, Datenelemente und Schnittstellen geklärt werden.
Ergebnis ist das Sprint Backlog: der detaillierte Plan für den nächsten Sprint. Er 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
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 anwesend, jedoch nicht aktiv beteiligt sind, falls sie nicht selbst Backlogelemente bearbeiten. Zweck des Daily Scrum 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 einer Aufgabe länger als geplant 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 Fragen auf, die sich nicht innerhalb der strikten 15-Minuten-Vorgabe beantworten lassen, so werden sie entweder notiert und dem Scrum Master übergeben, oder ihre Beantwortung wird auf ein späteres Meeting, häufig direkt im Anschluss, verlegt.[20][50]
Sprint Review
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.[51][52]
Im Sprint Review ist die Beteiligung von 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 alle Abnahmekriterien erfüllt und dennoch aus der Perspektive des Benutzers unbrauchbar ist, beispielsweise wenn ein Button an einer schwer auffindbaren Stelle platziert wurde. Häufig entsteht während des Reviews ein lebhafter Dialog, in dem den Anwesenden neue Funktionalitäten einfallen.
Das Ergebnis des 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. Anhand der im Sprint Planning 1 festgelegten Bedingungen entscheidet er, ob sie abgenommen werden können oder nicht. Dabei soll er keine Kompromisse eingehen: Ein Team hat auch dann sein Ziel verfehlt, wenn es eine „fast fertige“, aber 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 des Sprint Reviews, bei dem es vorrangig um das Feedback der Stakeholder geht. Die Abnahme der Funktionalitäten des Produktinkrements wird daher häufig im Rahmen des Sprints umgesetzt.
Das Sprint-Review dauert maximal 1 Stunde je Sprint-Woche.
Sprint-Retrospektive
Die Sprint-Retrospektive steht 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 darin, gute Praktiken und Verbesserungen zu finden, die im nächsten Sprint umgesetzt werden. Die Retrospektive ist ein gemeinsames Ereignis des Scrum-Teams.[53][54]
Das Team soll seine Arbeitsweise offen und ehrlich überprüfen können. Dazu müssen Kritik und unangenehme Wahrheiten offen geäußert werden können. Das schließt auch Gefühle und Empfindungen ein.[55] Die Retrospektive soll daher in einem geschützten Raum ablaufen. Stakeholder dürfen 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 Aufgaben in das Sprint Backlog auf.[56]
Die Sprint-Retrospektive dauert maximal 45 min je Sprint-Woche, also maximal drei Stunden für einen Vier-Wochen-Sprint.
Artefakte
Product Backlog
Das Product Backlog ist eine geordnete Auflistung der Anforderungen an das Produkt. Das Product Backlog ist dynamisch und wird ständig weiterentwickelt. Alle Arbeit, die das Entwicklungsteam erledigt, muss ihren 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.[57][58]
Das Product Backlog ist nicht 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 Priorität werden als erste im Sprint umgesetzt.[12] Das Risiko einer Anforderung kann durch eine Analyse ihrer Abhängigkeiten zu anderen Anforderungen bestimmt werden.[59] Diese Abhängigkeiten werden auch als Rückverfolgbarkeit (englisch requirements traceability) bezeichnet und im Werkzeug, welches das Product Backlog verwaltet (z. B. Issue Tracker), als Nebenprodukt erfasst.
Die Anforderungen im Product Backlog sollten nicht technisch, sondern fachlich und anwenderorientiert sein. Eine Möglichkeit, um diese Sichtweise zu unterstützen, ist die Formulierung der Produkteigenschaften als User Stories. Die dabei für jede User Story erwünschten Eigenschaften wurden von Bill Wake zum Akronym INVEST zusammengefasst.[60] Es steht für:
- Independent – unabhängig. Sie sollte nach Möglichkeit nicht von anderen User Stories abhängen.
- Negotiable – verhandelbar. Sie sollte keine Umsetzungsdetails festlegen.
- Valuable – nützlich. Ihre Umsetzung erhöht den Gebrauchswert des Produkts für den Endkunden.
- Estimable – schätzbar. Der Aufwand für die Umsetzung muss abschätzbar sein.
- Small – klein. Der Aufwand für die Umsetzung sollte überschaubar sein. Erstrebenswert sind einige Arbeitstage, maximal einige Wochen.
- Testable – überprüfbar. Ihre erfolgreiche Umsetzung sollte sich mit objektiven Kriterien überprüfen lassen.
Product Backlog Refinement
Das Product Backlog Refinement (früher auch Backlog Grooming genannt[61]) ist ein fortlaufender Prozess, bei dem der Product Owner und das Entwicklungsteam gemeinsam das Product Backlog weiterentwickeln. Hierzu gehören:[62][63]
- 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 Stakeholder wertvolle Informationen liefern, indem sie 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-Treffen zusammen mit ausgewählten Stakeholdern.[64]
Das Product Backlog Refinement sollte nicht mehr als 10 % der Zeit des Entwicklungsteams in Anspruch nehmen.
Sprint Backlog
Das Sprint Backlog ist der aktuelle Plan der für einen Sprint zu erledigenden Aufgaben. Es umfasst die Product-Backlog-Einträge, die für den Sprint ausgewählt wurden, und die dafür nötigen Aufgaben (z. B. Entwicklung, Test, Dokumentation). Das Sprint Backlog wird laufend nach der Erledigung einer (Teil-)Aufgabe von den Team-Mitgliedern aktualisiert. Dies dient zur Übersicht des aktuellen Bearbeitungsstands.[65] Um es für alle sichtbar zu machen, wird häufig ein Taskboard genutzt.
Product Increment
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 nutzbaren Zustand sein und der Definition of Done entsprechen.[66]
Zusätzliche Anforderungen
Transparenz des Fortschritts
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.[67] Im Kern von Scrum wird für die Transparenz des Fortschritts keine spezifische Technik vorgegeben. Typischerweise werden hierzu Burndown-Grafiken verwendet.
Definition of Done
Die Definition of Done (DoD) 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 Ereignisse 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 als fertig akzeptiert wird.[68] Die Verantwortung für die Einhaltung der Kriterien der DoD obliegt dem Team.
Definition of Ready
Die Definition of Ready (DOR) folgt dem Ansatz der Definition of Done. Sie soll sicherstellen, dass ein Eintrag im Produkt Backlog vom Team implementiert werden kann, also wirklich alle notwendigen Vorbedingungen und Inputs verfügbar sind, beispielsweise stabile und freigegebene Interfacedokumente (ICDs). Zudem muss ein gemeinsames Verständnis über den Inhalt des Eintrags vorhanden sein. Verantwortlich für die Einhaltung der DOR ist der Produkt Owner. Nur Einträge, die Ready sind, können in einen Sprint übernommen werden.
Ergänzende Techniken
In 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
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.[69]
User Stories folgen im Allgemeinen diesem Muster:
Als NUTZER will ich FUNKTION oder EIGENSCHAFT, 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 20 Prozent der elektrische Antrieb so stark sein muss, dass die Fahrerin nicht mehr als 50 Watt durch 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.[70] Sobald eine User Story umgeschrieben oder um weitere Information ergänzt wird, werden auch diese Änderungen im Product Backlog festgehalten.[71]
Fragen nach dem Wie, also nach der technischen Umsetzung einer User Story, gehören ins Sprint Planning und werden nicht im Product Backlog, sondern im Taskboard mit Hilfe der einzelnen Tasks festgehalten.
Taskboard
Das Taskboard ist eine Technik zur Visualisierung des Sprint Backlogs. Darauf lässt sich jederzeit erkennen, welche Einträge aus dem Product Backlog für den Sprint ausgewählt wurden, welche Aufgaben dazu zu bearbeiten sind, und in welchem Bearbeitungszustand diese Aufgaben sind. Das Taskboard ist eine Kanban-Tafel.
Typischerweise besteht das Taskboard aus vier Spalten. In der ersten Spalte Anforderungen werden die Einträge aus dem Product Backlog eingetragen, 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 zweite Spalte enthält alle noch zu erledigenden Aufgaben, die nächste Spalte diejenigen in Bearbeitung und die letzte Spalte alle erledigten.
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. 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.[72]
Planungspoker
Scrum schreibt keine spezifische Methode vor, Aufwände abzuschätzen. Bei einer guten Schätzmethode sollten die Beteiligten zunächst unbeeinflusst von den anderen Teilnehmern schätzen. Andererseits sollte die Methode in annehmbarer Zeit zu einem akzeptierten und validen Ergebnis führen. Seit ca. 2005 ist Planungspoker eine gängige Methode in Scrum und generell in agilen Projekten.[73] Die englische Bezeichnung Planning Poker ist eine geschützte Warenbezeichnung der Firma Mountain Goat Software.[74]
Jeder Teilnehmer erhält einen Satz Spielkarten. Diese sind mit Schwierigkeitsgraden oder Story Points bedruckt, beispielsweise in der Systematik:
- trivial, einfach, mittel, schwierig, sehr schwierig, extrem schwierig
- (XXS), XS, S, M, L, XL, (XXL): T-Shirt Sizes
- 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 orientieren sich an den ersten Fibonacci-Zahlen 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 … Diese werden häufig gewählt, um der zunehmenden Unsicherheit in der Schätzung schwererer Aufgaben gerecht zu werden. Häufig gibt es außerdem Karten mit Unendlichkeitssymbol ∞, Kaffeetasse als Pausensymbol und Fragezeichen.
Das Planungsspiel läuft folgendermaßen:[74]
- Der Product Owner stellt die User Story vor, die es zu schätzen gilt.
- Das Team klärt in der Diskussion mit dem Product Owner seine Fragen zu der Story.
- Jedes Teammitglied wählt für sich eine Karte, die seiner Ansicht nach der Schwierigkeit der Story entspricht.
- Alle gewählten Karten werden gleichzeitig aufgedeckt.
- Die Teilnehmer mit der niedrigsten und der höchsten Schätzung erklären ihre Beweggründe.
- Der Prozess wird wiederholt, bis ein Konsens gefunden ist.
- Das Spiel wird wiederholt, bis alle User Stories geschätzt sind.
Bei einer größeren Zahl von User Stories ist es zweckmäßig, eine Zeitvorgabe pro Story zu vereinbaren, und diese jeweils mit einer Sanduhr oder Stoppuhr zu überwachen. Ist die Zeit abgelaufen, ohne dass die Story geschätzt werden konnte, so ist das ein Indiz dafür, dass die Beschreibung nicht gut verständlich ist und neu verfasst werden sollte.[74]
Impediment Backlog
Das Impediment Backlog ist eine Technik, mit welcher 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.
Burn-Down-Chart
Das Burn-Down-Chart dient der Visualisierung bereits geleisteter und noch verbleibender Arbeit. Es gibt zwei Varianten:
- Als Sprint Burndown wird es zur Verfolgung des Sprintfortschritts verwendet.
- Als Release Burndown wird es zur Verfolgung des Produktfortschritts über mehrere Sprints hinweg verwendet.
Beim Sprint Burndown wird auf der horizontalen Achse der Zeitverlauf in Tagen und auf der vertikalen Achse die Anzahl der noch zu erledigenden Tasks aufgetragen. So ergibt sich eine 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 eingetragen werden. Dies erfordert jedoch eine Schätzung der Restaufwände für alle Tasks, so dass diese Variante mehr Aufwand erfordert. Da die Genauigkeit bei Tasks mit einem Aufwand von maximal einem Tag nur geringfügig besser wird, hat sich das Zählen der Tasks bei vielen Teams durchgesetzt.
Beim Release Burndown wird auf der horizontalen Achse der Zeitverlauf in Sprints und auf der vertikalen Achse die Anzahl der noch zu erledigenden Product-Backlog-Einträge aufgetragen, beispielsweise in Story Points. Ändert sich der Umfang des Product Backlog, so wird dies unterhalb der horizontalen Achse eingetragen. Bei jedem Sprint aktualisiert der Product Owner das Release Burndown. Mit Hilfe des Release Burndown kann der Product Owner Umfang und Liefertermin des aktuellen Releases bestimmen.[75]
Fünf Phasen einer Retrospektive
Als Struktur einer Sprint-Retrospektive haben sich fünf Phasen bewährt:[76]
- 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 die Annahme, dass jeder die bestmögliche Arbeit geleistet hat, die er oder sie leisten konnte, und zwar unabhängig davon, welche offenen Punkte festgestellt werden.
- Zweitens werden Informationen gesammelt. Dies geschieht oft, indem man zurückblickt und ermittelt, was gut gelaufen ist und was nicht.
- Im dritten Schritt werden Erkenntnisse gewonnen. In dieser Phase klären Teams normalerweise, warum Dinge geschehen sind, damit nicht nur Symptome kuriert, sondern die tatsächlichen Ursachen erkannt werden.
- Viertens entscheidet man, was zu tun ist. Das umfasst Vereinbarungen über sinnvolle 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.[77]
Adaptionen von Scrum
Obwohl der Scrum Guide[20] die essentiellen Elemente von Scrum vorschreibt, scheinen viele Unternehmen signifikant davon abzuweichen. Die wenigste Variation findet sich in der Sprint-Länge, den Treffen, der Teamgröße und im Requirements Engineering. Die Unternehmen variieren am ehesten in den Rollen, der Aufwandsschätzung und der Qualitätssicherung. Für einige der Abweichungen gibt es gute Gründe, oft aber sind die Abweichungen das Resultat einer nicht vollständigen Umsetzung von Scrum in einer hierarchischen, nicht-agilen Organisation.[78]
Zur Skalierung von Scrum auf große Projekte mit vielen Mitarbeitern und Scrum-Teams bzw. für gesamte Unternehmen gibt es mehrere Ansätze. Die bekanntesten sind:
Grenzen und Nachteile von Scrum
Keine Erfolgsgarantie
Erfolgsgarantien kann Scrum, wie viele andere Prozesse und Vorgehensmodelle, nicht bieten.
Verwertung gewonnener Erkenntnisse
Laut den Machern von Scrum muss man sich bei Verwendung von Scrum darauf einstellen, dass die ursprünglichen Einschätzungen permanent über- oder untertroffen werden. Scrum zeigt, laut seinen Erfindern, vom ersten Tag an Abweichungen vom Soll-Zustand an. Wie gut die Produktentwicklung mit Scrum funktioniert, hängt nach Angaben der Entwickler von Scrum davon ab, wie das Scrum-Team die gewonnenen Erkenntnisse anwendet. Nach Schwaber kann auch ein „Team von Idioten“ nach Scrum arbeiten.[83] 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.
Rollenkonflikte
Die Selbstorganisation im Entwicklungsteam impliziert, dass Hierarchien in Frage gestellt werden. Mitglieder, die nicht bereit sind, ihre bisherige Position innerhalb des Entwicklungsteams aufzugeben, können daher Konflikte erzeugen. Scrum fordert, dass alle Teammitglieder vielfältige Aufgaben eines Sprints bearbeiten können. Jemand, der sich exklusiv als Tester, Programmierer oder Architekt sieht, passt nicht optimal in ein Entwicklungsteam nach Scrum.
Juristische Erwägungen
Im Rahmen von Werkverträgen und vor dem Hintergrund des Produkthaftungsgesetzes kann die Anwendung von Scrum 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[84] werden Vorschläge angeboten, wie Werkverträge für Scrum-Projekte zu gestalten sind.[85][86]
Zertifizierung
2003 war das Jahr, in dem die ersten zertifizierten Scrum Master von Ken Schwaber ausgebildet wurden. Heute konkurrieren mehrere Scrum-Zertifizierungen auf dem Markt. Neben Scrum-fokussierten Anbietern finden sich auch agile Erweiterungen und Anpassungen der etablierten Projektmanagement-Anbieter. Die Zertifizierungen weisen unterschiedliche Kosten, Voraussetzungen und Inhalte auf.[87] Zu den bekanntesten gehören ScrumAlliance, Scrum.org und Scrum Inc., die den Scrum Guide von Schwaber und Sutherland als gemeinsamen und zentralen Standard ansehen.[88]
| ScrumAlliance | Scrum.org | Scrum Inc. | |
|---|---|---|---|
| Gründer | Ken Schwaber und Mike Cohn | Ken Schwaber | Jeff Sutherland |
| Gründungsjahr | 2001 (Zertifizierungen seit 2003) | 2009 | 2006 (Zertifizierungen seit 2019) |
| Hauptsitz | Westminster, Colorado | Burlington, Massachusetts | Cambridge, Massachusetts |
| Angebot | Certified...
|
Professional...
|
Registered...
|
| Gültigkeitsdauer | 2 Jahre | unbegrenzt | 1 Jahr |
| Zertifizierungen |
1,2 Mio. (2021)[89] |
0,6 Mio. (2021)[90] |
29.200 (2021)[91] |
Werkzeuge
Es gibt diverse Werkzeuge wie Agilo for Scrum, Redmine (verschiedene Plugins verfügbar), OpenProject, Jira, oder Team Foundation Server, die darauf ausgelegt sind, die Einführung von Scrum und die darin anfallenden Prozesse zu erleichtern.
Literatur
- Ken Schwaber, Mike Beedle: Agile Software Development with Scrum. Prentice Hall, Upper Saddle River 2002, ISBN 978-3-86645-643-3.
- Ken Schwaber: Agiles Projektmanagement mit Scrum. Microsoft Press, Redmond 2007, ISBN 978-3-86645-631-0 (englisch: Agile Project Management with Scrum.).
- Ken Schwaber: Scrum im Unternehmen. Microsoft Press, Redmond 2008, ISBN 978-3-86645-643-3 (englisch: The Enterprise and Scrum.).
- Roman Pichler: Scrum: Agiles Projektmanagement erfolgreich einsetzen. dpunkt.verlag, Heidelberg 2008, ISBN 978-3-89864-478-5.
- Jeff Sutherland, Rini van Solingen, Eelco Rustenberg: The Power of Scrum. North Charleston 2011, ISBN 978-1-4635-7806-0.
- Roman Pichler, Stefan Roock: Agile Entwicklungspraktiken mit Scrum. dpunkt.verlag, Heidelberg 2011, ISBN 978-3-89864-719-9.
- Boris Gloger, André Häusling: Erfolgreich mit Scrum: Einflussfaktor Personalmanagement. Hanser Verlag, München 2011, ISBN 978-3-89864-719-9.
- Holger Koschek: Geschichten vom Scrum: Von Sprints, Retrospektiven und agilen Werten. 2. Auflage (1. Auflage 2009). dpunkt.verlag, Heidelberg 2014, ISBN 978-3-86490-140-9.
- Ken Schwaber, Jeff Sutherland: Software in 30 Tagen: Wie Manager mit Scrum Wettbewerbsvorteile für ihr Unternehmen schaffen. dpunkt.verlag, Heidelberg 2014, ISBN 978-3-86490-074-7 (englisch: Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, and Leave Competitors in the Dust.).
- Kenneth S. Rubin: Essential Scrum: Umfassendes Scrum-Wissen aus der Praxis. mitp, 2014, ISBN 978-3-8266-9047-1 (englisch: Essential Scrum: A Practical Guide to the Most Popular Agile Process.).
- Roman Pichler: Agiles Produktmanagement mit Scrum. 2. Auflage (1. Auflage 2012). dpunkt.verlag, Heidelberg 2014, ISBN 978-3-86490-142-3 (englisch: Agile Product Management with Scrum.).
- Sven Röpstorff, Robert Wiechmann: Scrum in der Praxis: Erfahrungen, Problemfelder und Erfolgsfaktoren. 2. Auflage (1. Auflage 2012). dpunkt.verlag, Heidelberg 2015, ISBN 978-3-86490-258-1.
- Jeff Sutherland, J.J. Sutherland: Die Scrum Revolution: Management mit der bahnbrechenden Methode der erfolgreichsten Unternehmen. Campus Verlag, Frankfurt 2015, ISBN 978-3-593-39992-8 (englisch: Scrum: The Art of Doing Twice the Work in Half the Time.).
- Boris Gloger: Scrum: Produkte zuverlässig und schnell entwickeln. 5. Auflage (1. Auflage 2008). Hanser Verlag, München 2016, ISBN 978-3-446-44723-3.
- Ralf Wirdemann: Scrum mit User Stories. 3. Auflage (1. Auflage 2009). Hanser Verlag, München 2017, ISBN 978-3-446-45052-3.
- Boris Gloger, Jürgen Margetich: Das Scrum-Prinzip: Agile Organisationen aufbauen und gestalten. 2. Auflage (1. Auflage 2014). Schäffer-Poeschel, Stuttgart 2018, ISBN 978-3-7910-3947-3.
- Dominik Maximini: Scrum: Einführung in der Unternehmenspraxis. 2. Auflage (1. Auflage 2013). Springer Gabler, Wiesbaden 2018, ISBN 978-3-662-56325-0.
- Rolf Dräther, Holger Koschek und Carsten Sahling: Scrum kurz & gut. 2. Auflage (1. Auflage 2013). O’Reilly, 2019, ISBN 978-3-96009-094-6.
- Jeff Sutherland, James O. Coplien: Scrum: Ein Buch über Zusammenarbeit. Vahlen, München 2021, ISBN 978-3-8006-6153-4 (englisch: A Scrum Book: The Spirit of the Game.).
Weblinks
Einzelnachweise
- The State of Scrum: Benchmarks and Guidelines (PDF; englisch) – siehe auch ebenda auf Seite 10 (von 48); Scrum Alliance, Juni 2013 (abgerufen am 25. Dezember 2014)
- Mary Poppendieck, Tom Poppendieck: Lean Software Development: An Agile Toolkit. Addison-Wesley, Upper Saddle River 2003.
- Malte Foegen: Der Ultimative Scrum Guide 2.0. wibas, Darmstadt 2014, S. 50–51.
- The New New Product Development Game. Cb.hbsp.harvard.edu, 1. Januar 1986.
- I. Nonaka, H. Takeuchi: The Knowledge-Creating Company. Oxford University Press, 1995.
- Peter DeGrace, Leslie Hulet Stahl: Wicked Problems, Righteous Solutions: A Catolog of Modern Engineering Paradigms. 1998.
- Jeff Sutherland. Abgerufen am 21. Oktober 2011.
- J. J. Sutherland: Das Scrum-Praxisbuch. Campus Verlag, 2020, ISBN 978-3-593-44432-1, S. 17 (google.de [abgerufen am 23. Juni 2021]).
- Jeff Sutherland: Origins of Scrum. Scrum Inc, 7. Mai 2007, abgerufen am 27. September 2020 (englisch).
- QPW – info. In: gertrudandcope.com. Abgerufen am 27. September 2020 (englisch).
- Boris Gloger: Scrum. Produkte zuverlässig und schnell entwickeln. 3. Auflage. Hanser Verlag, München 2011, S. 19.
- How did Scrum originate? (englisch) – abgerufen am 25. Mai 2018.
- Mike Beedle. Abgerufen am 21. Oktober 2011.
- Ken Schwaber: Scrum im Unternehmen. Microsoft Press Deutschland, 2008, S. XI–XII.
- 1st Annual State of Agile™ Report bis 13th Annual State of Agile™ Report
- Ikujiro Nonaka, Hirotaka Takeuchi: A Theory of the Firm’s Knowledge-Creation Dynamics. In: Alfred Chandler u. a. (Hrsg.): The Dynamic Firm. The Role of Technology, Strategy, Organization, and Regions. Oxford University Press, 2008, S. 215–216.
- Boris Gloger: Scrum. Produkte zuverlässig und schnell entwickeln. 3. Auflage. Hanser Verlag, München 2011, S. 27–30.
- Scrum Code of Ethics
- Der Agile Atlas – Core Scrum – Improuv (improuv.com), mit Verweis auf ein 12-seitiges PDF (≈ 120 KB); Übersetzung vom Januar 2013; abgerufen am 25. Dezember 2016.
- Jeff Sutherland Ken Schwaber: Der Scrum Guide. (PDF) scrum.org, November 2017, abgerufen am 24. September 2017.
- Malte Foegen: Der Ultimative Scrum Guide. wibas, Darmstadt 2014, S. 112–113.
- Boris Gloger: Scrum. Produkte zuverlässig und schnell entwickeln. 3. Auflage. Hanser Verlag, München 2011, S. 12.
- Ken Schwaber, Jeff Sutherland: The Scrum Guide. S. 7.
- Dean Leffingwell: Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development). Addison-Wesley, Boston 2010.
- Craig Larman, Bas Vodde: Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley, Boston 2010.
- Scrum Alliance: Agile Atlas. (Memento vom 12. Juni 2014 im Internet Archive) V 2012.12.13, S. 4–6.
- Boris Gloger, Scrum – Produkte zuverlässig und schnell entwickeln, Hanser, 4. Auflage, 2013.
- Dean Leffingwell: Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development). Addison-Wesley, Boston 2010.
- Craig Larman, Bas Vodde: Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley, Boston 2010.
- Ken Schwaber, Jeff Sutherland: The Scrum Guide. November 2017. Abgerufen am 28. September 2018, S. 6 (PDF; 582 kB).
- Scrum Alliance: Agile Atlas. (Memento vom 12. Juni 2014 im Internet Archive) V 2012.12.13, S. 4.
- Boris Gloger: Scrum. Produkte zuverlässig und schnell entwickeln. 3. Auflage. Hanser Verlag, München 2011, S. 78–87.
- Roman Pichler: Scrum – Agiles Projektmanagement erfolgreich einsetzen. d.punkt Verlag, Heidelberg 2009, S. 10–13.
- Roman Pichler: Scrum – Agiles Projektmanagement erfolgreich einsetzen. d.punkt Verlag, Heidelberg 2009, S. 15.
- Scrum Alliance: Agile Atlas. S. 5.
- Wann ist der Scrum Master überflüssig? (10 unangenehme Anzeichen). Abgerufen am 17. Oktober 2020 (englisch).
- Roman Pichler: Scrum – Agiles Projektmanagement erfolgreich einsetzen. d.punkt Verlag, Heidelberg 2009, S. 20–23.
- Malte Foegen: Der Ultimative Scrum Guide 2.0. wibas, 2014, S. 62–65.
- Boris Gloger: Scrum. Produkte zuverlässig und schnell entwickeln. 3. Auflage. Hanser Verlag, München 2011, S. 88–101.
- Boris Gloger: Scrum. Produkte zuverlässig und schnell entwickeln. 3. Auflage. Hanser Verlag, München 2011, S. 101–103.
- Scrum Alliance: Agile Atlas. (Memento vom 12. Juni 2014 im Internet Archive) V 2012.12.13, S. 10.
- Boris Gloger: Scrum. Produkte zuverlässig und schnell entwickeln. 3. Auflage. Hanser Verlag, München 2011, S. 104–107.
- Ken Schwaber, Jeff Sutherland: The Scrum Guide. S. 9 f.
- Scrum Alliance: Agile Atlas. (Memento vom 12. Juni 2014 im Internet Archive) V 2012.12.13, S. 3.
- Ken Schwaber, Jeff Sutherland: The Scrum Guide. S. 10.
- Ken Schwaber, Jeff Sutherland: The Scrum Guide. S. 9.
- Ken Schwaber, Jeff Sutherland: Der Scrum Guide. S. 9.
- Scrum Alliance: Agile Atlas. (Memento vom 12. Juni 2014 im Internet Archive) V 2012.12.13, S. 7–8.
- Jose Luis Soria Teruel: Commitment vs. Forecast: A subtle but important change to Scrum. Abgerufen am 18. Januar 2013.
- Roman Pichler: Scrum. Agiles Projektmanagement erfolgreich einsetzen. dpunkt.verlag, Heidelberg 2009, S. 104–107.
- Ken Schwaber, Jeff Sutherland: The Scrum Guide. S. 13.
- Scrum Alliance: Agile Atlas. (Memento vom 12. Juni 2014 im Internet Archive) V 2012.12.13, S. 10–11.
- Ken Schwaber, Jeff Sutherland: The Scrum Guide. S. 14.
- Scrum Alliance: Agile Atlas. (Memento vom 12. Juni 2014 im Internet Archive) V 2012.12.13, S. 11.
- Rolf Dräther: Retrospektiven kurz & gut. O'Reilly, Köln 2014, S. 125.
- Malte Foegen: Der Ultimative Scrum Guide 2.0. wibas, Darmstadt 2014, S. 140–141.
- Ken Schwaber, Jeff Sutherland: The Scrum Guide. S. 15–16.
- Scrum Alliance: Agile Atlas. (Memento vom 12. Juni 2014 im Internet Archive) V 2012.12.13, S. 6.
- Patrick Rempel, Patrick Mäder: Estimating the Implementation Risk of Requirements in Agile Software Development Projects with Traceability Metrics. In: Requirements Engineering: Foundation for Software Quality (= Lecture Notes in Computer Science). Nr. 9013. Springer International Publishing, 2015, ISBN 978-3-319-16100-6, S. 81–97, doi:10.1007/978-3-319-16101-3_6 (springer.com [abgerufen am 18. Januar 2017]).
- Bill Wake: INVEST in Good Stories, and SMART Tasks. 17. August 2003, abgerufen am 25. August 2018 (englisch).
- Scrum und Backlog Refinement (oder auch Backlog Grooming). In: scrum-trainings. 4. Dezember 2013, abgerufen am 27. September 2020 (deutsch).
- Ken Schwaber, Jeff Sutherland: The Scrum Guide. S. 16.
- Scrum Alliance: Agile Atlas. (Memento vom 12. Juni 2014 im Internet Archive) V 2012.12.13, S. 6–7.
- Malte Foegen: Der Ultimative Scrum Guide 2.0. wibas, Darmstadt 2014, S. 92–93 und 96–97.
- Sprint Backlog. Abgerufen am 27. September 2020.
- Scrum Alliance: Agile Atlas. (Memento vom 12. Juni 2014 im Internet Archive) V 2012.12.13, S. 9.
- Scrum Alliance: Agile Atlas. (Memento vom 12. Juni 2014 im Internet Archive) V 2012.12.13, S. 9.
- Scrum Alliance: Agile Atlas. (Memento vom 12. Juni 2014 im Internet Archive) V 2012.12.13, S. 9–10.
- Roman Pichler: Scrum – Agiles Projektmanagement erfolgreich einsetzen. d.punkt Verlag, Heidelberg 2009, S. 46–47.
- Malte Foegen: Der Ultimative Scrum Guide 2.0. wibas, Darmstadt 2014, S. 104–105.
- Roman Pichler: Scrum – Agiles Projektmanagement erfolgreich einsetzen. d.punkt Verlag, Heidelberg 2009, S. 46–47.
- Boris Gloger: Scrum. Produkte zuverlässig und schnell entwickeln. 3. Auflage. Hanser Verlag, München 2011, S. 167–169.
- Mike Cohn: Agile Estimating and Planning. Prentice Hall, 2005, ISBN 0-13-147941-5.
- Scrum Effort Estimations – Planning Poker, The International Scrum Institute, abgerufen am 20. Februar 2015.
- Malte Foegen: Der Ultimative Scrum Guide 2.0. wibas, Darmstadt 2014, S. 148–151.
- Esther Derby, Diana Larsen: Agile Retrospectives: Making Good Teams Great. Pragmatic Programmers, 2006.
- Retromat – Anregungen & Abläufe für (agile) Retrospektiven. Abgerufen am 11. Januar 2020.
- Philipp Diebold, Jan-Peter Ostberg, Stefan Wagner, Ulrich Zendler: What do practitioners vary in using scrum? 2015, doi:10.18419/opus-3482 (uni-stuttgart.de [abgerufen am 27. September 2020]).
- Overview. Abgerufen am 23. Juni 2021 (englisch).
- SAFe 5.0 Framework. Abgerufen am 23. Juni 2021 (amerikanisches Englisch).
- Scaling Scrum with Nexus. Abgerufen am 23. Juni 2021 (englisch).
- https://scrumatscale.scruminc.com/
- Ken Schwaber: Scrum et al. (Minute 14) Abgerufen am 12. August 2011.
- Philipp M Kühn, Nikolaus Ehlenz: Agile Werkverträge mit Scrum. In: Computer und Recht. Band 34, Nr. 3, 1. März 2018, ISSN 2194-4172, S. 139–151, doi:10.9785/cr-2018-340303 (cr-online.de [abgerufen am 3. September 2020]).
- Tom Arbogast, Craig Larman, Bas Vodde: Practices for Scaling Lean & Agile Development. Addison-Wesley Longman, Amsterdam 2010, ISBN 978-0-321-63640-9, S. 499 ff. (PDF)
- Andreas Opelt, Boris Gloger, Wolfgang Pfarl, Ralf Mittermayr: Der agile Festpreis: Leitfaden für wirklich erfolgreiche IT-Projekt-Verträge. Carl Hanser Verlag, 2012, ISBN 978-3-446-43226-0.
- SCRUM Usergroup Deutschland: Ausbildung & Zertifizierung. In: scrum-usergroup.de. Abgerufen am 12. Mai 2016.
- Scrum Alliance, Scrum Inc., Scrum.org Endorse The Scrum Guide | Scrum Inc. Abgerufen am 27. September 2020.
- Certified Scrum Certified Count. Abgerufen am 31. Januar 2021 (englisch).
- Professional Scrum Certified Count. Abgerufen am 12. November 2021 (englisch).
- Education Scrum Inc. Abgerufen am 12. Dezember 2021 (englisch).