ENGAGEMENT

Sprint

Eine fix definierte Arbeitseinheit (meist 1 bis 2 Wochen), an deren Ende ein lieferfähiges Inkrement steht und reviewt wird.

Zuletzt geprüft: vonKevin Riedl wiki ↗

Sprint ist ein Scrum-spezifischer Begriff, der in den allgemeinen Sprachgebrauch übergegangen ist und jede kurze, zeitlich begrenzte Arbeitseinheit meint. Die ursprüngliche Definition verlangt drei Dinge: feste Länge, Planungssession am Anfang, Review am Ende. Die meisten Teams behalten die ersten zwei und lassen die dritte fallen, weswegen viele Teams ihre Kadenz „Sprints" nennen, aber kein vorzeigbares Inkrement produzieren. Ein Sprint ohne Demo ist nur eine Deadline; ein Sprint ohne Retro ist ein Laufband.

Die Dauer zählt. Einwöchige Sprints erzwingen engen Scope und decken Lieferprobleme schnell auf. Zweiwöchige Sprints bieten Platz für substanzielle Arbeit, absorbieren aber mehr Drift. Dreiwöchige Sprints werden meistens zu zwei schlecht geplanten.

Beispiel für das stille Versagen: Ein Team fährt sechs Monate lang zweiwöchige „Sprints", trifft jedes Planungsmeeting und shippt nichts, das ein Stakeholder anklicken kann. Der Beirat rutscht immer weiter, weil Arbeit nach Hoffnung geschätzt wird, nicht nach dem, was reinpasst, und es gibt kein Review, das das Team zwingt, sich einem lauffähigen Inkrement zu stellen. Die Lösung ist brutal und einfach: Am Ende jedes Sprints muss jemand außerhalb des Teams nutzen können, was gebaut wurde. Kann er das nicht, ist die Kadenz Theater, und das Schrumpfen auf einwöchige Sprints legt meist innerhalb von zwei Wochen offen, warum.

Der ehrliche Trade-off und der häufigste Founder-Fehler: Sprints als Weg zu behandeln, eine feste externe Deadline zu treffen. Die Kadenz ist darum gebaut, die Zeitbox zu fixieren und den Scope zu flexen, was das Gegenteil eines harten Launch-Termins mit fixem Scope ist. Für wirklich termingetriebene Arbeit mit fixem Scope willst du einen Fixpreis-Plan mit expliziten SDLC-Milestones, kein Sprint-Board. Sprints passen zu laufender Agile-Auslieferung und iterativer Arbeit Richtung MVP; zu Research- und Design-Arbeit passen sie schlecht, wo eine zeitlich begrenzte Exploration mit schriftlicher Zusammenfassung eine erzwungene Demo schlägt. Sie hängen außerdem von gesundem CI/CD ab, denn ein Sprint, der an seinem Ende nicht shippen kann, ist kein Sprint.

// FAQ

Häufige Fragen

Einwochen-Sprints für frühphasige Teams und unklaren Scope; sie zwingen kleine Schnitte und decken Lieferprobleme früh auf. Zweiwochen-Sprints für reife Teams mit stabilem Scope. Dreiwochen-Sprints sind fast immer zwei schlecht geplante hintereinander.
Das ist ein Signal, kein Drama. Entweder war der Scope zu groß, das Team blockiert oder die Definition von „shippbar" unklar. In der Retro genau das benennen, nicht Story Points neu kalibrieren.
Nein. Kanban kennt keine Sprints, nur Flow und WIP-Limits. Wer beides mischt, bekommt das Schlechteste aus zwei Welten. Eins wählen, dann konsequent.