Scrum Guide und Skalierung: Teil 3 - Scrum Ereignisse

Geschrieben von Peter Beck am 02.03.2015
Scrum Events

Scrum-Ereignisse umfassen den Sprint, sowie die Scrum-Meetings. Wenn wir die Definitionen im Scrum Guide als Regeln für die skalierte Implementierung auffassen, müssen alle Scrum-Ereignisse sowohl für die einzelnen Scrum Teams als auch für die Gesamtheit - die Produktorganisation - gelten.

In Scrum werden vorgeschriebene Ereignisse verwendet, um eine Regelmäßigkeit herzustellen und die Notwendigkeit anderer, nicht in Scrum definierter, Besprechungen zu minimieren. Alle Ereignisse haben eine zeitliche Beschränkung (Time Box), so dass jedes Ereignis eine maximale Dauer hat. Bei Sprintbeginn steht dessen Dauer fest und darf weder gekürzt noch verlängert werden. Die anderen Ereignisse dürfen beendet werden, sobald sie ihren Zweck erfüllt haben.


Die Einhaltung der Scrum-Ereignisse schliesst nicht aus, dass andere Besprechungen notwendig werden können. Im Zweifelsfall sollte bei einer skalierten Scrum-Implementierung eine Vorgehensweise gewählt werden, bei der man mit den definierten Scrum-Meetings auskommt.

3.1 Die Sprints

Was für ein einzelnes Scrum Team gilt, gilt auch für eine skalierte Produktorganisation nach Scrum. Das ist insbesondere wichtig, wenn es um die Planung der Sprints geht.

Das Herz von Scrum ist der Sprint, eine Time Box von maximal einem Monat, innerhalb dessen ein fertiges ("Done"), nutzbares und potenziell auslieferbares Produkt-Inkrement hergestellt wird. Alle Sprints innerhalb eines Entwicklungsvorhabens sollten die gleiche Dauer haben. Der neue Sprint startet sofort nach dem Abschluss des vorigen Sprints.

Wenn also mehrere Entwicklungsteams gleichzeitig an einem Produkt arbeiten, so sind ihre Sprints auch von gleicher Dauer, um einen gemeinsamen Überprüfungs- und Anpassungsrhythmus zu erzielen. Dem widerspricht auch nicht die häufig verwendete Praxis, in bestimmten Teams mehrere Sprints zu absolvieren, während in anderen gleichzeitig nur jeweils ein Sprint abgeschlossen wird, sofern die Sprint-Zyklen miteinander harmonieren.

Ob man jetzt nun sagt, dass mehrere gleichzeitig nach Scrum entwickelnde Teams mehrere Sprints haben, oder einen einzigen, ist einfach nur Wortklauberei. Am Ende eines jeden umfassenden Sprints produzieren alle Teams gemeinsam ein Produkt-Inkrement gemäß der Definition von “Done” und den Maßgaben der Organisation.

Abbildung 1: Umfassender Sprint für alle Umfassender Sprint für alle

Abbildung 2: Synchrone schnellere Sprint-Taktung Synchrone schnellere Sprint-Taktung

3.2 Die Sprint Plannings

Im Sprint Planning wird die Arbeit für den kommenden Sprint geplant. Dieser Plan entsteht durch die gemeinschaftliche Arbeit des gesamten Scrum Teams.

Die gemeinschaftliche Arbeit des gesamten Scrum Teams richtet sich auf zwei Hauptziele des Sprint Plannings.

  • Was ist in dem Produkt-Inkrement des kommenden Sprints enthalten? 
  • Wie wird die für die Lieferung des Produkt-Inkrements erforderliche Arbeit erreicht? 

Der erste Punkt erfolgt vor allem durch die Interaktion mit dem Product Owner. Der zweite Punkt kann von einem Entwicklungsteam in Eigenregie erfüllt werden. Dafür gibt es bei einer skalierten Scrum-Implementierung verschiedene Möglichkeiten.

3.2.1 Punkt 1: Was

Das Entwicklungsteam erstellt eine Prognose über die Funktionalität, die im Sprint entwickelt werden soll. Der Product Owner beschreibt das Ziel, das mit dem Sprint erreicht werden soll und die Product Backlog-Einträge, welche - wenn sie in dem Sprint abgeschlossen werden - das Ziel erfüllen. Das ganze Scrum Team erarbeitet gemeinsam ein Verständnis über die Arbeitsinhalte des Sprints. ?

Wenn mehrere Scrum Teams gemeinsam an dem kommenden Sprint planen, muss genau so die gegenseitige Transparenz und eigenständige “Pull”-basierte Vorhersage eingehalten werden, wie bei einem einzigen Scrum Team. Die folgenden Vorgehensweisen zu diesem Punkt illustrieren mögliche Implementierungen dieser Regel:

  • Einige Scrum Teams veranstalten gemeinsam einen ersten Teil des Sprint Plannings, in dem sie untereinander und mit dem Product Owner abklären, welche Product Backlog-Einträge von welchem Team im kommenden Sprint angenommen werden. 
  • Einige Product Owner erarbeiten eine Vorauswahl der passenden Product Backlog Einträge. Dann entfällt die Zuteilung und es geht nur noch um die Menge des anzunehmenden Product Backlogs.

Am Ende des Sprint Plannings haben auf jeden Fall alle ein Verständnis über die aktuellen Vorhersagen, Sprint-Ziele (das Sprint-Ziel) sowie ggf. den gegenseitigen Abstimmungsbedarf.

3.2.2 Punkt 2: Wie

Nach der Vereinbarung des Sprint-Ziels und der Auswahl der Product Backlog-Einträge für den Sprint entscheidet das Entwicklungsteam, wie es das Produkt-Inkrement erstellen möchte, damit die Funktionalität in einen "Done"-Zustand gebracht werden kann. Als Sprint Backlog bezeichnet man die Auswahl der Product Backlog-Einträge für den jeweiligen Sprint plus den Umsetzungsplan des Entwicklungsteams.

Die Erarbeitung der Sprint Backlogs erfolgt hiernach je Entwicklungsteam. Darüber hinaus muss allerdings gewährleistet werden, dass sich mehrere Entwicklungsteams bei der Umsetzungsplanung gegenseitig abstimmen und die gemeinsame Lieferung des Produkt-Inkrementes planen können.

3.2.3 Sprint-Ziele / Sprint-Ziel

Das Sprint-Ziel bietet dem Entwicklungsteam eine gewisse Flexibilität in Bezug auf die im Sprint zu implementierende Funktionalität. Die ausgewählten Product Backlog-Einträge bilden eine zusammenhängende Funktionalität, die als Sprint-Ziel angesehen werden kann. Das Sprint-Ziel kann aber auch jedes andere verbindende Element sein, welches das Entwicklungsteam - statt in verschiedene Richtungen zu laufen - zur Zusammenarbeit motiviert.

Wenn es ein Sprint-Ziel für den Sprint eines einzelnen Scrum Teams gibt, so gibt es auch ein Sprint-Ziel für den Sprint im skalierten Scrum. Gemäß der Beschreibung liesse sich das Sprint-Ziel für mehrere Teams als Summe oder Zusammenfassung der Sprint-Ziele der einzelnen Teams ableiten. Oder anders herum: die Sprint-Ziele der einzelnen Scrum Teams sind Teilziele des übergreifenden Sprint-Ziels.

Somit stellt das übergreifende Ziel eine Art Mini-Vision für den jeweiligen Sprint dar, an der sich alle Scrum Teams gleichermassen orientieren sollten. Daher gilt - wie beim einzelnen Team auch - dass das Sprint-Ziel über der eigenen Product Backlog-Auswahl steht. Ein Scrum Team, dass seine Vorhersage zu 100% erfüllt, aber eine wichtige Gelegenheit verpasst hat, den anderen Teams bei der Erreichung des übergreifenden Ziels zu helfen, hat den Geist von Scrum vielleicht noch nicht verstanden.

3.3 Die Daily Scrums

Das Verständnis des Daily Scrums im skalierten Umfeld wird wahrscheinlich geschärft, wenn wir uns nicht auf die Mechanik, sondern den Sinn des Daily Scrums konzentrieren:

Das Entwicklungsteam überprüft im Daily Scrum seinen Fortschritt in Richtung des Sprint-Ziels und den Trend bei der Abarbeitung der Sprint Backlog-Einträge.

Natürlich erfolgt diese selbstorganisierte Überprüfung und Anpassung in jedem Entwicklungsteam separat. Doch genau so funktioniert auch die teamübergreifende Synchronisation. Selbstorganisiert, im Hinblick auf das Sprint-Ziel, mit voller Transparenz über Entwicklungsstand, Fortschritt und gemeinsame Hindernisse.

Mögliche Implementierungen dieser Regel im skalierten Scrum sind:

  • Einrichtung eines separaten Scrum of Scrum-Meetings, in dem sich Vertreter der einzelnen Entwicklungsteams regelmässig untereinander abstimmen. 
  • Gegenseitige Besuche der Daily Scrums - die Meetings stehen Besuchern ja offen - zur Informationsbeschaffung und dem Austausch von Hindernissen, Hilfegesuchen oder -Angeboten.

3.4 Die Sprint Reviews

Das Sprint Review ist einer der drei wesentlichen Inspektions- und Adaptionspunkte in Scrum. Daher ergibt sich aus der Beschäftigung mit dem Scrum Guide, dass neben der Überprüfung des Produkt-Inkrements auch die Möglichkeit des Feedbacks und der Ideensammlung gegeben sein muss.

Das Ergebnis des Sprint Reviews ist ein überarbeitetes Product Backlog, das die möglichen Product Backlog-Einträge für den kommenden Sprint enthält.

Ein Sprint Review muss der gesamten Produktorganisation ermöglichen, diese Transparenz über den aktuellen Stand zu erlangen sowie Verbesserungen, Änderungen und Möglichkeiten zu identifizieren und anzusprechen. Das erfordert typischerweise die Beteiligung sämtlicher Scrum Team Mitglieder aller Scrum Teams.

Aus organisatorischen Gründen kann es bei größeren skalierten Scrums erforderlich sein, diese Überprüfung und Anpassung mehrstufig durchzuführen. Allerdings besteht bei zu großen Scrums die Gefahr, wichtige Informationen beim Übergang / der Skalierung zu verlieren. Um das zu vermeiden, empfiehlt sich die Einbeziehung eines möglichst großen Teilnehmerkreises (alle) in möglichst wenige Sprint Review-Teilmeetings (eines).

3.5 Die Sprint Retrospectives

Die Sprint Retrospektive wird durchgeführt, um 

  • zu überprüfen wie der vergangene Sprint in Bezug auf die beteiligten Menschen, Beziehungen, Prozesse und Werkzeuge verlief; 
  • die wichtigsten gut gelaufenen Elemente und mögliche Verbesserungen zu identifizieren und in eine Reihenfolge zu bringen; und 
  • einen Plan für die Umsetzung von Verbesserungen der Arbeitsweise des Scrum Teams zu erstellen.

Bezogen auf eine skalierte Scrum-Implementierung bedeutet das, diese Überprüfung auf die Produktorganisation als Ganzes auszuweiten. Im skalierten Umfeld will man natürlich auch eine Verbesserung der Arbeit innerhalb der einzelnen Scrum Teams. Darüber hinaus müssen allerdings Möglichkeiten zum Feedback und Lernzyklen eingerichtet werden, die eine kontinuierliche Verbesserung der eingesetzten skalierten Praktiken und Vorgehensweisen erlauben.

Es gibt viele Möglichkeiten, die Retrospektiven zu skalieren. So kann man Retrospektiven mit mehreren Teams gleichzeitig durchführen - oder die Ergebnisse einzelner Retrospektiven auf höherer Ebene sammeln und als Input für eine “Scrum of Scrums”-Retrospektive verwenden. Je ehrlicher und lernbereiter eine Scrum-Produktorganisation dabei ist, desto steiler fällt die entsprechende Lern- und Fortschrittskurve aus.

... Im nächsten Artikel geht es um Scrum Artefakte ...

Andreas Schliep

Andreas „Andy“ Schliep

Andy ist einer der ersten deutschsprachigen Scrum-Trainer und ein Gründungsmitglied von DasScrumTeam. Nach seinem Studium an der Hochschule Bremerhaven begann Andreas seine Karriere zunächst als Softwareentwickler, später dann als Projektleiter, Teamleiter und schließlich als Bereichsleiter. Zu Scrum fand Andreas zwischen 2003 und 2004 durch seine damaligen Kollegen bei WEB.DE. Nach der Implementierung von Scrum bei WEB.DE wechselte Andreas im Jahr 2006 zu SPRiNT iT und entschied sich 2008, als Coach und Trainer selbstständig zu machen. Heute fokussiert er sich neben der Einführung von Scrum vor allem auf agile Führungskompetenzen und die nachhaltige Transformation von Organisationen. Als Co-Autor hat Andy an der Erstellung der Lernziele der Scrum Alliance für Scrum Master, Product Owner und Entwickler mitgewirkt.

Peter Beck

Über den Autor

Peter Beck

Peter hat es sich zur Aufgabe gemacht Unternehmen zu schaffen, die Wert für ihre Kunden und ihre Mitarbeiter liefern. Das war auch seine Motivation für die Gründung von DasScrumTeam. Peter ist leidenschaftlicher Scrum Trainer (Certified Scrum Trainer, CST) und Berater mit einem soliden Hintergrund im Engineering. Seit 2007 trainiert und berät er eine große Bandbreite von Entwicklungsteams, Fachabteilungen, Projektleitern und Führungskräften in der Anwendung von Scrum, agilen Planungsmethoden und Softwareengineerings-Praktiken. Peter ist Diplom-Ingenieur für Elektro und Informationstechnik (TU).

  • Erfahrung mit Scrum seit 2004 als Teammitglied, ScrumMaster, Product Owner, Coach und Trainer.
  • Führen von international verteilten Scrum Teams als ScrumMaster
  • Mitgründer und Product Owner der DasScrumTeam AG
  • Besondere Interessen: Agile Unternehmen und Scrum beyond Software

Mehr Posts zum Thema

Immer informiert mit dem DasScrumTeam Newsletter

Das Beste in Sachen Scrum. Einmal im Monat. Jeden Monat.