Scrum Guide
Inhaltsverzeichnis: Spielregeln – Inhalt – Simplifikationen – Neuerungen – Klarstellungen – Fehlende Begriffe – Download – Hinweise
Wissen kompakt: Der Scrum Guide definiert Scrum mit seinen Spielregeln. Die aktuelle Version – Scrum Guide 2020 – beinhaltet zahlreiche Vereinfachungen, Neuerungen und Klarstellungen.
Scrum Guide – das Dokument, das die Spielregeln von Scrum beschreibt
Scrum ist ein Framework, das Menschen, Teams und Organisationen hilft, Werte durch adaptive Lösungen für komplexe Probleme zu generieren. Es wird in der Produkt- und Softwareentwicklung und auch im Projektmanagement genutzt. Die Definition und die Spielregeln von Scrum sind im Scrum Guide festgehalten.
Herausgegeben wird der Scrum Guide durch die beiden Urheber von Scrum Ken Schwaber und Jeff Sutherland. Die aktuelle Version wurde am 18. November 2020 veröffentlicht. Nach den Ausgaben in den Jahren 2010, 2011, 2013, 2016 und 2017 ist es die 6. Ausgabe. Der Titel lautet: “The Scrum Guide. The Definite Guide to Scrum: The Rules of the Game”. Der Hinweis “Definite Guide” könnte ein Indikator sein, dass bis zu einer 7. Auflage sehr viel Zeit vergehen wird. Verfügbar ist der Guide in über 30 Sprachen.¹
Der Inhalt des Scrum Guides
Der Scrum Guide 2020 umfasst folgende Inhalte:
- Purpose des Dokuments
- Scrum Definition, Theorie und Werte
- Scrum Team mit Entwicklern, Product Owner und Scrum Master
- Scrum Events mit Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospektive
- Scrum Artefakte mit Product Backlog, Sprint Backlog und Inkrement sowie entsprechenden Commitments in Form von Product Goal, Sprint Goal und Definition of Done
- Erklärung zum Abschluss inklusive Verlautbarungen wie Danksagungen und Historie des Scrum Guides²
Interessant ist, dass im Guide selbst eine Einschätzung zu Scrum zu finden ist. Demnach verstehen die beiden Urheber Scrum als leichtgewichtiges Framework und nicht als Methode. Der Scrum Guide selbst ist keine Anleitung, wie Scrum umzusetzen ist, sondern “lediglich” eine Beschreibung des Frameworks. Innerhalb des Frameworks können verschiedene Methoden, Prozesse oder Techniken zum Einsatz kommen. Jedes beschriebene Element im Guide dient einem bestimmten Zweck, der für den Gesamtwert und die mit Scrum erzielten Ergebnisse wesentlich ist.
Simplifikationen im Scrum Guide 2020
Der Scrum Guide 2020 ist schlanker als sein Vorgänger: 13 Seiten umfasst die aktuelle Version, 20 waren es bei der Vorgängerversion. Mehrfach wird betont, dass Anwender einen smarten und intelligenten Umgang mit Scrum pflegen sollen, basierend auf den weiterhin vorhandenen Säulen Transparenz, Inspection (Überprüfung) und Adaption (Anpassung). Der Kontext ist wesentlich für die Anwendung des Frameworks, so dass sich die Autoren entschieden haben, verschiedene beschreibende Elemente und Erläuterungen einfach wegzulassen:
- Generell werden Events weniger detailliert beschrieben. Bspw. werden beim Daily Scrum die drei in der Praxis gebräuchlichen Fragen nicht mehr benannt und es gibt keinen Hinweis darauf, dass eine identifizierte Prozessverbesserung zur Gewährleistung einer kontinuierlichen Verbesserung in das Sprint Backlog aufgenommen werden sollte. Auch die sehr umfassende Beschreibung der Elemente eines Sprint Reviews oder die detaillierten Gründe, wozu eine Retrospektive durchgeführt wird, existieren nicht mehr.
- Auf Hinweise wie “Das Refinement sollte nicht mehr als 10% der Kapazität des Development Teams beanspruchen”, “Scrum ist leichtgewichtig, einfach zu verstehen, aber schwierig zu meistern” oder “mangelndes Produktverständnis ist ein Impediment” wurde verzichtet.
- Allgemeine Erläuterungen wurden weggelassen. Auch wenn sich Anforderungen auch weiterhin ändern werden, und der Fortschritt einer Entwicklung überwacht werden muss, so finden sich keine Hinweise darauf im Scrum Guide.
Bei diesen Simplifikationen geht es nicht darum, gelebte und sinnvolle Praktiken als nutzlos zu deklarieren. Sie verfolgen ein anderes Ziel: dadurch das der Scrum Guide weniger präskriptiv ist, gibt es weniger “obligatorische” Elemente. Folglich wird das Framework benutzerfreundlicher und erlaubt es Anwendern, die Elemente und Praktiken zu nutzen, die in ihrem Kontext sinnvoll sind. In gewisser Weise gibt es also weniger Zwang und mehr Freiheit. Und sicherlich ist es für viele Organisationen auch zukünftig sinnvoll, das Daily Scrum mit drei einheitlichen Fragen und einer Ausrichtung auf das Sprint Goal zu strukturieren.
Neuerungen im Scrum Guide 2020
Natürlich werden im Scrum Guide 2020 nicht zur Informationen weggelassen bzw. simplifiziert. Es gibt auch einige Neuerungen:
- die Verwendung von Accountabilitys anstelle von Rollen,
- die Definition eines Product Goals (Produktziels),
- die Betonung von Commitments bei Artefakten,
- und Selbstmanagement ersetzt Selbstorganisation.
Accountabilitys anstelle von Rollen
Im Scrum Guide 2020 wird der Begriff Rolle durch Accountability (Verantwortlichkeit) ersetzt. Die Accountabilitys teilen sich in drei Gruppen:
- Scrum Master,
- Product Owner und
- Developer (Entwickler).
Der Gedanke dahinter: es geht bei den Bezeichnungen nicht um Stellenbeschreibungen, sondern um ein Minimum an Verantwortlichkeiten, die zur Ausführung von Scrum erforderlich sind. Inhaltlich ändert sich Scrum dadurch nicht; Rollen wurden schon immer durch eine Reihe von Verantwortlichkeiten beschrieben. Klar wird die Änderungen bei einem Blick auf die Jobtitel “Scrum Master” oder “Product Owner”. Diese werden auch zukünftig in vielen Organisationen benutzt werden, die Stellenbeschreibungen werden allerdings umfangreicher sein als die Verantwortlichkeiten, die im aktuellen Scrum Guide beschrieben sind.
Darüber hinaus gibt es im Kontext der Accountabilitys bzw. Rollen eine weitere Anpassung: In der Vorgängerversion des Scrum Guides wurde von einem Development Team (Entwicklungsteam) gesprochen. Fortan wird nur noch von Entwicklern gesprochen. Entwickler bzw. Developer sind die Leute im Scrum Team, die sich im einem Sprint dazu verpflichtet haben, jegliche Aspekte eines Inkrements zu erstellen. In der Praxis bedeutet dies, dass sich fortan nicht nur Softwareentwicklern angesprochen fühlen dürfen, sondern alle Beteiligten – also bspw. auch Manager in der Linie, UX Designer oder Marketingmitarbeiter, die aktiv in einem Sprint mitwirken.
Product Goal
Neu im Scrum Guide 2020 ist das Product Goal. Als Äquivalent zum Sprint Ziel, das die Ausrichtung für das Sprint Backlog vorgibt, liefert das Product Goal den Rahmen für das Product Backlog. Es lässt sich als Antwort auf ein “Why” bzw. “Warum” verstehen: “Why are we doing all of this work?” bzw. “Warum leisten wir die gesamte Arbeit?” Und damit gibt es eine Richtung für das Scrum Team und die Stakeholder vor, liefert einen Kontext und einen Zweck.
Das Product Goal, das im Product Backlog transparent gemacht werden sollte, ist für das Scrum Team erstrebenswert und muss messbar sein. Die konkrete Ausgestaltung, aber auch die Messung ist natürlich kontextabhängig. In gewisser Weise gibt es eine Wechselwirkung zwischen Product Backlog und Product Goal: Das Product Goal hilft dabei, dass Product Backlog zu entwickeln. Und die Entwicklung des Product Backlogs kann Auswirkungen auf das Product Goal haben. Dieses kann sich also auch im Laufe der Zeit entwickeln.
Und wo liegt der Unterschied zwischen Product Goal und einer Vision? In der 2017er Version des Scrum Guides hieß es: “Das Inkrement ist ein Schritt in Richtung einer Vision oder eines Ziels.” In der aktuellen Ausgabe heißt es hingegen übersetzt: “Ein Inkrement ist ein konkretes Zwischenziel auf dem Weg zum Product Goal.” Da Scrum weiterhin Teams ermutigt, schrittweise Fortschritte in Richtung eines Ziels zu machen, ist der Unterschied eher marginal. In der Praxis könnte es so sein, dass ein Vision Statement das Product Goal im Detail beschreibt, oder dass das Product Goal ein erster Schritt zu einer größeren Vision ist. Kurzum: Die Verwendung der Begriffe Vision, Mission, Strategie und nun auch Product Goal hängt vom Kontext ab.
Commitments bei Artefakten
Mit der Veröffentlichung des Scrum Guides 2020 werden für jedes Artefakt Commitments hinzugefügt:
- Für das Product Backlog das Product Goal,
- für das Sprint Backlog das Sprint Goal und
- für das Inkrement die Definition of Done.
Ziel ist es, durch das jeweilige Commitment zu dem jeweiligen Artefakt Informationen bereitzustellen, um die Transparenz und den Fokus zu erhöhen, an denen der Fortschritt gemessen werden kann.
Alle Commitments sind obligatorisch, die Ausgestaltung ist aber kontextabhängig. Die Verantwortung für die Commitments liegt beim Product Owner für das Product Goal (er ist auch verantwortlich für das Product Backlog), und beim Scrum Team für das Sprint Ziel bzw. die Definition of Done.
Commitment als Begriff taucht auch weiterhin bei den Scrum Werten (neben Fokus, Offenheit, Respekt und Mut) auf.
Selbstmanagement anstelle von Selbstorganisation
In der gängigen Praxis werden die Begriffe Selbstorganisation und Selbstmanagement oft synonym verwendet. Warum ersetzt also im Scrum Guide fortan das Selbstmanagement die Selbstorganisation? Ziel ist es, den Fokus noch stärker auf das Scrum Team zu richten. Es ist verantwortlich für alle produktbezogenen Aktivitäten, bspw. für Zusammenarbeit mit Stakeholdern, die Durchführung von Experimenten, die Entwicklung, den Betrieb oder die Wartung eines Produkts. Damit das Scrum Team dies leisten kann, muss es durch die Organisation befähigt werden, sich selbst zu managen. Dieses Selbstmanagement geht über die Selbstorganisation hinaus, zumal damit nicht nur die Organisation der eigenen Arbeit adressiert wird, sondern auch die Befähigung zu entscheiden, wer innerhalb des Teams was wann und wie erledigt.
Der Scrum Guide äußert sich übrigens nicht explizit zu Managern in Organisationen. Diese könnten weiterhin außerhalb des Scrum Teams agieren, um es zu unterstützen. Sie könnten auch als Teil des Scrum Teams an der Erstellung eines Inkrements mitwirken. Grundsätzlich gilt, dass der Scrum Guide auch weiterhin jegliche Einmischung des Managements “von außen” mit negativen Einfluss auf das Sprint Goal und/oder das Product Goal negiert. Damit Scrum funktioniert, muss das Scrum Team die Freiheit besitzen, die Verantwortung für die zu erledigende Arbeit zu übernehmen, also für das wer, was, wann und wie. Selbstmanagement ist daher der passende Begriff.
Klarstellungen aus dem Scrum Guide 2017
Neben den Simplifikationen und Neuerungen finden sich im aktuellen Scrum Guide auch weiterhin Aussagen zu Aspekten, die mit der 2017er Version klargestellt wurden:
- Auch wenn Scrum seine Wurzeln in der Softwareentwicklung hat, eignet sich die Elemente und Regeln durch ihren iterativen, inkrementellen Ansatz generell für jegliche Produkt- oder Serviceentwicklung. Bestärkt wird dies in der aktuellen Ausgabe durch den expliziten Verzicht auf beschreibende Erläuterungen aus dem Kontext der Softwareentwicklung.
- Es bleibt die Aufgabe des Scrum Masters, Scrum im Sinne des Scrum Guides umzusetzen. Darüber hinaus unterstützt er das Scrum Team, den Product Owner und auch die gesamte Organisation.
- Alle Meetings arbeiten mit Timeboxes. Natürlich dürfen diese auch weiterhin als “maximale” Timeboxes verstanden werden, so dass entsprechende Events auch schon vor Ablauf einer Timebox beendet werden können.
- Das Daily Scrum orientiert sich am Sprint-Ziel auch wenn die drei “üblichen” Fragen nicht mehr explizit erwähnt werden.
- Das Sprint Review orientiert sich auch weiterhin am Sprint Ziel. Dabei präsentiert das Scrum Team die Ergebnisse den wichtigsten Stakeholdern und der Fortschritt der Entwicklung in Richtung Product Goal wird diskutiert. Grundsätzlich handelt es sich wie gehabt um ein “Arbeitstreffen” und keine Freigabe-Präsentation.
“Fehlende” Begriffe im Scrum Guide
In der Vergangenheit gab es immer wieder Stimmen, die behaupten, “Was nicht im Scrum Guide steht, ist kein Scrum!”. Tatsächlich handelte es sich um ein relativ praxisfremdes Argument; viele Elemente, die in zahlreichen Scrum Projekten und Entwicklungen genutzt wurden, befanden sich nicht im Scrum Guide.
Durch die Simplifikationen ist der Scrum Guide von 20 auf 13 Seiten “geschrumpft”. Explizit wird erwähnt, dass der Scrum Guide “absichtlich unvollständig” ist und lediglich die Teile definiert, die für die Implementierung der Scrum Theorie notwendig sind. Es ist faktisch also egal, dass folgende Begriffe keine Erwähnung finden:
- Velocity
- Grooming (Refinement wird aber einmal erwähnt)
- Standup Meeting
- Definition of Ready
- Scrum of Scrums bzw. Skalierung
- Story Points
- Traceability bzw. Nachvollziehbarkeit
- Vegas Regel
- …
Und übrigens: Auch wenn Scrum das am weitesten verbreitete Framework im agilen Kontext ist, die Begriffe “agil”, “Agilität” oder Transformation tauchen auch nicht auf.
Impuls zum Diskutieren:
Die Scrum Theorie basiert laut Scrum Guide 2020 auf Empirie und Lean Thinking. Von Lean Thinking war in der 2017er Version kein Wort zu lesen. Umfasst Lean Thinking nicht deutlich mehr als nur Simplifikation?
Hinweise:
Haben Sie Lust auf einen neuen Lieblings-Newsletter?
Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken.
[1] Hier können Sie den Scrum Guide auf Englisch herunterladen. Und hier auf Deutsch.
[2] Hier finden Sie eine Beschreibung der verschiedenen Ausgaben inklusive der Änderungen.
Hier finden Sie bei Bedarf auch eine vereinfachte, deutschsprachige, nach H. Phettberg entgenderte Scrum Guide Version.
Als Empfehlung wird die Scrum Teamgröße mit 10 angegeben. Da sowohl Product Owner und Scrum Master dem Scrum Team zugerechnet werden, “verbleiben” noch 8 Entwickler im Team. Im alten Scrum Guide waren es noch 9.
Hier hören Sie einen interessanten Podcast über das Scrum Guide Update 2020 u.a. mit Vertretern von Scrum Alliance und Scrum.Org.
Hier finden Sie eine optisch sehr gelungene Visualisierung des Frameworks.
Und hier finden Sie ergänzende Informationen aus dem t2informatik Blog: