Scrum ist ein Vorgehensmodell für agiles Projekt- und Produktmanagement. Das Framework wurde ursprünglich von Jeff Sutherland und Ken Schwaber in den 1990er Jahren für die agile Softwareentwicklung konzipiert. Doch Scrum hat mittlerweile Anwendung über die Softwareentwicklung hinaus gefunden und wird branchenunabhängig in nahezu allen Bereichen eingesetzt.
Der Name „Scrum“ kommt aus dem Rugby und beschreibt das Gedränge das um den Ball entsteht. Die zwei Wirtschaftswissenschaftler, Nonaka und Takeuchi, nutzten dieses Wort als Analogie für außergewöhnlich erfolgreiche Produktentwicklungsteams. Denn auch bei Scrum stehen alle Beteiligten eng beieinander.
Der aktuelle Scrum Guide (2020) beschreibt, welche Rollen, Events und Artefakte für die erfolgreiche Implementierung von Scrum notwendig sind. Diese Definitionen werden dir in diesem Artikel erklärt. Sie sind allerdings nicht als strenge Prozessvorgaben, sondern als lockere Richtlinien zu verstehen.
Scrum Team
Das Scrum Team besteht aus drei Rollen: dem Product Owner, dem Entwicklungsteam sowie dem Scrum Master. Das gesamte Scrum Team ist dafür verantwortlich, bei jedem Sprint (vgl. Scrum Events) ein nutzbares Inkrement zu erstellen. Unter einem Inkrement versteht man ein konkretes Etappenziel auf dem Weg zum übergreifenden Produktziel. Die Zusammenarbeit im Scrum Team verläuft auf Augenhöhe. Hierarchien und Micromanagement haben keinen Platz. Die Basis für erfolgreiche agile Teams sind Offenheit, Respekt, Selbstverpflichtung, Fokus und Mut.
Product Owner
Der Product Owner trägt, wie der Name schon sagt, die Verantwortung für das zu entwickelnde Produkt. Das Ziel ist es, den Wert des Endproduktes für die Stakeholder (z.B. Kund*innen, Nutzer*innen, Manager*innen etc.) zu maximieren. Um dies zu garantieren, hält der Product Owner im Product Backlog (vgl. Scrum Artefakte) alle Anforderungen an das Produkt fest und übersetzt diese in konkrete Aufgaben. Unter Berücksichtigung des Produktziels sowie der Bedürfnisse der Stakeholder strukturiert und priorisiert der Product Owner anschließend die heruntergebrochenen Aufgaben. Wichtig ist, dass der Product Backlog transparent, sichtbar und verständlich für das gesamte Scrum Team ist.
Entwicklungsteam
Das Entwicklungsteam besteht aus 3-9 funktionsübergreifenden Fachexpert*innen, die sich dazu verpflichten, bei jedem Sprint (vgl. Sprint Events) einen Aspekt eines verwendbaren Inkrements zu erstellen. Die Mitglieder des Entwicklungsteams sind also diejenigen, welche die konkrete Umsetzung der Aufgaben für die Produktentwicklung verantworten. Je nachdem in welchem Bereich Scrum genutzt wird, variieren die Fähigkeiten, die benötigt werden. Sobald der Product Backlog vom Product Owner priorisiert wurde, erstellt das Entwicklungsteam selbstständig einen Sprint Plan, genauer gesagt den Sprint Backlog (vgl. Scrum Artefakte). Das interdisziplinäre Entwicklungsteam entscheidet hierbei eigenverantwortlich, wer die festgelegten Aufgaben bearbeitet und in welcher Reihenfolge.
Scrum Master
Der Scrum Master ist für die Umsetzung der Scrum Regeln und Werte verantwortlich. Dazu gehört beispielsweise die Sicherstellung, dass alle Scrum Events stattfinden und innerhalb gewisser Zeitrahmen abgehalten werden. Außerdem coacht der Scrum Master die Teammitglieder in Selbstorganisation mit dem Ziel die Team Effektivität zu erhöhen. Zudem beseitigt er oder sie diverse Hindernisse, welche das Scrum Team von Fortschritten abhalten könnten. Neben dem Scrum Team, ist es auch Aufgabe des Scrum Masters, der gesamten Organisation die Scrum Theorie und Praxis zu vermitteln.
Scrum Events
Wie auf der Abbildung 2 zu erkennen ist, gibt es fünf Scrum Events, welche der Transparenz, der Überprüfbarkeit sowie der kontinuierlichen Verbesserung der Zusammenarbeit dienen. Zu diesen Ereignissen gehören:
- der Sprint
- die Sprint-Planungssitzung (Sprint Planning)
- das Daily Scrum
- der Sprint Review
- die Sprint Retrospektive (farblich markiert in Blau)
Optimalerweise finden alle Veranstaltungen am gleichen Ort und zur selben Zeit statt, um die Komplexität zu verringern.
Sprint
Das Herzstück von Scrum ist der Sprint, ein Zeitraum von ein bis maximal vier Wochen, in welchem alle für das Erreichen des Sprintziels (Erstellung eines fertigen, nutzbaren und potentiell auslieferbaren Produktinkrements) erforderlichen Arbeiten absolviert werden.
Der Sprint enthält folgende Teilschritte: die Sprint-Planung, die Daily Scrums, den Sprint Review sowie die Sprint Retrospektive. Ein neuer Sprint startet unmittelbar nach Abschluss des vorherigen Sprints. Im Gegensatz zum Wasserfallmodell ermöglichen Sprints eine steile Lernkurve, da der Fortschritt in Richtung eines Produktziels kontinuierlich (beispielsweise anhand von Burn-Down Charts) überprüft und angepasst wird. Somit wird das Risiko zu hoher Kosten und Aufwände für die Umsetzung eines spezifischen Projekts begrenzt. Falls ein Sprintziel aufgrund neuer Entwicklungen veraltet ist, kann der Product Owner den Sprint abbrechen.
Sprint-Planungssitzung
Die Sprint-Planungssitzung (Sprint Planning) findet am Anfang jedes Durchlaufs statt. Ziel ist die Erstellung des Sprint Backlogs (vgl. Scrum Artefakte), also eine Auflistung der Aufgaben, die innerhalb eines Sprints zu erledigen sind, sowie die Festlegung des Sprintziels.
Wichtig ist, dass das gesamte Scrum Team dasselbe Verständnis des zu entwickelnden Inkrements und des resultierenden Plans für die Zusammenarbeit hat. Im Meeting werden folgende drei Fragen beantwortet:
- Warum ist dieser Sprint wertvoll? Hier liegt der Fokus auf der Ausformulierung des Sprintziels sowie der Erläuterung warum der Sprint für die Stakeholder von Bedeutung ist.
- Was kann in diesem Sprint fertiggestellt werden? Das Entwicklungsteam wählt, im Austausch mit dem Product Owner, Elemente aus dem Product Backlog für den aktuellen Sprint aus. Das Entwicklungsteam legt die Aufgaben, die im Sprint bearbeitet werden, also selbst fest.
- Wie wird die ausgewählte Arbeit erledigt? Das Entwicklungsteam erstellt für jedes ausgesuchte Product Backlog Element selbstständig einen Plan in welcher Art und Weise die Arbeit erledigt werden soll.
Daily Scrum
Das Daily Scrum ist eine tägliche 15-minütige Sitzung für das Entwicklungsteam, um den Fortschritt der Arbeit zu überprüfen, den Sprint Backlog gegebenenfalls anzupassen und den nächsten Arbeitstag zu planen. Außerdem können Hindernisse identifiziert werden. Das Meeting sollte jeden Tag zur selben Uhrzeit und am gleichen Ort stattfinden, um die Komplexität zu verringern. Folgende drei Fragen eignen sich für das Daily Scrum Meeting: 1) Was habe ich gestern zum Erreichen unseres Sprintziels getan? 2) Was werde ich heute zum Erreichen unseres Sprintziels tun? 3) Welche Hindernisse halten mich beziehungsweise uns davon ab, unser Sprintziel zu erreichen?
Sprint Review
Der Sprint Review ist das vorletzte Ereignis des Sprints und dient der Präsentation und Überprüfung des freizugebenden Produktinkrements sowie der Bestimmung potentieller, zukünftiger Anpassungen des Product Backlogs. Die Maximaldauer liegt bei 4 Stunden. Zunächst stellt das gesamte Scrum Team den wichtigsten Stakeholdern die Sprint-Ergebnisse vor und diskutiert die Fortschritte auf dem Weg zum übergreifenden Produktziel. Basierend auf den gemeinsamen Gesprächen, werden nächste Schritte abgeleitet und gegebenenfalls Anpassungen am Product Backlog vorgenommen.
Sprint Retrospektive
Die Sprint Retrospektive schließt den Sprint ab und dauert maximal 3 Stunden. Die Zielsetzung ist es, den letzten Sprint zu reflektieren und Maßnahmen abzuleiten, die zukünftige Sprints in Bezug auf deren Qualität und Effektivität verbessern. Gegebenenfalls fügt das Scrum Team die wirksamsten Verbesserungen direkt zum Sprint Backlog für den nächsten Sprint hinzu.
Scrum Artefakte
Zu den Scrum Artefakten gehören: der Product Backlog, der Sprint Backlog und das Inkrement. Diese Dokumente werden durchgängig gepflegt und dienen der empirischen Prozesssteuerung. Scrum basiert auf der Theorie des Empirismus. Das bedeutet, dass Wissen durch Erfahrungen entsteht und Entscheidungen auf der Grundlage von Fakten getroffen werden. Der Prozess ist, im Gegensatz zum Wasserfallmodell, iterativ und basiert auf den drei Säulen: Transparenz, Überprüfung und Anpassung. Die drei Artefakte stellen sicher, dass die wichtigsten Informationen der Projektarbeit bereitgestellt werden und somit die Transparenz maximiert wird.
Product Backlog
Der Product Backlog ist eine dynamische Liste, in der alle Anforderungen für das zu entwickelnde Produkt gesammelt werden. Über den gesamten Projektzeitraum hinweg pflegt, ordnet und priorisiert der Product Owner diesen einen Backlog. Neben dem Hinzufügen neuer Anforderungen oder Ergänzungen, gehört auch das Bearbeiten oder Löschen bestehender Product Backlog Elemente – sollte dies zum Beispiel durch Wünsche der Kund*innen nötig sein – zu den Aufgaben des Product Owners. Je höher die Priorität des Product Backlog Elements ist, desto genauer wird präzisiert (Beschreibung, Reihenfolge, Aufwandsschätzung, Wertangabe, User Stories etc.). Diese Verfeinerung hilft dem Entwicklungsteam in der Sprint-Planungssitzung die passenden Product Backlog Elemente für den Sprint auszuwählen.
Im Scrum Guide (2020) wird als elementarer Teil des Product Backlogs außerdem das Produktziel genannt. Die Verpflichtung zum Produktziel verleiht dem Artefakt zusätzliche Qualität und verbessert die Transparenz. Das Produktziel ist, wie der Name schon verrät, das langfristige Ziel des Scrum Teams. Jedes Produkt hat immer nur ein Produktziel auf einmal. Erst wenn dieses erfüllt (oder aufgeben) ist, kann ein neues angenommen werden.
Sprint Backlog
Der Sprint Backlog ist ein Plan von und für das Entwicklungsteam. Er beschreibt, welche Aufgaben im Sprint bearbeitet werden beziehungsweise weist alle Anforderungen auf, welche im zu erstellenden Produktinkrement enthalten sein werden. Im Laufe des Sprints kann der Sprint Backlog nach Bedarf und in Absprache mit dem Product Owner aktualisiert werden. Das Daily Scrum bietet eine Möglichkeit, den aktuellen Stand und den Fortschritt der Arbeit kontinuierlich zu überprüfen. Der Sprint Backlog hat lediglich für einzelne Sprints Relevanz, während der Product Backlog während des gesamten Projektzeitraums gepflegt wird.
Im Gegensatz zum Produktziel, welches die langfristige Ausrichtung eines Produkts bestimmt, beschreibt das Sprintziel ein gemeinsames übergeordnetes Ziel, welches pro Sprint erreicht werden soll. Es beantwortet also die Frage, warum das aktuelle Inkrement erstellt wird und welchen Mehrwert es bietet. Das Sprintziel wird während der Sprint-Planungssitzung erstellt und dem Sprint Backlog hinzugefügt. Neben dem Sprintziel (warum), wird zusätzlich festgelegt, welche Product Backlog Elemente (was) für den Sprint ausgewählt werden. Auch das Wie, also ein umsetzbarer Plan für die Bereitstellung des Inkrements, wird erstellt.
Produktinkrement
Das Produktinkrement umfasst alle Elemente aus dem Product Backlog, welche im Rahmen des vergangenen Sprints umgesetzt wurden. Zudem beinhaltet es den Wert aller Inkremente, die in den vorherigen Sprints umgesetzt wurden. Das Produktinkrement ist also quasi immer das aktuelle Produkt in seinem letzten Release-Zustand. Es stellt einen wichtigen Bestandteil und Anteil zur Erreichung des Projektziels dar. Innerhalb eines Sprints können mehrere Inkremente erstellt werden. Die Summe dieser Inkremente wird im Sprint Review vorgestellt, und gründlich überprüft, um sicherzustellen, dass alle Inkremente zusammenarbeiten. Um einen Mehrwert zu erzielen, muss das Inkrement nutzbar und potentiell lieferfähig sein.
Die Definition of Done ist hierbei eine formale Beschreibung des Zustands des Inkrements, wenn es die für das Produkt erforderlichen Qualitätsmaßnahmen erfüllt. In dem Moment, in dem ein Product Backlog Element die Definition of Done erfüllt, wird ein Inkrement geboren. Die Definition of Done schafft Transparenz, indem sie allen ein gemeinsames Verständnis darüber vermittelt, welche Arbeiten im Rahmen des Inkrements abgeschlossen wurden. Wenn ein Product Backlog Element nicht der Definition of Done entspricht, kann es weder präsentiert noch freigegeben werden. Stattdessen wird es zur zukünftigen Prüfung zurück in den Product Backlog gegeben.
Verfasst von:
Diverse Autor*innen
