Was ist der Scrum Guide?
Der Scrum Guide ist die verbindliche Definition von Scrum. Er wird von den Begründern Ken Schwaber und Jeff Sutherland herausgegeben, erschien erstmals 2010 und liegt seit November 2020 in der aktuellen Fassung vor [1]. Scrum selbst wurde bereits 1995 erstmals öffentlich vorgestellt. Der Guide ist bewusst kurz und beschreibt nur die Elemente, die für Scrum unverzichtbar sind; Praktiken wie User Stories, Story Points oder Burn-down-Charts gehören nicht dazu, sondern sind ergänzende Techniken.
Wichtig ist der Schlusssatz des Guides: Das Rahmenwerk ist unveränderlich. Wer nur Teile umsetzt, kann das tun, aber das Ergebnis ist dann nicht Scrum [1]. Das ist keine Formalität. Viele Probleme, die Teams Scrum zuschreiben, entstehen, weil zentrale Elemente fehlen, etwa die Retrospektive, ein klares Product Goal oder eine verbindliche Definition of Done. Die deutsche Fassung steht ebenfalls kostenlos zur Verfügung [2].
Auf welcher Theorie beruht Scrum?
Scrum beruht auf Empirie und Lean Thinking. Empirie heisst, dass Wissen aus Erfahrung entsteht und Entscheidungen auf Beobachtungen beruhen; Lean Thinking heisst, Verschwendung zu reduzieren und sich auf das Wesentliche zu konzentrieren [1]. Daraus ergeben sich drei Säulen: Transparenz, damit Arbeit und Fortschritt für alle sichtbar sind; Überprüfung, damit Abweichungen früh erkannt werden; und Anpassung, damit auf Erkenntnisse sofort reagiert wird.
Ergänzt wird die Theorie durch fünf Werte: Commitment, Fokus, Offenheit, Respekt und Mut. Sie sind keine Dekoration. Ohne Offenheit gibt es keine Transparenz, ohne Mut keine ehrliche Retrospektive, ohne Fokus kein erreichtes Sprint Goal. Teams, die mit Scrum Schwierigkeiten haben, finden die Ursache oft nicht in den Regeln, sondern in den Werten.
Wie ist ein Scrum Team zusammengesetzt?
Ein Scrum Team besteht aus einem Scrum Master, einem Product Owner und Developers. Innerhalb des Teams gibt es keine Sub-Teams und keine Hierarchien; es ist eine Einheit, die sich auf ein Ziel konzentriert, das Product Goal. Das Team ist cross-funktional, verfügt also über alle Fähigkeiten, um in jedem Sprint Wert zu schaffen, und selbstmanagend, entscheidet also intern, wer was wann und wie tut. Typischerweise umfasst es zehn oder weniger Personen [1].
| Verantwortlichkeit | verantwortlich für | typische Missverständnisse |
|---|---|---|
| Developers | Sprint Backlog erstellen, Qualität über die Definition of Done sichern, Plan täglich anpassen, sich gegenseitig zur Verantwortung ziehen | «Developers» meint nicht nur Programmierende, sondern alle, die am Increment arbeiten |
| Product Owner | Wert des Produkts maximieren, Product Goal entwickeln, Backlog-Einträge erstellen und ordnen, Transparenz des Backlogs | eine Person, kein Gremium; kann Aufgaben delegieren, bleibt aber verantwortlich |
| Scrum Master | Scrum etablieren, Wirksamkeit des Teams, Hindernisse beseitigen lassen, Events ermöglichen | kein Projektleiter und kein Protokollführer, sondern Führungskraft, die dient |
Seit 2020 spricht der Guide bewusst von Verantwortlichkeiten statt Rollen. Damit wird betont, dass es um Verantwortung geht, nicht um Stellenbezeichnungen. Eine Person kann formal Projektleiterin sein und im Scrum Team die Verantwortung des Product Owners übernehmen; entscheidend ist, dass die Verantwortung klar zugeordnet ist. Wird ein Team zu gross, empfiehlt der Guide, es in mehrere Scrum Teams aufzuteilen, die dasselbe Product Goal, denselben Product Backlog und denselben Product Owner teilen.
Welche Events kennt Scrum?
| Event | Zweck | Timebox bei einem Monat Sprint |
|---|---|---|
| Sprint | Container für alle Events, Ideen werden zu Wert | fix, höchstens ein Monat |
| Sprint Planning | Warum ist der Sprint wertvoll, was wird erledigt, wie | höchstens acht Stunden |
| Daily Scrum | Fortschritt zum Sprint Goal prüfen, Plan anpassen | 15 Minuten |
| Sprint Review | Ergebnis prüfen, mit Stakeholdern nächste Schritte festlegen | höchstens vier Stunden |
| Sprint Retrospective | Qualität und Wirksamkeit verbessern | höchstens drei Stunden |
Bei kürzeren Sprints sind die Events in der Regel kürzer, das Daily Scrum bleibt bei 15 Minuten [1]. Ein neuer Sprint beginnt unmittelbar nach dem Ende des vorherigen. Nur der Product Owner darf einen Sprint abbrechen, und zwar dann, wenn das Sprint Goal hinfällig geworden ist. Wie die Events in der Praxis gut gelingen, beschreibt der Beitrag Die fünf Scrum-Events richtig durchführen.
Welche Artefakte und Commitments gibt es?
| Artefakt | Inhalt | Commitment |
|---|---|---|
| Product Backlog | geordnete, sich entwickelnde Liste dessen, was das Produkt verbessern soll | Product Goal: angestrebter künftiger Zustand des Produkts |
| Sprint Backlog | Sprint Goal, ausgewählte Einträge und Plan zur Umsetzung | Sprint Goal: das eine Ziel des Sprints |
| Increment | nutzbarer Schritt zum Product Goal, additiv zu allen früheren | Definition of Done: formale Beschreibung der geforderten Qualität |
Die Commitments wurden 2020 eingeführt, um Transparenz und Fokus zu stärken [1]. Das Product Goal gibt dem Backlog eine Richtung; das Team muss ein Product Goal erfüllen oder aufgeben, bevor es das nächste angeht. Das Sprint Goal gibt dem Sprint einen Zweck und lässt Flexibilität in der konkreten Arbeit. Die Definition of Done legt fest, wann ein Eintrag fertig ist; erfüllt er sie nicht, darf er weder ausgeliefert noch im Review gezeigt werden, sondern geht zurück in den Backlog.
Was hat sich 2020 gegenüber 2017 geändert?
- Weniger präskriptiv: Der Guide ist kürzer und beschreibt Scrum stärker als Rahmenwerk für unterschiedliche Bereiche, nicht nur für Software.
- Ein Team, ein Produkt: Statt Entwicklungsteam innerhalb des Scrum Teams gibt es ein Scrum Team ohne Sub-Teams.
- Product Goal neu eingeführt als Commitment des Product Backlogs.
- Commitments für alle drei Artefakte: Product Goal, Sprint Goal, Definition of Done.
- Selbstmanagement statt Selbstorganisation: Das Team entscheidet, wer was wann und wie tut.
- Sprint Planning mit drittem Thema: Warum ist dieser Sprint wertvoll?
Was bedeutet der Guide für die Praxis?
Viele Teams arbeiten nach eigenen Varianten von Scrum, oft ohne es zu merken. Ein kurzer Abgleich mit dem Guide lohnt sich: Gibt es ein Product Goal, das alle kennen? Hat jeder Sprint ein Sprint Goal oder nur eine Liste von Aufgaben? Gibt es eine schriftliche Definition of Done, und wird sie eingehalten? Ist der Product Owner eine Person mit echter Entscheidungsbefugnis? Findet die Retrospektive regelmässig statt und führt sie zu Veränderungen? Wer drei dieser Fragen mit Nein beantwortet, hat den grössten Hebel für Verbesserungen gefunden.
Der Guide schreibt bewusst nicht vor, wie Backlog-Einträge formuliert, geschätzt oder visualisiert werden. Hier kommen ergänzende Praktiken ins Spiel: User Stories mit Akzeptanzkriterien, agile Schätzverfahren und Priorisierungsmethoden wie WSJF oder MoSCoW. Sie sind nützlich, aber nicht Teil von Scrum und können je nach Team unterschiedlich eingesetzt werden.
Scrum im Werkzeug abbilden
Für Scrum braucht es einen geordneten Product Backlog, Sprints mit Sprint Goal und Sprint Backlog, ein Board für den Fortschritt und eine sichtbare Definition of Done. In Flenio lassen sich Aufgaben auf Boards in Zyklen planen, Ziele hinterlegen und Zeiten erfassen. Für den Einstieg bieten sich die Seiten zu Scrum, Product Owner und Scrum Master auf flenio.ch an, ebenso die Checkliste für den Start eines agilen Teams.
Wie hängen Scrum und das Agile Manifest zusammen?
Scrum ist älter als das Agile Manifest: Schwaber und Sutherland stellten Scrum 1995 vor, das Manifest entstand 2001. Beide teilen aber dieselben Grundgedanken. Die vier Werte des Manifests, etwa Reagieren auf Veränderung mehr als das Befolgen eines Plans, finden sich in den Säulen und Werten von Scrum wieder [3]. Scrum übersetzt diese Werte in konkrete Regeln: feste Zyklen, klare Verantwortlichkeiten und regelmässige Gelegenheiten zur Überprüfung. Wer Scrum nur als Satz von Meetings versteht, ohne die dahinterliegenden Werte, erhält Rituale ohne Wirkung.
Ein praktischer Tipp für den Einstieg: Lesen Sie den Scrum Guide gemeinsam im Team, Abschnitt für Abschnitt, und notieren Sie zu jedem Abschnitt, wo Ihre heutige Praxis abweicht. Die Liste ist ein guter Ausgangspunkt für die nächsten Retrospektiven, weil sie konkrete, gemeinsam erkannte Abweichungen enthält statt allgemeiner Eindrücke. Wiederholen Sie die Übung nach einigen Monaten, um zu sehen, was sich verändert hat.
So wird der Guide vom Nachschlagewerk zum gemeinsamen Arbeitsinstrument des Teams.
Scrum im Verhältnis zu anderen Standards
Scrum ist ein Rahmenwerk für die Produktentwicklung, kein vollständiges Projektmanagementsystem. Fragen nach Budget, Verträgen, Portfolio oder Governance beantwortet der Guide nicht. In Organisationen wird Scrum deshalb oft in einen grösseren Rahmen eingebettet, etwa in HERMES agil oder in hybride Vorgehen nach ISO 21502 und PMBOK. Den Gesamtzusammenhang zeigt der Leitfaden Agiles Projektmanagement in der Praxis.