Sprint
Eine fix definierte Arbeitseinheit (meist 1 bis 2 Wochen), an deren Ende ein lieferfähiges Inkrement steht und reviewt wird.
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.
Wann das im Softwareprojekt zählt. Immer dann, wenn du laufende, iterative Auslieferung kaufst und in stetiger Kadenz lauffähige Software sehen willst statt einer großen Enthüllung am Ende.
Was Founder meistens falsch machen. Sie behandeln Sprints als Weg, einen fixen externen Launch-Termin zu treffen, was genau verkehrt ist: Die Kadenz fixiert die Zeitbox und flext den Scope. Sie lassen außerdem Demo und Retro fallen, bekommen also Planungsmeetings und shippen nichts, das ein Stakeholder anklicken kann.
Wie Wavect damit umgeht. Wir behalten Demo und Retro, und ein lauffähiges Inkrement, das jemand außerhalb des Teams nutzen kann, ist am Ende jedes Sprints die Messlatte. Für wirklich termingetriebene Arbeit mit fixem Scope planen wir stattdessen gegen explizite Milestones, wie in der QA-Checkliste vor dem Launch beschrieben.