Methoden

Sprint

Ein Sprint ist eine zeitlich fixierte Iteration (typischerweise 2 Wochen) im Scrum-Framework, in der ein Entwicklungsteam ein definiertes Set an Anforderungen umsetzt und ein funktionsfähiges Software-Inkrement liefert.

Der Sprint ist das Herzstück von Scrum und der Taktgeber agiler Softwareentwicklung. In regelmäßigen, gleichlangen Iterationen liefert das Team funktionsfähige Software – nicht irgendwann, sondern alle zwei Wochen. Diese Vorhersagbarkeit gibt Stakeholdern Planungssicherheit und dem Team einen klaren Rhythmus. Jeder Sprint ist ein Mini-Projekt mit Planung, Umsetzung, Prüfung und Reflexion.

Was ist Sprint?

Ein Sprint ist ein zeitlich begrenzter Entwicklungszyklus (Timebox) von konstanter Dauer, typischerweise 1-4 Wochen. Während eines Sprints entwickelt das Scrum-Team ein potenziell auslieferbares Produktinkrement. Der Sprint hat vier Events: Sprint Planning (Was wird umgesetzt und wie?), Daily Scrum (tägliche 15-Minuten-Abstimmung), Sprint Review (Ergebnis-Präsentation an Stakeholder) und Sprint Retrospektive (Team-Reflexion und Prozessverbesserung). Das Sprint-Ziel (Sprint Goal) gibt eine übergeordnete Richtung vor und hilft dem Team, Prioritäten zu setzen. Einmal begonnen, soll der Sprint-Scope nicht mehr verändert werden – neue Anforderungen kommen ins Backlog für den nächsten Sprint.

Wie funktioniert Sprint?

Im Sprint Planning wählt das Team Items aus dem Product Backlog und erstellt das Sprint Backlog mit konkreten Aufgaben. Täglich trifft sich das Team zum Daily Scrum und bespricht: Was habe ich gestern geschafft? Was mache ich heute? Gibt es Hindernisse? Am Sprint-Ende zeigt das Team das Ergebnis im Review – Stakeholder geben Feedback, das in die Backlog-Priorisierung einfließt. In der Retrospektive reflektiert das Team: Was lief gut? Was können wir besser machen? Was ändern wir im nächsten Sprint? Dann beginnt der Zyklus von vorne.

Praxisbeispiele

Sprint 1 eines MVP: Login, Registrierung und Profilseite werden umgesetzt – am Sprint-Ende kann sich ein Nutzer erstmals registrieren und anmelden.

Feature-Sprint: Das Team implementiert eine Warenkorb-Funktion mit Produktauswahl, Mengenänderung und Preisberechnung in einem 2-Wochen-Sprint.

Bug-Fix-Sprint: Nach einem Release werden kritische Bugs priorisiert und in einem fokussierten Sprint behoben, bevor neue Features folgen.

Performance-Sprint: Das Team optimiert Ladezeiten, Datenbank-Queries und Caching – messbare Performance-Verbesserungen als Sprint-Ziel.

Typische Anwendungsfälle

Produktentwicklung: Neue Features in planbaren Intervallen ausliefern und validieren

Kundenprojekte: Regelmäßige Deliverables geben Auftraggebern Transparenz und Kontrolle

Bug-Fixing und Stabilisierung: Fokussierte Sprints für Qualitätsverbesserung nach einem Release

Prototyping: Schnelle Sprints (1 Woche) für Proof-of-Concept-Entwicklung und Validierung

Team-Onboarding: Neue Teammitglieder lernen den Codebase und die Prozesse innerhalb der Sprint-Struktur kennen

Vorteile und Nachteile

Vorteile

Planbarkeit: Feste Zeitrahmen ermöglichen verlässliche Prognosen für Stakeholder
Regelmäßiges Feedback: Alle 2 Wochen können Stakeholder Ergebnisse prüfen und Richtung geben
Fokus: Das Team arbeitet an einem klar definierten Set an Aufgaben ohne Störungen durch neue Anforderungen
Messbarkeit: Velocity (Story Points pro Sprint) macht die Teamleistung transparent und planbar
Lernzyklen: Jede Retrospektive ermöglicht dem Team, sich kontinuierlich zu verbessern

Nachteile

Sprint-Overhead: Planning, Review und Retrospektive binden Zeit – bei zu kurzen Sprints überwiegt der Overhead
Scope-Starrheit: Dringende Änderungen während des Sprints sind nicht vorgesehen und stören den Fokus
Velocity-Druck: Die Messung der Teamleistung pro Sprint kann zu ungesundem Leistungsdruck führen
Nicht für alle Arbeit geeignet: Support, Wartung und Ad-hoc-Aufgaben passen oft besser zu Kanban als zu Sprints

Häufig gestellte Fragen zu Sprint

Wie lang sollte ein Sprint sein?

Die meisten Teams arbeiten mit 2-Wochen-Sprints – das ist der beste Kompromiss aus Planungssicherheit und Feedbackfrequenz. 1-Wochen-Sprints eignen sich für Prototyping und sehr dynamische Umgebungen. 3-4-Wochen-Sprints sind bei komplexen Themen sinnvoll, aber das Feedbackintervall wird länger. Wichtig ist die Konstanz: Die Sprint-Länge sollte nicht ständig wechseln.

Was passiert, wenn nicht alles im Sprint fertig wird?

Nicht abgeschlossene Items gehen zurück ins Product Backlog und werden für den nächsten Sprint neu priorisiert. Das ist kein Versagen, sondern normaler Bestandteil agiler Entwicklung. Wichtig ist, in der Retrospektive zu analysieren, warum die Schätzung nicht passte, und die Sprint-Planung für künftige Sprints anzupassen.

Kann man Sprints vorzeitig abbrechen?

Ja, aber nur der Product Owner kann einen Sprint abbrechen – und nur, wenn das Sprint-Ziel obsolet geworden ist (z.B. durch strategische Änderungen oder neue Marktbedingungen). Ein Sprint-Abbruch ist ein Ausnahmefall und sollte selten vorkommen. Erledigte Arbeit wird reviewed, nicht erledigte Items gehen zurück ins Backlog.

Software agil in Sprints entwickeln?

Wir beraten Sie gerne zu Sprint und finden die optimale Lösung für Ihre Anforderungen. Profitieren Sie von unserer Erfahrung aus über 200 Projekten.

Agiles Projekt planen Kostenlos beraten lassen

Zurück zum IT-Glossar