Scrum Sprint – planen und durchführen

Scrum bezeichnet ein Framework beziehungsweise ein Schema, nach dem Projekte in Teamarbeit organisiert und durchgeführt werden können. Verantwortlich für die Durchführung und Planung der Scrum Sprints ist der Scrummaster, der gemeinsam mit dem Projektteam und dem Produktinhaber entscheidet, welche Schritte eines Projekts in einem Sprint erledigt werden können. Scrum folgt dabei den Prinzipien des agilen Arbeitens.
Bei dieser Methode werden große und komplexe Aufgaben in kleinere, in einem überschaubaren Zeitraum durchführbare Teilstücke aufgeteilt. Das Scrum Framework und der Sprint folgen diesem Prinzip und bieten einen konkreten Rahmen, in dem die Projektteams ihre Teilaufgaben schrittweise fertigstellen. Diese Teilaufgaben werden in den Sprints abgearbeitet, sodass das herzustellende Produkt schrittweise fertiggestellt wird. Die einzelnen Entwicklungsschritte werden, insbesondere bei der Software-Entwicklung, auch Iterationen genannt.
Das agile Arbeiten mit dem Scrum Framework ermöglicht es Produktentwicklern und Projektteams, ihr Endprodukt in einzelnen Sprintphasen fertigzustellen. Diese Arbeitsweise steht im Gegensatz zu der sonst üblichen Projektorganisation, in der die Aufgaben zu Beginn verteilt werden, die einzelnen Programmierer, Produktentwickler, Salesmanager und wer sonst noch an dem Projekt beteiligt ist, anschließend längere Zeit an ihren jeweiligen Aufgaben arbeiten und zum Ende des Projekts hin versuchen, alles zusammenzufügen.
Diese klassische Projektorganisation ist jedoch sehr fehleranfällig, denn am Ende passen vielleicht nicht alle Teile zusammen, die gewünschte Funktionalität ist noch nicht erreicht oder man hat zwar ein fast fertiges Produkt, muss aber endlos auf den einen Kollegen warten, der seinen Teil noch nicht fertig hat. So kann es zu erheblichen Verzögerungen in der letzten Projektphase kommen, die durch das Arbeiten im Rahmenwerk ausgeschlossen sind.
Bei einem Scrum Sprint erfährt das gesamte Scrum Team, woran die anderen gerade arbeiten und welche Schritte als Nächstes anstehen. Bei der Planung und der rückblickenden Evaluation des Sprints wird immer wieder sichergestellt, dass alle Beteiligten genau wissen, was von ihnen zu welchem Zeitpunkt erwartet wird.
Die Sprints fungieren als Container für die vier Einzelevents Sprint Planning, Daily Scrums, Sprint Review und Sprint Retrospective. Diese werden nacheinander abgearbeitet und wiederholt, bis das Produkt fertig ist.
Beim Sprint Planning entscheidet das Team gemeinsam mit dem Scrummaster und dem Produktinhaber, welche Aufgaben beziehungsweise Tasks aus dem Product Backlog in dieser Arbeitsphase beziehungsweise in diesem Sprint abgearbeitet werden können. Im Product Backlog wurden zu Beginn des Projekts die Anforderungen an das fertige Produkt zusammengestellt.
Beim Daily Scrum trifft sich das Projektteam, um die täglichen Fortschritte und Herausforderungen bei der Erreichung der definierten Ziele zu besprechen. Gegebenenfalls können auch der Scrum Master und der Product Owner hinzugezogen werden. Die Fortschritte und der Status der einzelnen Tasks können auf einem Task Board visualisiert werden. Durch eine stets aktuelle Darstellung der Fortschritte und Herausforderungen im Daily Scrum können Überraschungen ausgeschlossen werden und man weiß immer, wie gut oder schlecht man im Zeitplan liegt.
Am Ende eines Scrum Sprints werden die Ergebnisse gemeinsam mit den Stakeholdern oder dem Product Owner, der die Stakeholder vertritt, präsentiert und besprochen. Insbesondere bei der Software-Entwicklung ist häufig das Sprint Goal, die Iteration, bereits funktionierende Komponenten, die potenziell bereits an den Kunden ausgeliefert werden können, herzustellen. Das beschleunigt nicht nur den Arbeitsprozess, sondern trägt auch zu einer besseren Qualitätssicherung und einer besseren Kommunikation mit den Stakeholdern bei.
Beim letzten Schritt beziehungsweise Event eines Scrum Sprints, der Scrum Retrospective reflektiert das Scrum Team über den Ablauf des Sprints und erörtert, was im nächsten Durchlauf besser gemacht, weggelassen oder hinzugenommen werden sollte.
Die Gesamtlänge eines Scrum Sprints sollte, wie der Name bereits suggeriert, nicht zu lang gewählt werden. Empfohlen werden Zeiträume von einer Woche bis zu einem Monat. Setzt man die Dauer eines Sprints zu lang an, mehren sich die Gefahren des klassischen Projektmanagements. Die einzelnen Ziele können zu komplex werden, der Überblick geht verloren und Fehlentwicklungen werden eventuell zu spät erkannt. Dem beugt der Scrum Sprint mit seiner kurzen Dauer und der beständigen Wiederholung seiner vier Events effektiv vor und begrenzt somit auch die potenziellen Kosten eines Projekts.
Mit der Planung des Sprints beziehungsweise dem Sprint Planning beginnt der Scrum Sprint beziehungsweise der Sprint Cycle. Hierbei trifft sich das gesamte Team mit dem Scrum Master sowie dem Produktinhaber und es wird gemeinsam entschieden, welche Aufgaben in diesem Sprint anstehen und wie diese abgearbeitet werden.
Die Aufgaben und Anforderungen an das Produkt liegen dabei bereits im Produkt-Backlog. Während der Sprint-Planung wählt man die zur Erreichung des Sprint Goal notwendigen Elemente aus dem Produkt-Backlog und überführt sie eventuell in abgewandelter Form in den Sprint-Backlog, der die Aufgaben des aktuellen Sprintzyklus enthält.
Anschließend beginnt die Arbeitsphase mit täglichen Meetings, bei denen sich die Teammitglieder gegenseitig auf den neuesten Stand bringen. So können die einzelnen Mitglieder des Scrum Teams an bewältigbaren Tasks arbeiten und der Gesamtzusammenhang trotzdem gewahrt bleiben.
Jeder Scrum Sprint (Cycle) beginnt mit einem Planungstreffen, in dem sich alle Beteiligten (Product Owner, Scrum Master oder Agile Manager sowie das gesamte Team) auf die Ziele und Aufgaben des Sprints einigen. Dabei sind die Projektziele bereits im Product Backlog definiert und der Product Owner bereitet die Übernahme in den Sprint Backlog vor. Gemeinsam wird entschieden, was realistisch schaffbar ist und wie viel Arbeitszeit zu veranschlagen ist. Dabei sollte stets ein wenig Luft für Unvorhergesehenes gelassen werden, denn die Planung einer 100-prozentigen Auslastung ist eine Garantie dafür, Ziele nicht rechtzeitig zu erreichen.
Außerdem verständigen sich alle Beteiligten auf Prioritäten und erarbeiten eine Balance aus Qualität und Geschwindigkeit. Da die Team Members hier bereits eingebunden sind, werden die Zeitangaben und die Schätzung des Arbeitsaufwandes deutlich realistischer, als wenn ein Auftraggeber mit einem Projektmanager alleine verhandelt.
Das Sprint Goal, welches hier definiert wird, sollte, zumindest im Bereich Softwareentwicklung, funktionsfähige Komponenten oder bereits implementierbare Lösungen für Teile des Produkt Backlogs enthalten. Diese Inkremente sind unter Umständen bereits auslieferbar und verbessern somit die Zusammenarbeit und die Abstimmung zwischen Scrum Team und Kunden.
Ein Beispiel für ein solches Scrum Sprintziel ist die Gestaltung einer Startseite oder die Implementierung eines Kontaktformulars, während das Projektziel die Entwicklung des gesamten Internet-Auftritts umfasst.
Das Backlog Refinement bezieht sich auf die Formulierung der gesamten Projektziele und ihre Unteraufgaben im Product Backlog. Dieses wird nicht nur zu Beginn eines Projekts erstellt und danach sklavisch abgearbeitet, sondern im Verlauf des Arbeitsprozesses immer wieder angepasst.
So können im Projektverlauf neue Aufgaben und Ziele hinzukommen, teilweise gestrichen oder modifiziert werden. Außerdem kann hier beständig an den Prioritäten gearbeitet und Akzeptanzkriterien für den Abschluss eines Tasks formuliert werden. Das Product Backlog wird dadurch stets aktuell gehalten, was die Aufnahme einzelner Tasks oder Items in das Sprint Backlog erleichtert und der Qualitätssicherung dient.
Das Backlog Refinement dient der Vorbereitung des Sprint Plannings und der Wahrung der Gesamtübersicht. Es sollte regelmäßig, beispielsweise zum Beginn jedes zweiten oder dritten Sprints, durchgeführt werden, um immer wieder den Ist- mit dem Soll-Zustand abzugleichen und eine effiziente Sprintplanung zu ermöglichen.
Die Vorbereitung eines Sprints obliegt vor allem dem Product Owner, der sich um ein kontinuierliches Backlog Refinement bemühen sollte. So bereitet er die einzelnen Items vor, die bei der Sprintplanung in den Sprint Backlog übernommen werden sollen und gewährleistet den Überblick über den Projektfortschritt insgesamt. Zu diesem Zweck sollte der Product Owner insbesondere die Ergebnisse aus der letzten Sprint Review, der Retrospective sowie eventuelles Stakeholder Feedback in das Product Backlog einarbeiten und bei der Sprintplanung vorstellen.
Zu einer guten Vorbereitung gehört außerdem die Einschätzung der Leistungsfähigkeit des Teams, in der auch die Urlaubsplanung beziehungsweise die Verfügbarkeit der einzelnen Teammitglieder beachtet werden sollte, um zu einer realistischen Einschätzung des Zeitaufwands zu gelangen. Diese Rolle übernimmt häufig der Scrum Master.
Die Dauer einer Sprintplanung ist abhängig von der Dauer des Sprints beziehungsweise Sprint Cycles und dem Umfang der definierten Tasks und Items. Er sollte jedoch möglichst kurz gehalten werden, da der Sprint selbst auch die kurze Frist anpeilt. Als Faustregel gilt, dass man pro Woche geplantem Sprint etwa zwei Stunden Sprint Planning ansetzen sollte.
Der Sprint besteht aus der Abfolge seiner vier Einzelevents: Sprint Planning, Daily Scrums, Sprint Review und Sprint Retrospective. Je nach Größe des Gesamtprojekts wird diese Abfolge, beziehungsweise dieser Sprint Cycle, mehrfach wiederholt und gegebenenfalls von Backlog Refinements ergänzt.
Wie bereits erwähnt, zielt der Sprint auf einzelne, umsetzbare Teilstücke des Gesamtprojekts ab und sollte daher auch nicht zu lange angesetzt und mit zu vielen Tasks oder zu großen Items überfrachtet werden. Die empfohlene Dauer eines Sprints liegt daher zwischen einer und vier Wochen.
Am besten legen das Team, der Product Owner und der Scrum Master die Dauer gemeinsam fest. Ein Konflikt kann jedoch zwischen Owner und Master entstehen, denn der Owner hat besonders die Kundenanforderungen und der Scrum Master die Fähigkeiten und Ressourcen des Teams im Blick. Oft muss dann ein Kompromiss zwischen Geschwindigkeit und Qualität gefunden werden.
Während der täglichen Meetings beziehungsweise des Daily Scrum teilen die Mitglieder des Scrum Teams ihre Arbeitsfortschritte. Besonderes Augenmerk wird dabei auf mögliche Herausforderungen und Blocker gelegt. Ein Blocker kann beispielsweise sein, dass ein Teammitglied für seine Arbeit auf die Vorarbeit eines anderen Mitglieds seines Teams oder aus einem ganz anderen Team oder Projekt angewiesen ist. Diese Vorarbeit muss dann entsprechend priorisiert und geleistet werden, damit keine Blockade entsteht.
Bei der Sprint Review präsentieren alle Beteiligten (Teammitglieder wie Designer, Entwickler oder Programmierer; der Scrum Master und der Product Owner) ihre Arbeitsfortschritte. Dieses Projekt Event kann auch im informellen Rahmen stattfinden und Erfolge sollten auch im Team gefeiert werden. Gelöste Aufgaben können anschließend in Produktion gehen oder als funktionierende Iteration bereits an den Kunden ausgeliefert werden. Es geht darum, möglichst das gesamte Knowledge aller Beteiligten zusammenzutragen.
Die Sprint Retrospektive schließt den Kreis des Scrum Sprints und dient bereits der Vorbereitung eines erneuten Scrum Sprint Cycles. Hier wird reflektiert, was im vergangenen Zyklus gut gelaufen ist und was in Zukunft verbessert werden sollte.
Die Vorteile des Scrum Sprints liegen in der Übersichtlichkeit und der Geschwindigkeit, mit der Projekte abgearbeitet werden und erste, funktionierende Teilstücke beziehungsweise Iterationen fertiggestellt werden können. Dabei sorgt der Scrum Master für eine kontinuierliche Kommunikation aller Stakeholder und minimiert damit den Koordinationsaufwand der einzelnen Teammitglieder.
Durch den Ablauf des Scrum Sprint Cycles ist ein ständiges und frühzeitiges Feedback und eine kontinuierliche Anpassung der Projektziele und Items gewährleistet. Das hilft, Fehlentwicklungen vorzubeugen und sorgt dafür, dass alle gemeinsam in die gleiche Richtung arbeiten.
Trotz seiner offensichtlichen Vorteile birgt der Scrum Sprint auch einige Gefahren. Durch die Aufteilung in kleine, bewältigbare Schritte kann der Überblick für das große Ganze verloren gehen und durch die flachen Hierarchien werden große Anforderungen an die Eigenverantwortung der Mitglieder des Teams gestellt. Außerdem müssen die Projektziele zu Beginn klar umrissen sein, damit eine realistische und vollständige Planung der Scrum Sprints ermöglicht wird. Das erfordert einen relativ hohen Planungsaufwand zu Beginn des Projekts, ohne den der Sprint nicht funktionieren kann.
Selbst die einfachsten Konzepte können schwer umzusetzen sein. Wenn man sich jedoch an den Ablauf der vier Scrum Events sowie an einige grundlegende Richtlinien und Tipps hält, steht einer erfolgreichen Projektplanung im Scrum Framework nichts im Wege. Als angehender Scrum Master solltest Du: