Blog / COMPANY - SCRUM@FLS-Serie
SCRUM@FLS - DER SPRINT
5. Juli 2021
Tim Hartnack
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.
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 ›