Sprints in Scrum Fester Takt, klare Ziele — so entsteht Lieferfähigkeit

Ein Sprint ist wie ein Mini-Projekt innerhalb des Projekts: Das Team nimmt sich für ein bis vier Wochen ein klar umrissenes Ziel vor, arbeitet fokussiert daran und liefert am Ende etwas Fertiges ab. Kein „zu 80 % fertig" — sondern ein echtes, nutzbares Ergebnis. Dieser Rhythmus ist das Herzstück von Scrum.

Sprints auf einen Blick

Was?
Fester Arbeitszyklus mit definiertem Ziel
Dauer
1-4 Wochen (meistens 2 Wochen)
Ergebnis
Ein fertiges, potentiell auslieferbares Produktinkrement
Regel
Kein Sprint wird vorzeitig abgebrochen oder verlängert
Timeline eines 2-Wochen-Sprints: Planning, Dailies, Review, Retro
Ein typischer 2-Wochen-Sprint im Überblick

Wie läuft ein Sprint ab?

Jeder Sprint folgt dem gleichen Muster — und genau das macht ihn so wirksam. Der Rhythmus gibt dem Team Sicherheit, ohne es einzuengen.

  1. Sprint Planning: Zu Beginn setzt sich das Team zusammen und plant, was in den nächsten ein bis vier Wochen umgesetzt wird. Der Product Owner bringt die wichtigsten Einträge aus dem Product Backlog mit. Das Team entscheidet, was realistisch machbar ist — und hält das im Sprint Backlog fest.
  2. Tägliche Abstimmung (Daily Scrum): Jeden Tag, 15 Minuten, im Stehen. Jeder sagt, woran er arbeitet und ob ihn etwas blockiert. Kein Statusbericht für den Chef — sondern Teamabstimmung auf Augenhöhe.
  3. Entwicklung: Das Team arbeitet eigenverantwortlich an den Aufgaben. Keine neuen Anforderungen von außen, keine spontanen Änderungen. Der Sprint ist eine geschützte Zeitbox.
  4. Sprint Review: Am Ende zeigt das Team, was fertig geworden ist. Stakeholder geben Feedback. Der Product Owner entscheidet, ob die Definition of Done erfüllt ist.
  5. Retrospektive: Das Team reflektiert: Was lief gut? Was nicht? Was ändern wir? Dieser Schritt ist der Motor für kontinuierliche Verbesserung.

Was heißt „fertig"?

Das klingt nach einer einfachen Frage — ist es aber nicht. „Fertig" heißt in Scrum nicht „Der Code ist geschrieben". Es heißt: Die Arbeit erfüllt alle Qualitätskriterien, auf die sich das Team vorab geeinigt hat.

Diese Kriterien stehen in der Definition of Done — einer gemeinsamen Checkliste. Typische Punkte sind: Code geschrieben, getestet, dokumentiert, von einem Teammitglied geprüft und in die Integrationsumgebung überführt.

Warum das wichtig ist? Weil „fast fertig" in Scrum nicht zählt. Entweder ein Produktinkrement erfüllt die Definition of Done — oder es ist nicht fertig. Punkt. Das verhindert, dass sich halbgare Arbeit anhäuft.

Welche Regeln gelten im Sprint?

Sprints klingen flexibel — und sind es auch. Aber ein paar Regeln sind fix:

  • Die Länge steht fest: Ob eine, zwei oder vier Wochen — einmal festgelegt, bleibt die Sprint-Dauer gleich. Das gibt allen Planungssicherheit.
  • Kein Abbruch von außen: Nur der Product Owner kann einen Sprint abbrechen, und auch das nur in Ausnahmefällen (wenn das Sprint-Ziel obsolet geworden ist).
  • Keine neuen Anforderungen während des Sprints: Was im Sprint Planning vereinbart wurde, gilt. Neue Ideen wandern ins Product Backlog — für den nächsten Sprint.
  • Das Team entscheidet über das Wie: Der Product Owner sagt, WAS gebaut werden soll. Das Team entscheidet, WIE es umgesetzt wird.