Wikipedia · einfach zusammengefasst · Stand
Scrum
Scrum (englisch für „Gedränge“) ist ein Vorgehensmodell des Projekt- und Produktmanagements, insbesondere zur agilen Softwareentwicklung.
Inhalt5 Abschnitte
Grundidee und Prinzipien
Scrum ist ein Vorgehensmodell des Projekt- und Produktmanagements, besonders für die agile Softwareentwicklung. Es wird inzwischen auch in anderen Bereichen eingesetzt. Scrum setzt auf kleine, selbstorganisierte, interdisziplinäre Teams: Von außen wird die Richtung beziehungsweise das Ziel vorgegeben, die Taktik zur Erreichung bestimmt das Team selbst.
Scrum besteht aus wenigen Regeln. Der Kern umfasst drei Verantwortlichkeiten, drei Artefakte und vier Ereignisse. Umsetzungstechniken wie User Stories, Taskboards oder Planungspoker gehören nicht zwingend zum Kern, sondern konkretisieren ihn. Die Grundidee ist empirisch, inkrementell und iterativ:
- Empirisch bedeutet, dass Entscheidungen auf Beobachtung und Erfahrung beruhen.
- Inkrementell bedeutet, dass das Produkt schrittweise durch nutzbare Teilprodukte erweitert wird.
- Iterativ bedeutet, dass Produkt, Planung und Vorgehen wiederholt überprüft und verbessert werden.
Viele Projekte sind zu komplex, um zu Beginn vollständig geplant zu werden. Deshalb wird zunächst ein langfristiger Plan, das Product Backlog, angelegt und fortlaufend verfeinert. Für den jeweils nächsten ein bis vier Wochen langen Sprint wird ein genauerer Detailplan, das Sprint Backlog, erstellt.
Die empirische Verbesserung beruht auf drei Säulen: Transparenz macht Fortschritt und Hindernisse regelmäßig für alle sichtbar. Überprüfung bedeutet, dass Projektergebnisse und Funktionalitäten regelmäßig geliefert und bewertet werden. Anpassung bedeutet, dass Anforderungen, Pläne und Vorgehen kontinuierlich verändert werden. Scrum verringert die Komplexität nicht, strukturiert sie aber in kleinere Bestandteile, die Inkremente.
Ziel ist die schnelle und kostengünstige Entwicklung hochwertiger Produkte entsprechend einer Vision. Anforderungen werden aus der Anwendersicht beschrieben und in Sprints umgesetzt. Am Ende jedes Sprints soll ein fertiges, getestetes und integriertes Product Increment vorliegen, das grundsätzlich ausgeliefert werden kann. Scrum ist für Teams mit drei bis neun Entwicklern konzipiert; ein Scrum-Team besteht höchstens aus zehn Mitgliedern. Für größere Vorhaben sind zusätzliche Skalierungs-Frameworks erforderlich.
Verantwortlichkeiten und Beteiligte
Ein Scrum-Team besteht aus den drei Verantwortlichkeiten Product Owner, Entwickler und Scrum Master. Die Fortschritte und Zwischenergebnisse sind für Stakeholder, also außerhalb des Scrum-Teams stehende Beteiligte, transparent.
Der Product Owner ist für die Eigenschaften und den wirtschaftlichen Erfolg des Produkts verantwortlich. Er erstellt, priorisiert, erläutert und aktualisiert die Anforderungen im Product Backlog und entscheidet allein über Produkteigenschaften und deren Reihenfolge. Er stimmt sich mit Stakeholdern ab und wägt deren unterschiedliche Interessen ab. Der Product Owner ist eine Person, kein Komitee. In der Praxis fehlt ihm jedoch häufig die notwendige Entscheidungsvollmacht oder er wird mit zusätzlichen Aufgaben überlastet.
Die Entwickler liefern die Funktionalitäten in der vom Product Owner bestimmten Reihenfolge und halten die vereinbarten Qualitätsstandards ein. Sie organisieren sich selbst; auch der Scrum Master schreibt ihnen nicht vor, wie sie Backlogeinträge umsetzen. Das Team soll interdisziplinär sein, beispielsweise mit Kompetenzen in Architektur, Entwicklung, Test, Dokumentation und Datenbanken. Gute oder schlechte Ergebnisse werden dem gesamten Team zugerechnet. Teammitglieder sollen sowohl spezialisiert als auch in der Lage sein, andere zu unterstützen.
Der Scrum Master sorgt dafür, dass Scrum als Rahmenwerk gelingt. Er führt die Regeln ein, überprüft ihre Einhaltung, beseitigt Hindernisse und unterstützt Kommunikation und Zusammenarbeit. Er moderiert häufig Sprint Planning, Product Backlog Refinement und Sprint-Retrospektive. Gegenüber dem Entwicklungsteam ist er eine dienende Führungskraft und ein Coach: Er gibt keine Arbeitsanweisungen, beurteilt die Teammitglieder nicht und übernimmt keine disziplinarische Führung.
Kunden erhalten das fertige Produkt; sie können interne Fachabteilungen oder externe Personen oder Gruppen sein. Anwender benutzen das Produkt und können, müssen aber nicht zugleich Kunden sein. Ihre Rückmeldungen sind besonders wichtig, weil sie die Funktionalität aus der Nutzungsperspektive beurteilen. Kunden und Anwender sollten insbesondere beim Sprint Review und Product Backlog Refinement einbezogen werden. Das Management stellt geeignete Rahmenbedingungen und Arbeitsmittel bereit, schützt das Team vor externen Arbeitsanforderungen, sorgt für passende Besetzung und unterstützt die Beseitigung von Hindernissen.
Sprints und Ereignisse
Ein Sprint ist ein Arbeitsabschnitt von ein bis vier Wochen, in dem ein Product Increment entsteht. Er beginnt mit dem Sprint Planning und endet mit Sprint Review und Sprint-Retrospektive. Sprints folgen unmittelbar aufeinander und sollten idealerweise gleich lang sein. Änderungen, die das Sprintziel beeinflussen, sind während eines Sprints nicht erlaubt. Ein Sprint wird nicht verlängert. Der Product Owner kann ihn vorzeitig abbrechen, wenn das Sprintziel nicht mehr sinnvoll ist; der Scrum Guide beschreibt solche Abbrüche als ressourcenintensiv und unüblich.
Im Sprint Planning werden drei Fragen beantwortet: Warum ist der Sprint wichtig? Was muss getan werden? Wie wird die Arbeit erledigt? Zuerst vereinbart das Scrum-Team ein Sprintziel. Danach stellt der Product Owner priorisierte Product-Backlog-Einträge vor. Das Team klärt Eigenschaften, Akzeptanzkriterien und die Definition of Done. Die Entwickler prognostizieren, wie viele Einträge sie liefern können; nur sie entscheiden über diese Menge, während der Product Owner die Reihenfolge bestimmt. Der Begriff Commitment wurde 2011 durch Forecast, also Prognose, ersetzt, weil Verpflichtungen häufig zu Lasten der Qualität führten. Anschließend zerlegen die Entwickler die ausgewählten Einträge in Tasks. Das Ergebnis ist das Sprint Backlog.
Das Daily Scrum findet an jedem Arbeitstag statt und dauert höchstens 15 Minuten. Es dient dem Informationsaustausch, nicht der Problemlösung. Üblicherweise berichtet jedes Teammitglied, was seit dem letzten Daily Scrum erreicht wurde, was bis zum nächsten erreicht werden soll und welche Hindernisse bestehen. Offene Fragen werden danach geklärt oder dem Scrum Master übergeben.
Im Sprint Review präsentiert das Entwicklungsteam das Inkrement. Scrum-Team und Stakeholder prüfen die Ergebnisse, vergleichen sie mit dem Sprintziel und besprechen die nächsten Schritte. Kunden und Anwender können die Funktionalität ausprobieren und wichtiges Feedback geben. Der Product Owner beurteilt anhand der vereinbarten Kriterien, ob Einträge fertig und abnahmefähig sind. Nicht fertige User Stories kehren ins Product Backlog zurück. Das Review dauert maximal 1 Stunde je Sprint-Woche.
In der Sprint-Retrospektive überprüft das Scrum-Team seine Arbeitsweise. Es sucht gute Praktiken und Verbesserungen für den nächsten Sprint. Die Veranstaltung findet in einem geschützten Raum statt; Stakeholder nehmen nur auf Einladung teil. Sie dauert maximal 45 Minuten je Sprint-Woche, also maximal drei Stunden bei einem Vier-Wochen-Sprint. Das Review untersucht hauptsächlich das Ergebnis und Stakeholder-Feedback, die Retrospektive dagegen Effektivität, Effizienz und Zusammenarbeit des Teams.
Artefakte und Umsetzungstechniken
Das Product Backlog ist eine geordnete, dynamische Liste der Produktanforderungen. Jede Arbeit des Entwicklungsteams muss dort ihren Ursprung haben. Der Product Owner ist für Pflege und Priorisierung verantwortlich. Das Backlog ist nicht vollständig; zunächst enthält es bekannte und gut verstandene Anforderungen. Priorisiert wird unter anderem nach wirtschaftlichem Nutzen, Risiko und Notwendigkeit.
Anforderungen sollen fachlich und anwenderorientiert formuliert werden. User Stories folgen häufig dem Muster: „Als [NUTZER] will ich [FUNKTION oder EIGENSCHAFT], damit [ZWECK].“ Die Eigenschaften guter User Stories werden mit INVEST beschrieben: Independent, Negotiable, Valuable, Estimable, Small und Testable. Im Product Backlog Refinement entwickeln Product Owner und Entwickler das Backlog fortlaufend weiter. Sie schätzen, ordnen, löschen, ergänzen, detaillieren und bündeln Einträge und planen Releases. Stakeholder können dabei Nutzungserwartungen erklären. Das Refinement sollte höchstens 10 % der Zeit des Entwicklungsteams beanspruchen.
Das Sprint Backlog ist der aktuelle Plan eines Sprints. Es enthält das Sprintziel, ausgewählte Product-Backlog-Einträge und die zugehörigen Tasks, etwa für Entwicklung, Test und Dokumentation. Die Entwickler aktualisieren es laufend. Das Product Increment ist die Summe der in aktuellen und früheren Sprints fertiggestellten Product-Backlog-Einträge. Am Sprintende muss es nutzbar sein und der Definition of Done entsprechen.
Die Definition of Done ist das gemeinsame Verständnis, wann Arbeit als fertig gilt. Sie enthält Qualitätskriterien, Einschränkungen und allgemeine nicht-funktionale Anforderungen, beispielsweise Kommentare, Unit Tests oder Design-Dokumente. Sie wird im Verlauf der Entwicklung weiterentwickelt und kann strengere Qualitätskriterien erhalten. Zusammen mit den Akzeptanzkriterien entscheidet sie über die Fertigstellung; für ihre Einhaltung ist das Team verantwortlich.
Häufige ergänzende Techniken sind Taskboards, Planungspoker, Impediment Backlogs und Burn-Down-Charts. Ein Taskboard visualisiert das Sprint Backlog meist mit den Spalten Anforderungen, noch zu erledigen, in Bearbeitung und erledigt. Planungspoker schätzt Aufwände mit Karten, etwa 0, ½, 1, 2, 3, 5, 8, 13, 20, 40 und 100 oder mit T-Shirt-Größen. Beim Burn-Down-Chart zeigt ein Sprint Burndown über Tage die noch offenen Tasks; idealerweise erreicht die Linie am Sprintende die Nulllinie. Ein Release Burndown zeigt über mehrere Sprints die noch offenen Product-Backlog-Einträge, beispielsweise in Story Points. Das Impediment Backlog sammelt Hindernisse, Lösungsaufgaben und deren Status.
Anpassungen, Grenzen und Einordnung
Unternehmen weichen unterschiedlich stark vom Scrum Guide ab. Wenig verändert werden meist Sprint-Länge, Ereignisse, Teamgröße und Requirements Engineering; häufiger variieren Rollen, Aufwandsschätzung und Qualitätssicherung. Abweichungen können begründet sein, entstehen aber auch durch eine unvollständige Umsetzung in hierarchischen, nicht agilen Organisationen.
Für größere Projekte und Organisationen gibt es unter anderem Scrum of Scrums, Large-Scale Scrum (LeSS), seit 2011 das Scaled Agile Framework (SAFe), seit 2015 Nexus von Ken Schwaber und seit 2018 Scrum@Scale von Jeff Sutherland.
Scrum bietet keine Erfolgsgarantie. Es macht Abweichungen vom Soll-Zustand früh sichtbar und verlangt, gewonnene Erkenntnisse tatsächlich für Änderungen zu nutzen. Werden die Ergebnisse der Überprüfung nicht angewendet, wird das Produkt nicht automatisch besser oder früher fertig.
Die Selbstorganisation kann Rollenkonflikte auslösen, wenn Teammitglieder weiterhin ausschließlich als Tester, Programmierer oder Architekt arbeiten wollen. Auch Machtkonflikte sind möglich, weil Scrum innerhalb des Entwicklungsteams keine Hierarchien vorsieht, Unternehmen ihre Mitarbeitenden aber häufig nach Rang und Bezahlung unterscheiden. Juristisch kann Scrum bei Werkverträgen und in Verbindung mit Produkthaftung schwierig sein, weil Leistung und Abnahmekriterien ungenauer sein können als bei traditionellen Vorgehensweisen.
Für Scrum existieren unter anderem Zertifizierungen von ScrumAlliance, Scrum.org und Scrum Inc.; alle erkennen den Scrum Guide als gemeinsamen zentralen Standard an. Die Gültigkeitsdauer unterscheidet sich: ScrumAlliance nennt 2 Jahre, Scrum.org eine unbegrenzte Gültigkeit und Scrum Inc. 1 Jahr. Werkzeuge wie Redmine, OpenProject, Jira und Azure DevOps unterstützen die Organisation von Backlogs, Aufgaben und Scrum-Prozessen, gehören aber nicht zum Scrum-Kern.
