Sprints haben ein Zeitfenster von einem Monat oder weniger, in dem das Entwicklerteam ein nutzbares und potentiell releasefähiges Produkt-Inkrement erstellt. Sprints haben eine konstante Dauer während der gesamten Entwicklungszeit. Während des Sprints werden keine Änderungen vorgenommen, die das Sprintziel gefährden würden. Die Qualitätsziele sinken nicht. Der Scope kann zwischen dem Product Owner und dem Entwicklungsteam geklärt und neu verhandelt werden, wenn mehr gelernt wird. Jeder Sprint hat ein Ziel. Innerhalb jedes Sprints baut und testet das Entwicklungsteam einen funktionalen Teil des Produkts, sodass der Product Owner es akzeptiert und die Funktionalität zu einem potenziell lieferbaren Produkt wird. Sprints ermöglichen Vorhersagbarkeit, indem sie mindestens nach jeden Kalendermonat eine Überprüfung und Anpassung der Fortschritte in Richtung Sprintziel sicherstellen. Sprints begrenzen das Risiko auf einen Kalendermonat. Wenn ein Sprint beendet ist, beginnt ein weiterer Sprint.

Sprints als Rahmen für andere Scrum Events

Jeder Sprint beginnt mit zwei Planungsevents, dem Sprint Planning 1 und 2: Das Was-Event und das Wie-Event. Im Was-Event verpflichtet sich das Scrum Team zu den User Stories aus dem Scrum Product Backlog und nutzt ein Wie-Meeting, um die engagierten User Stories in kleinere und konkrete Aufgaben zu zerlegen. Danach startet der Sprint. Am Ende des Sprints wird ein Sprint Review Meeting durchgeführt. Hier überprüft der Product Owner mit dem Team und Stakeholdern, ob alle bestätigten Elemente vollständig und korrekt implementiert sind. Zusätzlich wird ein Sprint Retrospektive Meeting durchgeführt, um die Projektdurchführung zu überprüfen und zu verbessern. Während des Sprints findet täglich ein kurzes Standup-Meeting (Daily Scrum Meeting) statt, um den Status der Items zu aktualisieren und die Selbstorganisation des Teams zu unterstützen. Zu den einzelnen Scrum Events findest du genauere Informationen in den Artikeln zu Sprint Planning 1+2, Sprint Review, Sprint Retrospektive und Daily Scrum.

Wer definiert das Sprintziel?

Der Product Owner beschreibt das Ziel, das mit dem Sprint erreicht werden soll. Die Erreichung des Ziels, spiegelt sich in den Backlog-Items. Gemeinsam wird von allen Team-Mitgliedern ein Verständnis über die Arbeitsinhalte des Sprints im Sprint Planning erarbeitet. Dieses gemeinsame Verständnis findet im Sprint-Ziel seinen Ausdruck. Beispiele:

• • Wir können das neue UI dem Vorstand präsentieren
  • Bereitstellung von Basisfunktionalitäten, um Geschäftspartner und Ansprechpartner zu verwalten
  • Die Funktionen zur Barrierefreiheit des UIs sind implementiert
  • Die Archivierungsfunktionalität ist soweit rund, dass wir sie ausliefern können

Mit einem gemeinsamen Ziel wird sichergestellt, dass das Team sich in die gleiche Richtung bewegt.

Wie wird das Sprintziel formuliert?

Bei der Formulierung von Zielen ist es hilfreich, die SMART-Methodik anzuwenden. SMART ist ein Akronym für „Specific – Measurable – Attractive – Realistic – Time-boxed“ und dient zur eindeutigen Definition von Zielen.

Specific (spezifisch)

Ein Ziel ist konkret und unmissverständlich zu benennen. Alle im Team müssen im Rahmen der Zielformulierung das gleiche inhaltliche Verständnis haben. Es ist wichtig, einen Konsens zu finden, so dass alle hinter dem Ziel stehen.

Measurable (messbar)

Sprintziele sind so zu definieren, dass man ihre Erreichung messen kann. Messbare, detaillierte Abnahmekriterien finden sich zwar in den User Stories, trotzdem ist es wichtig für das Sprintziel selbst zu definieren, um den Erfolg oder Misserfolg eines Sprints zu erkennen. Das ist insbesondere dann wichtig, wenn nicht alle gewählten Items im Backlog am Ende umgesetzt wurden.

Attractive (attraktiv)

Das Ziel ist immer positiv formuliert. Seine Erreichung soll motivieren.

Realistic (realistisch)

Das Sprintziel muss realistisch sein. Jedes Teammitglied sollte überzeugt sein, dass es erreicht werden kann. Wenn Zweifel an der Ausführbarkeit bestehen, müssen diese diskutiert und eventuelle Hindernisse beseitigt werden.

Time-boxed (terminiert)

Durch die vorgegebene Sprint-Länge ist das Ziel automatisch terminiert. Am Ende des Sprints soll das Sprint-Ziel erreicht sein.

Kann man einen Sprint abbrechen?

Unter Umständen ist es möglich einen Sprint abzubrechen und nochmal neu zu beginnen. Ein möglicher Grund kann eine drastische Änderung von Scope, Prioritäten oder Teamaufstellung sein. Ein unvorhergesehener Mehraufwand in der Umsetzung einer User Story kann den Nutzen derart mindern, dass diese obsolet wird. Der Product Owner kann sich dann gegen die Umsetzung der Nutzergeschichte entscheiden.
Der Product Owner ist der Entscheidungsträger beim Abbruch eines Sprints und hat die Verantwortung beim Sprint Planning und über das Product bzw. Sprint Planning. Scrum Master, Entwicklungsteam und Stakeholder nehmen hier höchstens eine beratenden Rolle ein. Der Product Owner könnte nämlich nach einem abgebrochenen Sprint diesselben User Stories aufnehmen, die zuvor im Sprint abgebrochen wurden, wenn er diese immer noch als wichtig und wertvoll erachtet.

Einen Überblick zur Serie Scrum Basics findest du hier: Scrum Basics: Alles auf einen Blick