Scrum ist ein Rahmenwerk aus dem Projekt- und Produktmanagement, das vorrangig in der Softwareentwicklung eingesetzt wird. Die Idee ist den beiden US-amerikanischen Softwareentwicklern Jeff Sutherland und Ken Schwaber um 1993 herum gekommen. Der Begriff Scrum ist allerdings noch älter und kann den beiden Wissensmanagement-Wissenschaftlern Ikujirō Nonaka und Hirotaka Takeuchi zugerechnet werden, die ihn in dem 1986 im Harvard Business Review veröffentlichten Beitrag The New New Product Development Game verwendeten. Scrum ist ein Begriff aus dem Rugby und kann mit „Gedränge“ übersetzt werden.
Seit dem Jahr 2010 wird Scrum über den sogenannten Scrum Guide von Sutherland und Schwaber definiert und unregelmäßig aktualisiert. In diesem Artikel beziehe ich mich auf die Scrum Guide Revision 2020 von Scrum.
Der Lesbarkeit halber verzichte ich auf die Nennung der weiblichen Rolle. Unter „Entwicklern“ sind sowohl weibliche Entwicklerinnen als auch männliche Entwickler zu verstehen. Ebenfalls zugunsten der Lesbarkeit verzichte ich für die Scrum-spezifischen Begriffe auf den Einsatz von Bindestrichen, also z.B. „Sprint Inkrement“ anstatt „Sprint-Inkrement“.
Der Sprint
Im Zentrum von Scrum steht der Sprint als allumfassendes Event. Ein Sprint ist ein auf zwei bis vier Wochen begrenzter Abschnitt in der Arbeit des Scrum Teams, der durch vier Ereignisse geprägt ist und an dessen Ende ein Sprint Inkrement entsteht. Ein Sprint wird geplant und in der Planung ein Sprintziel vereinbart. Am Ende des Sprints wird das Ergebnis den Stakeholdern präsentiert und innerhalb des Teams reflektiert. Auf das Ende eines Sprints folgt direkt der nächste. Nun aber erstmal zurück zu Scrum.
Scrum Definition und Scrum Theory
Scrum ist ein leichtgewichtiges Framework, das Menschen, Teams und Organisationen darin unterstützt, komplexe Probleme durch eine flexible, anpassungsfähige Vorgehensweise zu adressieren und wertschöpfend zu handeln.
Scrum ist betont unvollständig, jedoch strikt in seiner Auslegung. In der Schlussbemerkung des Scrum Guides wird darauf hingewiesen, dass eine nur teilweise Umsetzung des Scrum-Frameworks zwar möglich ist, jedoch dann nicht als Scrum bezeichnet werden sollte.
Scrum basiert auf Erfahrungswissen und orientiert sich am Lean Thinking. Die Umsetzung erfolgt inkrementell und iterativ in sogenannten Sprints. Auf das Ende eines Sprints folgt der nächste Sprint. Teilnehmer im Sprint ist das Scrum Team, das über alle notwendigen Fähigkeiten und Fachkenntnisse zur Umsetzung der Aufgaben verfügt.
Das Vorgehen soll eine gute Risikokontrolle bieten und die Vorhersagbarkeit optimieren. Drei wesentliche Schlüsselmerkmale des Scrum-Prozesses sind:
- Transparenz
- Überprüfbarkeit
- Anpassung
Scrum Values
Das Scrum-Team lebt die folgenden fünf Werte:
- Commitment (Verpflichtung)
- Fokus
- Offenheit
- Respekt
- Mut
Das Scrum Team sagt zu, seine Ziele zu erreichen und sich gegenseitig zu unterstützen. Es konzentriert sich auf die Arbeit des Sprints und die bestmögliche Erreichung seiner Ziele. Zwischen dem Scrum Team und den Stakeholdern, aber auch zwischend den Mitgliedern des Scrum Teams herrschen Offenheit und Respekt. Das Scrum Team bringt den Mut auf, komplexe Probleme zu lösen und Entscheidungen zu treffen, um seine Ziele zu erreichen.
Scrum Team
Ein Scrum Team besteht aus Scrum Master, Product Owner und Entwicklern. Scrum Teams sind selbstverwaltend und interdisziplinär. Sie bestehen üblicherweise aus bis zu zehn Personen. Innerhalb eines Teams gibt es keine Hierarchien.
Das Scrum Team ist umsetzungsverantwortlich für die Zusammenarbeit mit den Stakeholdern und alles, was das Produkt betrifft. Das kann z.B. Sicherheit, Wartung, Betrieb, Entwicklung und Forschung beinhalten.
Das Scrum Team ist ergebnisverantwortlich dafür, in jedem Sprint ein wertvolles Inkrement zu schaffen.
Entwickler
Entwickler sind diejenigen Mitglieder des Scrum Teams, die es sich zur Aufgabe gemacht haben, das Sprint Inkrement zu schaffen. Sie sind im Wesentlichen für folgende Aspekte der Sprint-Umsetzung verantwortlich:
- einen Plan für den Sprint, das Sprint Backlog, zu erstellen
- die Definition of Done einzuhalten
- täglich ihren Plan zur Erreichung des Sprintziels anzupassen
- sich wechselseitig als Experten zur Verantwortung zu ziehen
Product Owner
Der Product Owner ist ergebnisverantwortlich für die Wertmaximierung des Produktes. Dazu verantwortet der Product Owner das Product Backlog, was sich in folgenden Verantwortlichkeiten niederschlägt:
- Entwicklung und Kommunikation des Produktzieles
- Einträge im Product Backlog zu erstellen, priorisieren und klar zu kommunizieren
- Sichtbarkeit und Verständlichkeit des Product Backlogs sicherzustellen
Die Entscheidungen und Handlungen des Product Owners müssen in der gesamten Organisation respektiert werden. Sie sind über die Einträge im Product Backlog sowie den Sprint Inkrementen, die in den Sprint Reviews vorgestellt werden, transparent.
Der Product Owner ist eine Person, kein Gremium. Er kann versuchen die Bedürfnisse der Stakeholder zu berücksichtigen. Um Änderungen im Product Backlog vorzunehmen, kann versucht werden, den Product Owner davon zu überzeugen.
Scrum Master
Scrum Master sind verantwortlich dafür, Scrum in der Organisation einzuführen und Scrum-Theorie und -Praxis nach dem Scrum Guide zu vermitteln. Der Scrum Master ist ergebnisverantwortlich für die Effektivität des Scrum Teams. Scrum Master dienen dem Scrum Team und der Organisation.
Der Scrum Master dient dem Scrum Team durch:
- Coaching, zur Verbesserung des Selbstmanagements und der interdisziplinären Zusammenarbeit
- Unterstützung des Scrum Teams, sich auf die Schaffung hochwertiger Sprint Inkremente nach der Definition of Done zu konzentrieren
- Beseitigung von Hindernissen (Impediments)
- Sicherstellung der positiven und produktiven Durchführung aller Scrum Events
Der Scrum Master dient dem Product Owner durch:
- Techniken zur effektiven Definition des Produktzieles und Verwaltung des Product Backlogs
- Coaching des Scrum Teams, die Notwendigkeit klarer und präziser Einträge im Product Backlog zu verstehen
- Etablierung einer empirischen Produktplanung
- Optimierung der Zusammenarbeit mit den Stakeholdern
Der Scrum Master dient der Organisation durch:
- Coaching, Begleitung, Führung und Planung bei der Einführung von Scrum
- Unterstützung von Mitarbeitern und Stakeholdern bei der Umsetzung eines empirischen Ansatzes zur komplexen Arbeit
- Beseitigung von Barrieren zwischen Scrum Teams und Stakeholdern
Scrum Events
Scrum Events sind Events innerhalb eines Sprints zur Überprüfung und Anpassung von Scrum Artefakten. Events schaffen Regelmäßigkeit und minimieren die Notwendigkeit von Meetings. Events sollten nach Möglichkeit zu festen Zeiten an festen Orten stattfinden, um die Komplexität zu reduzieren.
Rahmenbedingungen eines Sprints
Innerhalb eines Sprints finden Sprint Planning, Daily Scrums, Sprint Review und Sprint Retrospektive statt. Während eines Sprints werden keine Änderungen vorgenommen, die das Sprintziel gefährden. Umfang und Inhalt eines laufenden Sprints können mit dem Product Owner neu vereinbart werden, wenn sich Anpassungsbedarf ergibt. Ein Sprint kann abgebrochen werden, wenn das Sprintziel hinfällig wird. Eine Entscheidung darüber obliegt allein dem Product Owner.
Sprints ermöglichen Vorhersagbarkeit, da mindestens einmal pro Monat eine Überprüfung und Anpassung des Fortschrittes hinsichtlich des Produktzieles stattfindet. Jeder Sprint kann als ein kurzes Projekt betrachtet werden.
Sprint Planning
Das Sprint Planning steht zu Beginn eines Sprints. Im Sprint Planning werden das Sprintziel definiert und das Sprint Backlog gefüllt. Der Product Owner stellt sicher, dass das Scrum Team vorbereitete ist, Einträge aus dem Product Backlog zur Umsetzung im Sprint zu besprechen.
Das Sprint Planning adressiert die folgenden Fragen:
- Warum ist dieser Sprint wertvoll?
- Was kann in diesem Sprint abgeschlossen (Done) werden?
- Wie wird die ausgewählte Arbeit erledigt?
Der Product Owner schlägt im Sprint Planning vor, wie das Produkt im aktuellen Sprint seinen Wert und Nutzen steigern könnte. Das Scrum Team arbeitet anschließend gemeinsam an der Definition eines Sprintzieles, das diese Wertsteigerung gegenüber den Stakeholdern zum Ausdruck bringt.
Die Entwickler wählen dann im Austausch mit den Product Ownern Einträge aus dem Product Backlog zur Bearbeitung im Sprint aus. Im Rahmen der Auswahl können diese Einträge verfeinert werden. Die Summe der ausgewählten Einträge ergibt sich aus den bisherigen Erfahrungen des Scrum Teams, der im Sprint vorhandenen Kapazität und der Definition of Done.
Jeden ausgewählten Eintrag aus dem Product Backlog brechen die Entwickler dann in kleinere Arbeitseinheiten von je maximal einem Tag Aufwand runter. Die Gesamtdauer des Sprint Plannings beträgt bei einem vierwöchigen Sprint maximal acht Stunden und ist bei kleineren Sprints entsprechend kürzer.
Daily Scrum
Das Daily Scrum ist ein täglich stattfindendes Event von 15 Minuten unter Entwicklern. Scrum Master und Product Owner nehmen teil, falls sie als „Entwickler“ an Aufgaben im Sprint Backlog mitarbeiten.
Das Daily Scrum verfolgt mehrere Ziele:
- Bewertung des Fortschrittes hinsichtlich des Sprintziels
- ggf. Anpassung des Sprint Backlogs
- Abstimmung der geplanten Arbeit
- Identifizierung von Hindernissen
- Verbesserung der Kommunikation
- schnelle Entscheidungsfindung
Entwickler treffen sich auch außerhalb des Daily Scrums für detaillierte Diskussionen zur Abstimmung oder Neuplanung der restlichen Arbeit im Sprint.
Sprint Review
Im Sprint Review präsentiert das Scrum Team den Stakeholdern, was im Sprint erreicht wurde. Das Sprint Review bietet Raum zur Überprüfung des Fortschrittes und für zukünftige Anpassungen. Das Sprint Review beschränkt sich nicht auf eine einseitige Vorstellung der Ergebnisse, sondern lässt Raum für Diskussionen und die gemeinsame Planung, was als nächstes verfolgt wird. Auch können im Rahmen des Sprint Reviews neue Einträge ins Product Backlog aufgenommen werden.
Das Sprint Review ist bei vierwöchigen Sprints auf maximal vier Stunden begrenzt und bei kleineren Sprints entsprechend kürzer.
Sprint Retrospective
Mit der Sprint Retrospektive wird der Sprint beendet. In der Sprint Retrospektive reflektiert das Scrum Team über den vergangenen Sprint, was gut und was nicht so gut gelaufen ist, welche Probleme es gegeben hat und wie diese angegangen wurden. Das Scrum Team überprüft, wie der Sprint in Hinblick auf Individuen, Interaktionen, Prozesse, Werkzeuge und die Definition of Done verlaufen ist. Aus den erarbeiteten Erkenntnissen können sich neue Aufgaben und Einträge im Product Backlog ergeben, die die zukünftige Qualität der Sprint Inkremente und Effektivität des Scrum Teams steigern.
Scrum Artifacts
Scrum Artefakte machen die Arbeit des Scrum Teams transparent. Jedes Artefakt beinhaltet ein Commitment, um Transparenz und Fokus sichtbar zu machen und den Fortschritt zu bewerten:
- Das Produktziel als Commitment für das Product Backlog
- Das Sprintziel als Commitment für das Sprint Backlog
- Die Definition of Done als Commitment für das Sprint Inkrement
Product Backlog und Produktziel
Das Product Backlog ist eine Liste von Dingen zur Verbesserung des Produktes und die einzige Quelle von Arbeit für das Scrum Team. Einträge im Product Backlog laufen durch einen vom Scrum Team durchgeführten Refinement-Prozess. Das Refinement wird im Scrum Guide als kontinuierlicher Prozess beschrieben und wird vermutlich daher nicht als Scrum Event erwähnt. Im Refinement-Prozess werden die Einträge zerlegt und präzisiert, so dass sie in einem zukünftigen Sprint Planning in das Sprint Backlog aufgenommen werden können.
Das Produktziel ist das langfristige Ziel des Scrum Teams und beschreibt einen zukünftigen Zustand des Produktes. Das Produktziel dient dem Scrum Team zur Planung, um Zwischenziele zu formulieren. Das Produktziel ist ein Eintrag im Product Backlog. Alle weiteren Einträge zahlen in irgendeiner Form auf die Erreichung des Produktzieles ein.
Sprint Backlog und Sprintziel
Das Sprint Backlog setzt sich aus drei Bestandteilen zusammen:
- dem Was: Einträge aus dem Product Backlog
- dem Wofür: Das Sprintziel
- dem Wie: Ein umsetzbarer Plan für die Lieferung des Sprint Inkrements
Das Sprint Backlog ist ein Echtzeitabbild der Arbeit, welche die Entwickler in einem Sprint zur Erreichung des Sprintziels umsetzen. Das Sprint Backlog dient der Überprüfung des Fortschrittes im Daily Scrum und wird aktuell gehalten.
Das Sprintziel ist das Commitment der Entwickler auf die Zielsetzung des Sprints. Es schafft Kohärenz, indem es Einträge aus dem Product Backlog zu einem höheren Ziel zusammenfasst, und Fokus, indem es Klarheit zur Priorisierung im Sprint schafft. Damit ermutigt es das Scrum Team, gemeinsam an der Erreichung zu arbeiten.
Sprint Increment und Definition of Done
Ein Sprint Inkrement ist ein konkreter Schritt in Richtung des Produktzieles. Jedes Inkrement baut auf den vorherigen auf und ist gründlich geprüft, denn nur wenn es verwendbar ist, stellt es auch einen Mehrwert dar. In einem Sprint kann mehr als ein Inkrement abgeliefert werden. Inkremente könne auch schon vor Durchführung des Sprint Reviews an die Stakeholder ausgeliefert werden.
Die Definition of Done beschreibt den Zustand eines Eintrages aus dem Product Backlogs, der erreicht werden muss, damit es als fertig angesehen werden kann. Zu diesem Zeitpunkt entsteht daraus ein Sprint Inkrement (bzw. es wird Teil eines Sprint Inkrementes). Einträge, die nicht der Definition of Done entsprechen, werden im Sprint Review nicht präsentiert und auch nicht veröffentlicht, sondern werden zur zukünftigen Berücksichtigung zurück ins Product Backlog verschoben.
Die Definition of Done schafft Transparenz und ein allgemeines Verständnis darüber, wann eine Arbeit als abgeschlossen gilt. Gleichzeitig definiert sie ein erforderliches Mindestmaß an Qualität. Für die Definition of Done kann ein organisationsweiter Standard existieren, andernfalls muss das Scrum Team eine für das Produkt geeignete Definition of Done zusammenstellen.
Zusammenfassung
Scrum ist ein iteratives Framework im Projekt-/Produktmanagement zur Entwicklung eines Produktzieles. Das Produktziel wird über eine Menge an Einträgen in einem Product Backlog erreicht. Die Arbeit erfolgt im Rahmen von festen maximal vier Wochen andauernden Zyklen, den Sprints. Ein Sprint wird durch das Sprint Planning eingeleitet, in dessem Rahmen aus dem Product Backlog das Sprint Backlog erarbeitet wird. Die Wertschöpfung im Sprint ergibt sich aus dem Sprintziel, auf das die ins Sprint Backlog aufgenommenen Einträge aus dem Product Backlog einzahlen. Teilnehmer des Sprints ist das Scrum Team, das sich aus dem Scrum Master, dem Product Owner und den Entwicklern zusammensetzt. Die Entwickler synchronisieren sich täglich im Daily Scrum und überprüfen den Fortschritt des Sprintzieles. Bis zum Ende des Sprints werden ein oder mehrere Sprint Inkremente geschaffen, die den Kriterien der Definition of Done standhalten müssen und im Sprint Review den Stakeholdern präsentiert werden. Abgeschlossen wird der Sprint mit der Sprint Retrospektive, die dem Scrum Team Raum zur Reflektion gibt und die zukünftige Arbeit verbessern soll.