
Beitrag teilen
3 Min. Lesezeit
02. Juli 2021 · Tim Hartnack
02. Juli 2021 · Tim Hartnack
N
eben der personellen Organisation der Scrum Teams, welche wir bereits in vergangenen Blogeinträgen beleuchtet habe, findet zudem eine zeitliche Organisation statt. Entscheidend sind dabei die sogenannten Scrum Events. Diese Events finden regelmäßig statt und sorgen dafür, dass alle Beteiligten stets über die notwendigen Informationen verfügen, die nötig sind, um den Scrum Prozess und damit die stetige Verbesserung unserer Arbeitsweise und folglich unseres Produktes zu gewährleisten.
In der Wikipedia liest sich die Definition für Event wie folgt: Den Begriff „Event“ kann man definieren als ein Zusammenkommen/Zusammensein zum gemeinsamen Erleben von Freude oder Zusammengehörigkeit.1

In diesen zwei Wochen führen die Teams alles Nötige durch, um das Produkt im Sinne unserer Kunden und der Architektur besser zu machen. Dabei gibt es Aufgaben welche direkte Arbeit an der Software erfordern. Das sind in erster Linie neue Features, aber auch Umbauten der Architektur und zum Beispiel der Buildpipeline. Zudem gibt es Aufgaben innerhalb eines Sprints, welche nur indirekt mit Änderungen an der Software zu tun haben. So müssen Änderungen dokumentiert, sowie zukünftige Änderungen besprochen und im Aufwand geschätzt werden.
Einen Behälter für alle nötigen Aufgaben zu finden, dient hauptsächlich der Reduktion der Komplexität sowie dazu eine Regelmäßigkeit (gleicher Ort, gleiche Zeit) für alle weiteren Events zu bieten. Die weiteren Events2 innerhalb eines Sprints sind:
Die Regelmäßigkeit aller Events innerhalb eines Sprints bietet die Möglichkeit der Vorhersage. Alle zwei Wochen überprüfen wir den Fortschritt in Richtung unseres Produktzieles und reagieren entsprechend. Am Ende des Sprints stellt das Team interessierten Stakeholder*innen die Fortschritte vor, welche im aktuellen Sprint erreicht wurden. So kann das Team inkl. der Produktowner*innen bereits eine Rückmeldung darüber bekommen ob die durchgeführten Änderungen auf das Produktziel einzahlen, oder eben nicht.
Zudem bietet sich am Ende jedes Sprints die Möglichkeit der Rückbetrachtung der Arbeitsweise und einer Anpassung für die Zukunft. Denn „nur was bereits geschehen ist, kann für eine vorausschauende Entscheidungsfindung genutzt werden". 3
Es kann vorkommen, dass sich das Produktziel (und damit entsprechend das Sprintziel) innerhalb eines Sprints ändert. Auch die technischen Möglichkeiten können sich innerhalb des Sprints ändern, sodass die bisher erbrachten Änderungen „weggeworfen“ werden müssen. Die Produktowner*innen haben dann die Möglichkeit den Sprint vorzeitig zu beenden, um mit einer neuen, besseren Planung einen nächsten erfolgreichen Sprint zu starten. Sollte es innerhalb des Sprints nicht möglich sein eine Story abzuschließen, weil etwa andere Aufgaben eine höhere Priorität erlangen ist dies kein Grund den Sprint zu beenden.
In der Wikipedia liest sich die Definition für Event wie folgt: Den Begriff „Event“ kann man definieren als ein Zusammenkommen/Zusammensein zum gemeinsamen Erleben von Freude oder Zusammengehörigkeit.1
ZUSAMMENKOMMEN UND ZUSAMMENGEHÖRIGKEIT
In Scrum ist es neben dem Zusammenkommen und gemeinsamen Erleben von Zusammengehörigkeit auch das gemeinsame Schaffen von Wert. Während man von einem Event normalerweise einen eher kurzen Zeitraum von wenigen Stunden bis zu einem Tag erwartet, sind die Sprints bei Scrum normalerweise nicht kürzer als eine Woche und nicht länger als ein Monat. Die Sprints unserer Softwareteams bei FLS betragen 2 Wochen. Ein Sprint stellt damit folglich einen „Behälter“ für weitere Scrum Events dar.In diesen zwei Wochen führen die Teams alles Nötige durch, um das Produkt im Sinne unserer Kunden und der Architektur besser zu machen. Dabei gibt es Aufgaben welche direkte Arbeit an der Software erfordern. Das sind in erster Linie neue Features, aber auch Umbauten der Architektur und zum Beispiel der Buildpipeline. Zudem gibt es Aufgaben innerhalb eines Sprints, welche nur indirekt mit Änderungen an der Software zu tun haben. So müssen Änderungen dokumentiert, sowie zukünftige Änderungen besprochen und im Aufwand geschätzt werden.
Einen Behälter für alle nötigen Aufgaben zu finden, dient hauptsächlich der Reduktion der Komplexität sowie dazu eine Regelmäßigkeit (gleicher Ort, gleiche Zeit) für alle weiteren Events zu bieten. Die weiteren Events2 innerhalb eines Sprints sind:
- Planning
- Daily
- Review
- Retrospective
REFINEMENT UND RÜCKMELDUNG
In unseren Entwicklungsteams führen wir zusätzliche Refinementmeetings durch, in welchen die zukünftigen Änderungen genauer besprochen und geschätzt werden. Das Refinementmeeting ist jedoch bedarfsorientiert und folgt entsprechend keiner Regelmäßigkeit.Die Regelmäßigkeit aller Events innerhalb eines Sprints bietet die Möglichkeit der Vorhersage. Alle zwei Wochen überprüfen wir den Fortschritt in Richtung unseres Produktzieles und reagieren entsprechend. Am Ende des Sprints stellt das Team interessierten Stakeholder*innen die Fortschritte vor, welche im aktuellen Sprint erreicht wurden. So kann das Team inkl. der Produktowner*innen bereits eine Rückmeldung darüber bekommen ob die durchgeführten Änderungen auf das Produktziel einzahlen, oder eben nicht.
Zudem bietet sich am Ende jedes Sprints die Möglichkeit der Rückbetrachtung der Arbeitsweise und einer Anpassung für die Zukunft. Denn „nur was bereits geschehen ist, kann für eine vorausschauende Entscheidungsfindung genutzt werden". 3
REFLEKTION UND ANPASSUNG
Der Sprint endet nach den bei uns vereinbarten 2 Wochen. Sollten die Aufgaben, auf welche sich das Team zu Beginn im Sprintplanning verständigt hat, nicht erfüllt worden sein, gilt der Sprint als fehlgeschlagen. In der Rückbetrachtung (Retrospektive) wird dann versucht die zukünftige Arbeitsweise anzupassen, um weitere Sprints erfolgreicher durchführen zu können.Es kann vorkommen, dass sich das Produktziel (und damit entsprechend das Sprintziel) innerhalb eines Sprints ändert. Auch die technischen Möglichkeiten können sich innerhalb des Sprints ändern, sodass die bisher erbrachten Änderungen „weggeworfen“ werden müssen. Die Produktowner*innen haben dann die Möglichkeit den Sprint vorzeitig zu beenden, um mit einer neuen, besseren Planung einen nächsten erfolgreichen Sprint zu starten. Sollte es innerhalb des Sprints nicht möglich sein eine Story abzuschließen, weil etwa andere Aufgaben eine höhere Priorität erlangen ist dies kein Grund den Sprint zu beenden.
WEITERFÜHRENDE LINKS:
Lesen Sie hier Teil 1 der Serie "SCRUM@FLS".
Zur Vorstellung des Product Owners ›
Zur Vorstellung des Scrum Masters ›
Zur Vorstellung des SCRUM-ENTWICKLER-TEAM ›
Lesen Sie hier Teil 1 der Serie "SCRUM@FLS".
Zur Vorstellung des Product Owners ›
Zur Vorstellung des Scrum Masters ›
Zur Vorstellung des SCRUM-ENTWICKLER-TEAM ›