Theorie "Sprint"
Sprinting und Sprint¶
Wie Sie bereits wissen, ist der Sprint ein Scrum Event - jedoch eines von besonderer Bedeutung. Denn: Der Sprint ist „der Container" der anderen Scrum Events. Das heißt, alle anderen Scrum Events finden während des Sprints statt. Dies ist nicht verwunderlich, denn sobald ein Sprint vorbei ist, beginnt der nächste Sprint - ohne Pause und ohne die Zeit, dass etwas anderes „zwischendurch" passieren kann.
Eine zentrale Rolle während des Sprints spielt das „Sprinting". Das Sprinting ist die Zeit, an der aktiv am Increment gearbeitet und entwickelt wird.
Das Sprint Planning Meeting ist abgeschlossen, das Sprint Goal ist bekannt und der Sprint Backlog wurde erarbeitet und für alle Beteiligten gut sichtbar platziert. Nun kann mit der Entwicklungsarbeit begonnen werden. Die Developer können die vorher festgelegten Tasks bearbeiten und sich Schritt für Schritt - d. h. in Iterationen - dem Sprint Goal nähern.
Nochmal zusammengefasst
Ein Sprint beginnt, sobald der vorherige Sprint aufhört. Der Sprint ist der Container aller anderen Scrum Events, d. h. während eines Sprints finden unterschiedliche Meetings statt und es wird während eines Sprints auf ein vorher festgelegtes Sprint Goal hingearbeitet.
Während jedes Sprints findet das Sprinting statt - immer zwischen dem Sprint Planning Meeting und dem Sprint Review. Jeden Tag während des Sprintings wird das Daily Scrum Meeting abgehalten.
Das Ziel eines Sprints¶
Das Ziel ist nicht, innerhalb eines Sprints das komplette Produkt zu erschaffen, sondern pro Sprint ein potenziell auslieferbares Increment zu erstellen. Um es anders auszudrücken: Die Developer erstellen pro Sprint einen dünnen vertikalen Schnitt des Gesamtproduktes. In diesem Zusammenhang fällt daher oft der Ausdruck: Thin vertical slices.
Ein potenziell auslieferbares Produkt
Das Increment am Ende eines Sprints sollte potenziell auslieferbar sein - das bedeutet nicht, dass es auch ausgeliefert werden muss. Eine Veröffentlichung oder Aushändigung an den Kunden sollte nach jedem Sprint möglich sein, es ist aber keineswegs eine Pflicht, das Increment auch tatsächlich auszuliefern.
Was während des Sprintings wichtig ist
Während des Sprintings ist es wichtig, dass sich die Developer auf die Aufgaben konzentrieren, die für den jeweiligen Sprint vorgesehen sind. Langfristige Aufgaben oder User Stories, Epics oder Themes, die noch in weiter Zukunft liegen, wurden noch nicht in das Sprint Backlog übernommen und müssen entsprechend noch nicht bearbeitet werden. Developer sollten sich daher auch nicht mit diesen PBIs beschäftigen.
Die Dauer eines Sprints¶
Da innerhalb eines Sprints kein gesamtes Produkt erstellt werden soll, der „dünner vertikale Schnitt" aber potenziell auslieferbar sein muss, ist es wichtig, dass ein Sprint nicht zu lange, aber auch nicht zu kurz andauert. Wie lang ein Sprint sein soll, wird vorher festgelegt. Bei der Festlegung der Dauer sollte der Product Owner im Hinterkopf behalten, dass der Sprint nur so lange andauern sollte, wie das geschäftliche Risiko überschaubar ist. Außerdem bietet es sich an, dass der Sprint so lange dauert, dass andere geschäftliche Angelegenheiten mit dem Sprint synchronisiert werden können.
Wichtig ist jedoch, dass Intervalle (die sogenannte time box) nicht länger als vier Wochen dauern und dass - sobald die Sprintdauer einmal festgelegt ist - der Zeitraum fix ist. Die Zeiträume können nur verändert werden, wenn das Scrum Team dies gemeinsam entscheidet. Dem Scrum Team muss bei einer Veränderung der Zeiträume allerdings bewusst sein, dass dadurch die Begutachtung des Projektfortschritts und der Prozessgüte erschwert wird.
Events und Meetings während des Sprints¶
Entwicklungsintervalle sind time-boxed¶
Ein Sprint ist, wie auch die anderen Scrum Events, time-boxed. Das heißt, dass das Ereignis innerhalb eines bestimmten Zeitrahmens abgeschlossen werden muss. Demnach wird der Sprint beendet, sobald die time box abgelaufen ist - auch wenn das Produktinkrement nicht vollständig fertiggestellt wurde. Auch wenn die Scrum Events durch die time box ein festes Ende haben, ist dieses Ende nicht gleichzusetzen mit einer Deadline. Denn eine Deadline ist meist von außen vorgegeben, wohingegen die time box vom Scrum Team selbst gesetzt wird. Außerdem drohen den Developern keine externen Konsequenzen, wenn Sie das Sprint Goal innerhalb der time box nicht erreichen.
Welche Sprintdauer optimal ist, ist von Projekt zu Projekt unterschiedlich. Bei komplexen Entwicklungsvorhaben bieten sich allerdings kürzere Sprints an, da
- auf diese Weise schneller gehandelt werden kann, falls das Projekt nicht in die richtige Richtung läuft.
- die Komplexität gesenkt wird.
- das Risiko verringert wird.
Vorteil von kurzen Intervallen
Der Grund, weswegen Sprints zeitlich begrenzt sind, ist einfach: Wenn der Prozess von der Idee bis zum fertigen Produkt verdichtet und entsprechend kurz ist, können Probleme erkannt und Prozessschwächen frühzeitig erkannt werden.
Meetingsequenzen¶
Bisher haben Sie schon von folgenden Scrum Events bzw. Meetings gehört:
- Kein offizielles Scrum Event: Backlog Refinement Meeting
- Sprint Planning Meeting
- Sprint
Weitere Meetings, die während jedes Sprints stattfinden sind:
- Daily Scrum Meeting, welches jeden Tag während des Sprintings stattfindet
- Sprint Review, welche im Anschluss zum Sprinting stattfindet
- Sprint Retrospective, welche nach dem Sprint Review und vor dem neuen Sprint stattfindet
- Kein offizielles Scrum Event: Release Planning Meeting, welches am Anfang des Projektes stattfinden kann
Während der nächsten Kapitel werden Sie mehr über die Ihnen noch unbekannten Scrum Events erfahren. An dieser Stelle haben Sie die Möglichkeit Ihr bisher erlangtes Wissen noch einmal zu überprüfen:
Was ist das Backlog Refinement Meeting, wie ist der Ablauf und wer nimmt teil?
Das Backlog Refinement Meeting ist ein regelmäßiges Zeitfenster zur Überprüfung und Bewertung des Product Backlogs. Dabei werden die User Stories im Backlog durchgegangen, auf ihre Relevanz hin überprüft und kontrolliert, ob sie die Interessen der Stakeholder noch widerspiegeln. Einen festen Ablauf für dieses Meeting gibt es nicht, eine mögliche Agenda könnte aber wie folgt aussehen:
- Ordnen und Priorisieren der Product-Backlog-Einträge
- Löschen von Product-Backlog-Einträgen, welche nicht mehr wichtig sind
- Hinzufügen von neuen Product-Backlog-Einträgen
- Ausformulieren und Hinzufügen von Details zu den Product-Backlog-Einträgen
- Zusammenfassen von Product-Backlog-Einträgen
- Schätzen von Product-Backlog-Einträgen (Aufwand)
- Eventuell Planung von Releases
Verantwortlich für das Backlog Refinement Meeting ist der Product Owner in seiner Rolle als Manager des Product Backlogs. Unterstützt wird er dabei von den Developern. Der Scrum Master kann, muss aber nicht, anwesend sein.
Was ist das Sprint Planning Meeting, wie lange dauert es und wer nimmt teil?
Das Sprint Planning Meeting ist der Auftakt für den folgenden Sprint. Während dieses Meetings wird die Arbeit festgelegt, die während des Sprints zu erledigen ist. Am Ende steht ein Plan, der vom gesamten Scrum Team erstellt wurde.
Behandelte Themen:
- Warum ist dieser Sprint wertvoll?
- Was kann in diesem Sprint erreicht werden?
- Wie sollen die ausgewählten Aufgaben erledigt werden?
Die Dauer des Sprint Planning Meetings hängt von der Dauer des Sprints ab. Das Meeting dauert maximal acht Stunden bei einer maximalen Sprintdauer von vier Wochen.
An diesem Meeting nimmt das gesamte Scrum Team bestehend aus:
- Product Owner,
- Developers und
- Scrum Master teil.
Gegebenenfalls können auch Vertreter des Kunden oder Anwenders anwesend sein.