Die fünf formellen Scrum Events im Projektmanagement

Neben den Rollen sind die Events (Ereignisse) ein zentrales strukturelles Element von Scrum. Es gibt fünf solche formellen Scrum Events:

• Sprint: In Scrum werden die Iterationen «Sprints» genannt. Es handelt sich dabei um das Gefäß, in dem die gesamte Entwicklung stattfindet und in dem die nachfolgenden Events enthalten sind.
• Sprint-Planungs-Meeting (Spring Planning): Das erste Event im Sprint, das unmittelbar zu Beginn der Sprint-Dauer stattfindet. Das Scrum-Team plant dabei, welche Anforderungen im Rahmen der Iteration umgesetzt werden und wie dies geschehen soll.
• Tägliches Scrum-Meeting (Daily Scrum): Im Verlauf des Sprints trifft sich das Entwicklerteam täglich am selben Ort und zur selben Zeit zu diesem Koordinationsmeeting. Das Meeting dauert immer 15 Minuten, unabhängig von der Sprint-Dauer und der Anzahl der Entwickler.
• Sprint-Review-Meeting: Das Entwicklerteam präsentiert das Resultat des Sprints und erhält dabei Feedback vom Kunden. Nur Anforderungen, welche vollständig umgesetzt sind, werden dem Kunden präsentiert.
• Sprint-Retrospektive: Als letztes Event im Sprint, unmittelbar vor dessen Ende, kommt das ganze Scrum-Team zusammen, um die letzte Iteration zu besprechen und Wege zu finden, die Zusammenarbeit für die Zukunft zu verbessern. Unmittelbar nach diesem Event beginnt der nächste Sprint.

Die Tatsache, dass nur die genannten Scrum Events, welche teils auch Meetings sind, festgesetzt sind, bedeutet nicht, dass es nicht gestattet wäre, auch andere Meetings/Events abzuhalten, wenn dies notwendig erscheint. Tatsächlich ist zumindest das Backlog Refinement eine Tätigkeit, welche ebenfalls in einem Meeting stattfindet. Was andere Meetings von den genannten unterscheidet ist aber die Festlegung von festen Maximaldauern für die genannten.

Der gesamte Ablauf in Scrum ist auf Einfachheit und Übersichtlichkeit ausgerichtet. Klare Regelungen zu Vorgehen, Inhalten und Umfang von Events sind darauf ausgerichtet, Planung so schlank und einfach wie möglich zu halten, um sich auf den eigentlichen Zweck, die Entwicklung von Produkten, konzentrieren zu können.

Timeboxing

Timeboxing ist ein Konzept vieler agiler Frameworks und Methoden. Dabei wird für bestimmte Events eine maximale Zeitdauer festgesetzt. Ein zentraler Grund dafür ist, eine Fokussierung auf das Wesentliche zu unterstützen. Die Dauer der Timeboxen der Events innerhalb eines Sprints hängt von jener des Sprints ab. Lediglich die Timebox für das Daily Scrum bleibt unabhängig von allen übrigen Rahmenbedingungen konstant.

Der Sprint

Sprint ist das Wort, mit der eine Iteration in Scrum bezeichnet wird. Das Ziel jedes Sprints ist es, ein potentiell releasebares Inkrement zu erzeugen. Inkrement steht dafür, dass die Entwicklungsresultate jedes Sprints zu jenen der vorangegangenen Sprints addiert und mit diesen integriert werden. «Potentiell releasebares» Inkrement meint, dass das Inkrement nicht zwingend released werden muss, dass es aber bereit zum Release wäre, sofern sich der Product Owner dazu entschliesst, dies zu tun.

Ein Sprint dauert maximal vier Wochen, abhängig von den Rahmenbedingungen (Komplexität, Verfügbarkeit des Kunden, Risiko, Erfahrung des Teams etc.) ist aber auch eine Sprintdauer von 1, 2 oder 3 Wochen denkbar. Theoretisch wäre auch eine andere Dauer denkbar; da dies aber bedeuten würde, dass die Anzahl der Arbeitstage (und entsprechend die Kapazität des Teams) abhängig von den enthaltenen Wochentagen laufend wechseln würde, wird normalerweise mit ganzen Wochen gearbeitet. Entsprechend ist auch die in manchen Büchern genannte maximale Sprint-Dauer von einem Monat nicht als wahlweise 30 oder 31 Tage zu sehen, sondern als gleichbedeutend mit 4 Arbeitswochen.

Sprints bilden das Gefäß, innerhalb dessen sowohl die Umsetzung wie auch die anderen Events stattfinden. Sie folgen unmittelbar aufeinander, das heisst, der Endpunkt eines Sprints ist gleichzeitig der Beginn des nächsten. Es gibt dazwischen keine Pause oder irgendwelche Zwischenabschnitte, in denen Vorbereitungen für weitere Sprints oder andere Entwicklungen durchgeführt würden.

Sprint-Planungsmeeting

Das Sprint-Planungsmeeting hat das Ziel, die Tätigkeiten des laufenden Sprints zu planen. Es findet als erstes Event des Sprints statt. Die Timebox bei einem vierwöchigen Sprint beträgt maximal 8 Stunden – bei kürzeren Sprints proportional weniger. Anwesend ist das gesamte Scrum-Team (Product Owner, Scrum Master und das ganze Entwicklungsteam).

Damit das Meeting optimal durchgeführt werden kann, sollte ein priorisierter und geschätzter Product Backlog vorliegen, dessen am höchsten priorisierten Feature (welche zuoberst angeordnet sind) klein genug sind, dass sie im Laufe eines Sprints gut umgesetzt werden können. Sie sollten dem Entwicklerteam auch bereits bekannt und von diesem geschätzt worden sein. Die Tätigkeit des Schätzens und des Klärens des genauen Umfangs von Features findet im Rahmen des Backlog Refinements (auch Backlog Grooming genannt) statt, welches fortlaufend stattfindet. (➔ weiterführende Informationen sind im entsprechenden Kapitel zu finden). Sollten nicht ausreichend umsetzungsbereite Anforderungen vorhanden sein, so ist das niemals ein Grund, nicht mit dem Sprint zu starten. In dem Fall müssen lediglich gewisse Arbeiten in Hinblick auf die Aufgabenklärung priorisiert angegangen werden, damit zumindest für die nächsten Tage ausreichend Arbeitsvorrat für das Entwicklerteam besteht.

Das Sprint-Planungsmeeting umfasst zwei Teile. Der Erste fokussiert das «Was» und klärt, welche Anforderungen im laufenden Sprint umgesetzt werden sollen. Dabei präsentiert der Product Owner die am höchsten priorisierten Product Backlog Items, welche im Rahmen seiner Planung für den kommenden Sprint passen würden. Die dabei dargestellten Items entsprechen im Wesentlichen jenen, welche der aktuellen Releaseplanung entsprechen. Nun entscheidet das Entwicklerteam basierend auf seiner Entwicklungskapazität, ob es die entsprechenden Anforderungen vollumfänglich oder nur teilweise umsetzen kann.

In diesem ersten Teil des Sprint-Planungsmeetings kollidieren öfters zwei unterschiedliche Interessenslagen. Der Product Owner möchte verständlicherweise so viele Features wie möglich realisieren lassen, weil er damit den Wert des Produktes vergrößern kann, das Entwicklungsteam hingegen ist daran interessiert, ausreichend Zeit zur Verfügung zu haben, um Produkte in der vereinbarten Qualität zu liefern. Schließlich und endlich werden sie ein Committment abgeben, dass die gewählten Features während des laufenden Sprints umsetzen werden. Versuche des Product Owners, hier Druck aufzubauen, damit das Team zusagt, mehr Anforderungen umzusetzen als es möchte, sind im Allgemeinen kontraproduktiv, da damit oft nur erreicht wird, dass bei Sprint-Ende nicht alle vereinbarten Anforderungen umgesetzt wurden und halbfertige Features zurück in den Product Backlog fallen. Sinnvollerweise sollten Sprints vom Team auch immer so geplant werden, dass die vereinbarten Ziele auch dann noch realistisch erreichbar sind, wenn beispielsweise ein Teammitglied zwei Tage krank wird oder ähnliche Ereignisse eintreten.

Im zweiten Teil des Sprint-Planungsmeetings steht das «Wie» im Vordergrund. Das Entwicklerteam bespricht die Anforderungen und definiert gemeinsam, wie diese im Verlauf des Sprints umgesetzt werden sollen. Dazu werden die einzelnen Anforderungen in Arbeitspakete (auch Tasks oder Aufgaben genannt) unterteilt, welche idealerweise im Rahmen eines Tages umgesetzt werden können. So kann ein Software-Entwicklungsfeature beispielsweise in die Aufgaben «Design», «Entwicklung», «Tests» und «Dokumentation» unterteilt werden. Die entsprechenden Aufgaben werden später nicht zwingend alle von derselben Person umgesetzt und je nach Anforderung und Teamzusammensetzung können auch mehr oder andere Aufgabenblöcke gebildet werden. Die Planung des Sprints erfolgt durch das Entwicklerteam und wird im Sprint Backlog festgehalten. Analog zum Produkt Backlog, für den der Product Owner verantwortlich ist, liegt die Verantwortung für den Sprint Backlog beim Entwicklerteam. Es entscheidet final darüber, wie die darin befindlichen Anforderungen im Rahmen der Vorgaben (Anforderungen, Akzeptanzkriterien und Definition of Done) umgesetzt werden.

Daily Scrum

Das Daily Scrum stellt eine unmittelbare Folge der selbstorganisierten Vorgehensweise des Entwicklerteams dar. Wo keine externe Rolle vorhanden ist, welche Arbeitspakete zuweist, muss dies in Absprache der Beteiligten geschehen. Dazu versammelt sich das gesamte Entwicklerteam täglich zur selben Zeit und am selben Ort zum Daily Scrum (auch Daily Standup genannt). Die damit implementierte Kontinuität soll dem ganzen Entwicklungsvorgang einen festen Rahmen bieten. Daneben ist es auch nicht sinnvoll, wenn Ort und Zeit täglich neu verhandelt werden müssen. Gleichbleibender Ort, Zeit und Dauer macht das Event für das ganze Team optimal planbar. Weitere Personen dürfen beim Meeting zwar dabei sein, haben aber keine aktive Rolle.

Die Timebox des Daily Scrum liegt unabhängig von der Anzahl der Teammitglieder oder der Sprintdauer stets bei 15 Minuten. Das Entwicklungsteam versammelt sich dazu, üblicherweise stehend, beim Taskboard und jedes Teammitglied beantwortet die folgenden drei Fragen:

1. Woran habe ich seit dem letzten Meeting gearbeitet?
2. Woran werde ich bis zum nächsten Meeting arbeiten?
3. Existieren irgendwelche Hindernisse, welche mich daran hindern, optimale Arbeit zu leisten?

Die ersten beiden Antworten spiegeln sich oft durch entsprechende Anpassungen auf dem Taskboard wieder, auf dem Aufgaben von «To Do» auf «Doing» resp. von «Doing» auf «Done» geschoben werden.

Der Scrum Master muss beim Daily Scrum nicht anwesend sein. Er sollte aber sicherstellen, dass dieses regelmäßig täglich innerhalb der Timebox stattfindet.

Sollte sich beim Daily Scrum Diskussionsbedarf zwischen einigen der Entwickler zeigen, so werden entsprechende Punkte zwischen den direkt Beteiligten nach dem Daily Scrum besprochen. So kann sichergestellt werden, dass nicht das ganze Team durch Einzelthemen absorbiert wird und dadurch entsprechend Zeit verliert.

Werden im Verlauf des Daily Scrum Hindernisse dargestellt oder wird festgestellt, dass beispielsweise benötigte Ressourcen oder Fähigkeiten nicht vorliegen, welche benötigt werden, um das Produkt wie vereinbart zu liefern, so ist es primär die Aufgabe des Scrum Masters, dafür zu sorgen, dass diese Hindernisse gelöst werden.

Sprint-Review

Das Sprint-Review-Meeting findet zum Ende des Sprints als zweitletztes Meeting statt. Seine Timebox liegt bei 4 Stunden bei einem vierwöchigen Sprint. Teilnehmer sind neben dem gesamten Scrum Team idealerweise Vertreter des Kunden, welche in diesem Meeting Feedback zu den gezeigten Entwicklungsresultaten geben. Es handelt sich dabei um ein informelles Meeting, dessen Ziel darin liegt, dass das entwickelte Produkt eine immer größere Wertschöpfung für den Kunden erzielt. Dafür ist es wichtig, dass der Kunde sein Feedback frei geben kann. Die Vorstellung, dass die präsentierte Lösung im Review praktisch abgenommen würde, würde diese Möglichkeit zur freien Äußerung reduzieren und der Kundenvertreter würde womöglich andere Rückmeldungen geben, deren Motivation womöglich mehr damit zu tun hätte, sich selbst keine Blöße zu geben und sich intern nicht angreifbar zu machen, weil dem Gegenüber womöglich (falsche) Zugeständnisse gemacht wurden. Vielmehr geht es hier um einen Austausch von Fachleuten für den Kundennutzen und Einsatz des Produktes. Das dabei geäußerte Feedback soll dazu dienen, dass die Anforderungen des Kunden noch besser verstanden werden können und eine noch größere Konzentration auf den Kundennutzen möglich wird.

Ein Produkt-Review-Meeting ist eine wundervolle Möglichkeit, auch interne Stakeholder aus der Organisation einzuladen. Dabei können sich auch andere Teile der Organisation ein Bild von Scrum machen. Das kann helfen, damit das «Scrum-Bewusstsein» sich auch in anderen Bereichen der Organisation einen Weg schafft. Daneben werden zum Review bei Bedarf auch externe Experten eingeladen, welche hier bei Bedarf ebenfalls ein Feedback geben können.

Im Sprint-Review werden ausschliesslich Produkte gezeigt, welche vollständig fertiggestellt wurden. Dies schließt auch alle in der «Definition of Done» festgelegten Tests, Dokumentationen etc. mit ein. Es geht in einem Sprint immer darum, ein potentiell auslieferbares Produkt zu erstellen. Entsprechend gilt die 100%-Regel. Das heißt, dass Ergebnisse, welche auch nur in geringen Teilen nicht den festgehaltenen Anforderungen entsprechen (beispielsweise, weil die Dokumentation noch nicht fertiggestellt ist) zurück in den Produkt Backlog fallen. Es gibt keine Ausnahme nach dem Motto: «Das liefern wir in den nächsten Tagen nach». Hier sollte der Product Owner absolut hart sein und nur das präsentieren lassen, was vollständig umgesetzt ist. Ansonsten besteht die große Gefahr, dass sich damit ein Verhaltensmuster etabliert, was dazu führt, dass die umgesetzte Lösung immer weiter verwässert und mit der Zeit eine lange Liste von noch offenen Punkten mitgeschleppt wird. Auch die Bestimmung der Performance des Teams und die damit verbundene Schätzung der in einem Sprint umsetzbaren Anforderungen leidet unter solchen «Ausnahmeregelungen» erheblich.

Ein typischer Ablauf für ein Sprint-Review ist, dass nach einer Begrüßung durch den Scrum Master oder Product Owner Letzterer ein Debriefing über den vergangenen Sprint abgibt. Dabei ist Transparenz ein hoher Wert. Auch wenn es nicht leichtfallen mag, auch angetroffene Schwierigkeiten zu kommunizieren, so dient es doch dem langfristigen Aufbau eines Vertrauensverhältnisses, wenn dieses Meeting nicht als «Marketing-Show» verstanden wird. Anschliessend präsentieren die Entwickler die von ihnen umgesetzten Produkte und beantworten Fragen dazu. Ein Feedback des Kunden wird vom Product Owner festgehalten und bei Bedarf nach dem Meeting mit dem Kunden gemeinsam detaillierter geklärt. Dieses Feedback kann Auswirkungen auf die weitere Planung haben und beispielsweise dazu führen, dass neue Produkt-Backlog-Einträge erstellt werden, bestehende angepasst oder gar gestrichen werden. Als Abschluss gibt der Product Owner einen Ausblick auf die weitere Releaseplanung, wobei es dabei wichtig ist, klarzustellen, dass diese vorläufig ist und basierend auf Feedbacks und gemachten Erfahrungen Änderungen unterworfen sein kann.

Sprint-Retrospektive

Die Sprint-Retrospektive ist ein internes Event, an dem nur die Mitglieder des Scrum-Teams teilnehmen. Es bildet die Grundlage einer kontinuierlichen Verbesserung der Teamzusammenarbeit und des Entwicklungsprozesses und dadurch der entwickelten Produkte. Das vom Scrum Master moderierte Event hat eine Timebox von maximal 3 Stunden pro Vierwochensprint.

Der Fokus dieses Meetings liegt nicht auf dem Produkt, sondern auf dem Prozess. Aus diesem Grund haben Teams oft die Tendenz, dieses Event geringer zu achten oder gar ausfallen zu lassen. Dabei hört man Aussagen wie «Wir haben doch schon so viel erreicht», «Wir haben schon Produktivitätssteigerungen von X erreicht, mehr ist da gar nicht möglich» oder «Wir fokussieren auf ein gutes Produkt und brauchen keinen Seelen-Striptease». Diese Aussagen gründen alle auf einem falschen Verständnis des Zieles des Events.

Ziel der Retrospektive ist es, dem Team zu ermöglichen, immer besser zusammenzuarbeiten und sich ankündigende Schwierigkeiten frühzeitig vorzunehmen und diese anzugehen. Dabei ist wichtig, dass es in diesem Event nicht um Schuldzuweisungen, sondern um die Fragestellung geht, wie künftig (noch) besser zusammengearbeitet werden kann. Konstruktive Kritik ist willkommen – destruktive nicht.

Der Scrum Master kann als Moderator viel dazu beitragen, dass dieses Event zum Erfolg wird. Er muss dabei aber sicherstellen, dass er seine Rolle als Moderator versteht und nicht als Kontrolleur, das dem Team seine Fehler vorhält und ihm sagt, wie es sich verändern soll. Inputs und Ansätze zur Verbesserung sollen entsprechend primär aus dem Team stammen. Dabei ist wichtig, dass für gefundene Optimierungspunkte auch klare Ziele gesetzt werden. Es ist dabei meist Erfolg versprechender, ein oder zwei Themen anzugehen und diese nachhaltig zu optimieren als an vielen Baustellen herumzuflicken.

Unmittelbar nach dem Ende des Sprint-Retrospektive-Meetings beginnt der nächste Sprint. Entsprechend wichtig ist es, dass das Team getroffene Vereinbarungen in Bezug auf die Verbesserung der Zusammenarbeit und des Prozesses gleich umsetzen kann.