Der Scrum Guide enthält viele Regeln und Empfehlungen, aber kannst du sie unterscheiden?
User Storys zu schätzen ist nicht verpflichtend. In Scrum gibt es keine verpflichtenden Best Practices! Scrum ist ein Rahmenwerk und keine Methode. Der Scrum Guide beschreibt deshalb nur das „Was“ und nicht das „Wie“. Deshalb sind Praktiken immer nur Empfehlungen.
Scrum Master, die Best Practices als verpflichtende Scrum Regeln auffassen, behindern die Agilität im Unternehmen. Agil zu sein bedeutet, sich an den Kontext anzupassen. Allerdings ist dieser für jedes Team, jedes Produkt und jedes Unternehmen verschieden.
Damit du nicht auch zu diesen Scrum Mastern gehörst, findest du hier eine Übersicht der wichtigsten Regeln und Empfehlungen aus dem Scrum Guide.
Starten wir mit den Regeln in Scrum:
Scrum Events sind zeitlich beschränkt
Jedes Event in Scrum hat eine Timebox. Für Sprints gilt etwa:
„Es sind Events mit fester Länge von einem Monat oder weniger, um Konsistenz zu schaffen.“ – Scrum Guide
Da der Sprint einen Container für alle anderen Events darstellt, richtet sich die Länge von Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospektive proportional nach der Länge des Sprints. Soll heißen: Bei kürzeren Sprints sind die Events in der Regel kürzer. Scrum Teams dürfen die im Scrum Guide beschriebenen Timeboxen also nicht überschreiten.
Timeboxen helfen Scrum Teams, sich auf das Wesentliche im Sprint zu fokussieren.
Erst wenn Nutzer die Arbeit des Teams auch verwenden können, ist sie fertig
Arbeit ist fertig, wenn sie die Definition of Done erfüllt.
Hinter dieser einfachen Aussage verbergen sich drei Regeln: Die Arbeit an einem Product-Backlog-Eintrag ist erst dann abgeschlossen, wenn
sie gründlich geprüft ist,
in das Produkt integriert ist
und von Nutzern verwendet werden kann.
„Um einen Mehrwert zu erzielen, muss das Inkrement verwendbar sein.“ – Scrum Guide
Nur ein „Done“-Inkrement stellt die nötige Transparenz her, damit die Vorhersagbarkeit optimiert werden kann und das Risiko kontrollierbar bleibt.
Somit ist die Definition of Done verpflichtend für jedes Scrum Team.
Erst das Sprint-Ziel macht aus einer Gruppe von Entwicklern ein Team
Spätestens seit dem Scrum-Guide-Update 2020 sind Sprint-Ziele verpflichtend.
Der Scrum Guide hält fest:
„Das Sprint‐Ziel wird während des Sprint‐Planning‐Events erstellt und dann zum Sprint-Backlog hinzugefügt.“ – Scrum Guide
Das Sprint-Ziel ist somit obligatorisch in Scrum. Nicht zuletzt kann es ohne ein Ziel kein Scrum Team geben, sondern lediglich eine Gruppe von Entwicklern.
Scrum Teams sind interdisziplinär und managen sich selbst
Die Fähigkeit eines Unternehmens, schnell Entscheidungen zu treffen, bestimmt die Agilität.
Das Gegenteil von Agilität ist Starrheit oder Langsamkeit. Diese entsteht durch Bürokratie, Standardisierung von Prozessen, Entscheidungsgremien oder Zentralisierung.
Um die Grundlage für schnelle und fundierte Entscheidungen zu schaffen, schreibt der Scrum Guide die Teamstruktur vor:
„Scrum Teams sind interdisziplinär, d. h. die Mitglieder verfügen über alle Fähigkeiten, die erforderlich sind, um in jedem Sprint Wert zu schaffen. Sie managen sich außerdem selbst, d. h. sie entscheiden intern, wer was wann und wie macht.“ – Scrum Guide
Das hast du richtig gelesen: Ein Team, welches für den Test und das Q&A eines Produkts zuständig ist, ist kein Scrum Team.
Nun zu den Empfehlungen im Scrum Guide:
Scrum Teams sollten 10 oder weniger Personen umfassen
In kleineren Teams ist die Kommunikation erheblich zeitsparender. Deshalb empfiehlt der Scrum Guide:
„Das Scrum Team ist klein genug, um flink zu bleiben, und groß genug, um innerhalb eines Sprints bedeutsame Arbeit fertigzustellen, üblicherweise 10 oder weniger Personen.“ – Scrum Guide
Scrum Teams mit mehr als zehn Personen sollten sich in mehrere Scrum Teams reorganisieren. Hierfür schreibt der Scrum Guide aber keine feste Regel vor. Er empfiehlt, dies spätestens ab zehn Teammitgliedern zu tun.
Zerkleinern der Arbeit macht sie verständlicher
Viele Menschen glauben, dass der Task-break-down von User Storys im Sprint Planning verpflichtend ist. Und dass die Tasks nur einen Tag Arbeit umfassen dürfen.
Dem ist nicht so:
„Für jeden ausgewählten Product‐Backlog‐Eintrag planen die Developer:innen die notwendige Arbeit, um ein Inkrement zu erstellen, das der Definition of Done entspricht. Dies geschieht oft durch Zerlegung von Product‐Backlog‐Einträgen in kleinere Arbeitseinheiten von einem Tag oder weniger.“ – Scrum Guide
Die Arbeit so zu verkleinern, dass sie in einem Tag umsetzbar ist, ist eine bewährte Praxis unter Entwicklern. Erst durch diese Granularität sind sie zuversichtlich, die Arbeit wirklich verstanden zu haben. Deshalb spricht der Scrum Guide diese Empfehlung aus.
Burn-down-Charts helfen, den Fortschritt im Blick zu behalten
In komplexen Umgebungen ist unbekannt, was passieren wird.
Daran ändern auch Burn‐down‐Charts nichts.
Scrum Teams ist freigestellt, wie sie den Fortschritt bei ihrer Arbeit im Auge behalten:
„Es gibt verschiedene Vorgehensweisen, um den Fortschritt vorherzusagen, wie Burn‐down‐Charts, Burn‐up‐Charts oder Cumulative‐Flow‐Diagramme.“ – Scrum Guide
Dies ersetzt aber nicht die Bedeutung eines empirischen Vorgehens: Nur was bereits geschehen ist, kann für eine Entscheidungsfindung genutzt werden.
Schätzen ist keine vorgeschriebene Tätigkeit eines Scrum Teams
Entwickler müssen Product-Backlog-Einträge nicht schätzen.
Die Einträge im Product-Backlog müssen lediglich klein genug sein, damit das Scrum Team sie innerhalb eines Sprints abschließen kann. Diese Einträge werden dann als „bereit“ bezeichnet. Die Aktivitäten, die dazu führen, fallen unter das Refinement.
„Dies ist eine kontinuierliche Aktivität, wodurch weitere Details wie Beschreibung, Reihenfolge und Größe ergänzt werden. Die Attribute variieren oft je nach Arbeitsumfeld.“ – Scrum Guide
Soll heißen: Die Angabe der Größe eines Product-Backlog-Eintrags ist nicht erforderlich.
Wo stimmst du mir zu und wo nicht? Schreibe es in die Kommentare.