Mit "Sprint" bezeichnet Scrum den wertschöpfenden Projektprozess, bei dem das Entwicklungsteam innerhalb eines Vorgangs mit fixierter Dauer Anforderungen aus dem Sprint Backlog in ein Inkrement umsetzt.
Mit "Sprint" bezeichnet Scrum den wertschöpfenden Projektprozess, bei dem das Entwicklungsteam innerhalb eines Vorgangs mit fixierter Dauer Anforderungen aus dem Sprint Backlog in ein Inkrement umsetzt.
Der Scrum Guide vergleicht den Sprint mit einem Projekt, das einen Monat dauert. Hintergrund dieses Vergleichs ist, dass für einen Sprint die Dauer, das zu erreichende Ergebnis, die zur Verfügung stehenden Ressourcen und der Ablauf wie bei einer traditionellen Projektplanung fest vorgegeben sind. Aus Sicht des Projektmanagements entspricht ein Sprint eher einem Arbeitspaket oder einem Vorgang.
Charakteristisch für Scrum ist, dass Sprints eine festgelegte Dauer haben, der Scrum Guide geht von vier Wochen bzw. einem Monat aus. Auch kürzere Dauern bis hinunter zu einer Woche sind möglich. Eine längere Dauer wird nicht explizit ausgeschlossen, ist aber unüblich, da damit die angestrebte Flexibilität der Entwicklungsarbeit reduziert wird.
Ziel eines Sprints ist es, die im Sprint Backlog festgelegten Anforderungen so zu realisieren, dass am Ende des Sprints ein grundsätzlich ablauffähiges Inkrement zur Verfügung steht. Beim Sprint Planning wird zusätzlich das Sprint-Ziel übergeordnet ausformuliert, um dem Scrum Team Orientierung für die Steuerung des Sprints zu geben.
Ein Sprint besteht, unabhängig von seiner Dauer, aus folgenden fünf Aktivitäten:
Zentrales Prinzip von Scrum ist die Taktung der gesamten Entwicklungsarbeit in direkt aufeinanderfolgende Sprints. Bei der Ablaufplanung sind deshalb lediglich zwei Parameter zu definieren: der Projektstart und die Sprintdauer. Die Planung und Steuerung des Projekts geschieht dann nur noch mit Hilfe des Backlogs, d.h. mit dem Leistungsumfang.
Der Sprint tritt im Agilen Projektmanagement an die Stelle des Arbeitspakets im Traditionellen Projektmanagement als kleinste Controlling-Einheit für den Projektfortschritt. Der Projektfortschritt kann bei einem mit Scrum durchgeführten Projekt sinnvoll nur anhand der bisher abgeschlossenen Sprints bewertet werden. Eine weit verbreitete Kennzahl für die Leistungsfähigkeit ist dabei die Velocity, angegeben in Story Points pro Sprint.
Scrum selbst kennt jedoch keinerlei Controlling, sondern stellt es dem Product Owner frei, wie er den Projektfortschritt oder die Leistung des Entwicklungsteams quantitativ bewerten möchte.
Das Konzept, den Leistungsumfang eines Projekts in Sprints zu erstellen, ist ein Kompromiss zwischen der Notwendigkeit, konkrete Fortschritte zu erzielen und nicht ausreichend definierten sowie sich verändernden Anforderungen. Die Kapselung der produktiven Arbeit in hinsichtlich Zeit, Arbeitsinhalt, Ergebnis und Aufwand fixierten Vorgängen (Time Box), gewährleistet, dass lieferfähige Arbeitsergebnisse entstehen. Gleichzeitig ermöglicht die produktorientierte Steuerung des Projekts mit Hilfe des Product Backlogs ein integriertes und effizientes Änderungsmanagement.
Die Einbettung von Scrum in ein Projekt wird durch die Sprints hinsichtlich der Ablaufplanung sehr einfach. Z.B. kann für die gesamte Software-Entwicklung ein Arbeitspaket definiert werden, in dem nach Scrum gearbeitet wird. Wenn eine genauere Terminplanung erforderlich ist, wird für jeden Sprint ein Vorgang definiert. Wenn innerhalb der geplanten Sprints die Anforderungen nicht umgesetzt werden können, muss über einen Änderungsantrag entweder die Dauer der Entwicklungsarbeiten durch Hinzufügen weiterer Sprints verlängert werden oder das zuletzt erreichte Inkrement als in Umfang oder Qualität verringertes Ergebnis akzeptiert werden.
Zwischen einer effizienten Projektsteuerung und dem Scrum Guide gibt es bei der Steuerung von Sprints einen Widerspruch hinsichtlich des vorzeitigen Abbrechens eines Sprints. Der Scrum Guide warnt dringend vor einem vorzeitigen Sprintabbruch und begründet dies unter anderem mit "Sprint cancellations are often traumatic to the Scrum Team …" (Schwaber, Sutherland: The Scrum Guide, 2017). Aus Sicht der Steuerung eines risikobehafteten und für Änderungen anfälligen Projekts ist dieses starre Festhalten an einem geplanten Ablauf jedoch nicht nachvollziehbar. Wenn z.B. das zuletzt erreichte Inkrement als ausreichend zur Erreichung des Projektziels erkannt wird, gibt es keinen Grund, wertvolle Engpassressourcen weiter mit nicht wertschöpfenden Arbeiten zu blockieren. Warum Software-Entwickler ein "Trauma" erleiden sollen, wenn sie eine begonnene Programmierung abbrechen, wird im Scrum Guide nicht ausgeführt.
Die iterativ-inkrementelle Erstellung des Leistungsumfangs in Sprints, sodass nach jedem Sprint mit dem Inkrement ein grundsätzlich funktionsfähiges Produkt vorliegt, entspricht auch dem Gedanken des Minimum Viable Products im Lean-Startup-Modell.
