Zentrales Element von Scrum ist der Sprint. Ein Sprint bezeichnet die Umsetzung einer Iteration, Scrum schlägt ca. 30 Tage als Iterationslänge vor. Vor dem Sprint werden die Produkt-Anforderungen des Kunden in einem Product Backlog gesammelt. Auch technische und administrative Aufgaben werden dort aufgenommen. Das Product-Backlog muss nicht vollständig sein; es wird laufend fortgeführt. Die Anforderungen für den ersten Sprint sind meistens rasch aufgestellt. Die Anforderungen werden informell skizziert. Für einen Sprint wird ein Backlog erstellt, in diesen werden Anforderungen übernommen, die während des Sprints umgesetzt werden sollen. Die Entscheidung, welche Anforderungen umgesetzt werden, wird vom Kunden nach von ihm festgelegten Prioritäten getroffen. Das Entwicklungsteam organisiert sich selbst, braucht also keine detaillierten methodischen Vorschriften. [Wikipedia]
Schritte eines Sprints
- Beginnt mit einer Planungssitzung. Das Team legt in einer Besprechung fest, welche Anforderungen aus dem Product Backlog innerhalb des Sprints in ein Produktinkrement umgewandelt werden können und übernimmt diese in das Sprint Backlog. Hindernisse werden in die Impediment Liste eingetragen.
- Das Team führt die dafür notwendigen Aktivitäten aus und täglich wird zur gleichen Zeit und am gleichen Ort ein Daily Scrum statt.
- Review und Retrospektive schließen den Sprint ab. Im Sprint Review kann der Product Owner die erbrachten Arbeitsergebnisse prüfen und in der darauf folgenden Sprint Retrospektive reflektiert das Team über seine Zusammenarbeit und leitet wenn nötig für den Prozess Verbesserungsmaßnahmen ab.
- Diese werden in die darauf folgende Planungssitzung mit eingebracht.
Sprints folgen unmittelbar aufeinander. Es wird vorgeschlagen am Ende eines Sprints den Nachmittag für Sprint Review und Sprint Retrospektive einzuberufen und am darauf folgenden Tag die Planungssitzung für den nächsten Sprint durchzuführen.
Am Ende eines Sprints muss der Product Owner eine lauffähige, getestete und dokumentierte Software begutachten können. Sinnvoll ist es von jeder dieser Inkrement-Versionen einen Softwarestand zu sichern.
Dies hat zur Folge, dass in jedem Sprint die Software, Dokumentation und Tests inkrementell wachsen. Dies verhindert die „alt bekannte“ Vernachlässigung von Tests und Dokumentation gegen Ende des Projektes und hält diese zugleich klein und überschaubar.
Achtung: Hypothetisch auslieferbare Software am Ende eines Sprints muss vermieden werden. Test und Dokumentation müssen vollständig sein. Fehlen diese, so wird das Projekt kurzfristig zwar beschleunigt, mittelfristig werden aber Nacharbeiten und langsamere Entwicklungsgeschwindigkeit das Projekt bremsen.
[AMAZONPRODUCTS asin=“3898644782″]
Hinweis: Die Formulierung eines Sprint-Ziels hilft dem Team ein gemeinsames Verständnis für einen Sprint zu erlangen und fokussiert zu arbeiten.
Schutz vor Veränderungen
Ein Sprint muss vor Veränderungen geschützt sein. Anforderungen, Zeitrahmen und Teamzusammensetzungen müssen für die Dauer eines Sprints konstant bleiben. Ohne geschützten Rahmen ist die Selbstorganisation des Teams schwer möglich.
Anforderungen
Das Team verpflichtet sich für die Umsetzung gewisser Anforderungen in einem Sprint. Daher kann der Product Owner keine Änderungen im laufenden Zyklus vornehmen. Es obliegt seiner Sorgfalt Anforderungen und Prioritäten umsichtig auszuwählen.
[AMAZONPRODUCTS asin=“3446447237″]
Zeit
Für Sprints gilt absolute Termintreue. Sie starten und enden am festgelegten Zeitpunkt. Erreicht das Team sein Ziel nicht, so wird die Anforderung in Absprache mit dem Product Owner verschoben. Ist das Team allerdings schneller, so kann es um neue Anforderungen bitten, welche aber bis zum Ende des Zeitraumes umzusetzen sind.
Team
Das Team darf nur an den Grenzen der Sprints verändert werden. Hier ist es sinnvoll die neuen Mitarbeiter an den Review, die Retrospektive und die Planungssitzungen teilhaben zu lassen.
Zeitplanung
Planungssitzung, Review und Retrospektive = max. 10 % der Sprint Länge
Bsp.: 4 Wochen Sprint = 20 Arbeitstage = 2 Tage Sitzungen = 1 Tag Planungssitzung + 1 Tag Review & Retrospektive
Vorbereitung auf die Sitzungen = max. 5% der Sprint Länge
Bsp. v. O.: 1 Tag Vorbereitung
Als Product Owner sollte die Planungssitzung ab der Hälfte eines Sprints vorbereitet werden. Je besser sie vorbereitet ist, umso effektiver kann die maximale Entwicklungsgeschwindigkeit des Teams erreicht werden.
