Sprint Velocity in Scrum: Vollstaendiger Leitfaden 2026

Q: Wie haengt Sprint Velocity mit Teamzufriedenheit und Nachhaltigkeit zusammen?

Nachhaltige Velocity - bei der das Team in einem Tempo arbeitet, das es unbegrenzt aufrechterhalten kann - ist ein Kernprinzip von Agile. Wenn Velocity als Druckmittel verwendet wird, fuehren Teams oft ueber nachhaltige Kapazitaet hinaus, was zu Burnout, erhoehten Defekten und schliesslichem Velocity-Zusammenbruch fuehrt. Ein Team mit moderater, aber konsistenter Velocity liefert ueber viele Sprints mehr Wert als eines, das hoch einsteigt und dann ausbrennt.

Q: Sollen Story Points neu geschaetzt werden, wenn ein Sprint bereits begonnen hat?

Story Points sollten waehrend eines Sprints fuer Velocity-Tracking-Zwecke generell nicht neu geschaetzt werden - nur wenn die Definition of Done vollstaendig erfuellt wird, zaehlen Punkte. Wenn ein Team jedoch entdeckt, dass eine Story weit komplexer als geschaetzt ist, kann es sie in kleinere Stories aufteilen. Dies unterscheidet sich davon, bestehende Stories neu zu schaetzen, um Velocity aufzublasen. Aenderungen sollten transparent und mit dem Product Owner besprochen sein.

Q: Wie geht man mit Velocity um, wenn Teammitglieder Teilzeit im Scrum-Team arbeiten?

Teilzeit-Teammitgliedschaft ist haeufig, verkompliziert aber die Velocity-Berechnung. Ein Ansatz ist die Normalisierung nach 'Team-Tagen' - verfuegbare Tage pro Sprint zu verfolgen und Punkte pro Team-Tag zu berechnen. Ein einfacherer Ansatz ist, den Beitrag des Teilzeitmitglieds als konsistenten Faktor in der Planung zu behandeln, da der Velocity-Durchschnitt seinen Beitrag bereits widerspiegelt. Vergleiche von Velocities ueber Sprints mit stark variierender Teilzeit-Verfuegbarkeit vermeiden.

Q: Was passiert mit der Velocity, wenn ein Team Continuous Delivery einfuehrt?

Teams, die Continuous Delivery praktizieren, stellen oft fest, dass die Velocity-Berechnung sich aendert, weil Arbeit mehrmals pro Sprint deployed wird, anstatt bis zum Sprint-Ende gehalten zu werden. In diesen Kontexten kann Throughput bedeutungsvoller sein als Story-Point-Velocity. Manche Teams, die Continuous Delivery nutzen, geben feste Sprint-Velocity zugunsten von Cycle-Time-Metriken auf. Velocity bleibt nuetzlich fuer Kapazitaetsplanung, solange das Team Sprint-basierte Zeremonien beibeh-aelt.

Q: Wie wirkt sich technische Schulden auf die Sprint Velocity aus?

Technische Schulden verschlechtern die Velocity im Laufe der Zeit, indem sie den Aufwand erhoehen, der erforderlich ist, um neue Features hinzuzufuegen, Bugs zu beheben und bestehenden Code zu pflegen. Ein Team, das technische Schulden ohne Adressierung anhaeuft, sieht moeglicherweise einen graduellen Velocity-Rueckgang ueber Monate, da die Komplexitaet waechst. Die Adressierung technischer Schulden kann voruebergehend die Velocity reduzieren, verhindert aber den langfristigen Velocity-Verfall durch unbehandelte Schulden.

Q: Wann sollte ein Team in Erwaegung ziehen, Story Points und Velocity-Tracking gaenzlich aufzugeben?

Manche reifen Agile-Teams, insbesondere in leistungsstarken Organisationen mit Continuous Delivery, stellen fest, dass Story Points mehr Overhead als Wert schaffen. Die #NoEstimates-Bewegung befuerwortet stattdessen das Tracking von Throughput und Cycle Time. Dies ist typischerweise eine Phase-3-Erwaegung - die meisten Teams profitieren waehrend ihrer gesamten Reife von Velocity-Tracking. Teams sollten diesen Wechsel in Erwaegung ziehen, wenn Velocity stabil und vorhersagbar ist und Story-Point-Schaetzungsdebatten unverhaltnis-maessig viel Zeit in Anspruch nehmen.

Q: Wie sollte Velocity nicht-technischen Stakeholdern kommuniziert werden?

Vermeiden Sie, rohe Story-Point-Zahlen nicht-technischen Stakeholdern zu praesentieren, da sie ohne Kontext bedeutungslos sind. Uebersetzen Sie stattdessen Velocity in Geschaeftsergebnisse: 'Basierend auf unserem Tempo koennen wir das Zahlungsmodul in 4 Wochen abschliessen.' Verwenden Sie Release-Burndown-Charts oder Roadmap-Visualisierungen anstatt Velocity-Tabellen. Wenn Stakeholder nach Lieferterminen fragen, geben Sie Bereiche (Best Case / Wahrscheinlich / Worst Case) an, die aus Velocity-Daten abgeleitet werden.

Q: Was ist der Unterschied zwischen Kapazitaet und Velocity in der Sprint-Planung?

Kapazitaet ist eine zukunftsorientierte Schaetzung der Arbeit, die ein Team im kommenden Sprint leisten kann, berechnet aus verfuegbaren Team-Tagen und historischer Produktivitaet. Velocity ist eine rueckwaertsgewandte Messung der tatsaechlich abgeschlossenen Story Points in vergangenen Sprints. Waehrend des Sprint Plannings verwenden Teams historische Velocity als Input zur Bestimmung der Kapazitaet (angepasst fuer Urlaub und bekannte Unterbrechungen), die dann verwendet wird, um zu bestimmen, wie viele Story Points aus dem Product Backlog gezogen werden.

Q: Wie wirkt Velocity mit dem Scrum-Wert des Engagements zusammen?

Velocity unterstuetzt den Scrum-Wert des Engagements, indem es Teams hilft, realistische, informierte Verpflichtungen waehrend des Sprint Plannings einzugehen. Wenn Teams historische Velocity-Daten verwenden, koennen sie sich zuversichtlich zu einem Sprint-Scope verpflichten, den sie genuineerreich genuinely koennen. Wenn Velocity als Druckmittel missbraucht wird, untergraebt es das Engagement durch das Erzwingen unrealistischer Versprechen.

Q: Ist Velocity relevant fuer Teams, die Research, Design oder Discovery statt Software-Lieferung durchfuehren?

Story-Point-Velocity ist fuer inkrementelle Lieferarbeit konzipiert und passt weniger natuerlich auf reine Discovery- oder Design-Arbeit. Teams, die Research durchfuehren, koennen sich anpassen, indem sie Velocity verwenden, um 'Lerneinheiten' pro Sprint zu verfolgen. Die Kernprinzip - empirisches, transparentes Fortschritts-Tracking - gilt fuer jede Art von Arbeit, auch wenn die spezifische Metrik angepasst werden muss.

Von Abhay Talreja

23.2.2026

Mein neuester Artikel - Empirical Process Control - The Key to Agile Success

Sprint Velocity in Scrum - Vollstaendiger Leitfaden

Sprint Velocity ist eine Metrik, die haeufig in der agilen Softwareentwicklung verwendet wird, insbesondere in Scrum, um die Arbeitsmenge zu messen, die ein Entwicklungsteam in einem einzelnen Sprint abschliessen kann.

Velocity wird typischerweise in Story Points gemessen, die relative Masseinheiten sind, die zur Schaetzung der Komplexitaet und des Aufwands verwendet werden, der erforderlich ist, um eine User Story abzuschliessen.

Am Ende jedes Sprints berechnet das Team seine Sprint Velocity, indem es die Story Points aller User Stories summiert, die sie waehrend dieses Sprints erfolgreich abgeschlossen haben.

Durch das Verstaendnis und die effektive Nutzung von Velocity koennen Teams ihre Planung verbessern und bessere Ergebnisse liefern.

Schnellantwort: Sprint Velocity auf einen Blick

Aspekt	Details
Was sie misst	Pro Sprint abgeschlossene Story Points
Berechnung	Summe der Story Points aller vollstaendig erledigten User Stories
Wann verwenden	Sprint-Planung, Release-Prognose, Retrospektiv-Analyse
Wann NICHT verwenden	Teams vergleichen, individuelle Leistung bewerten, als Ziel maximieren
Stabilisiert sich nach	3-5 Sprints fuer neue Teams
Verwandte Metrik	Throughput (Anzahl abgeschlossener Elemente, unabhaengig von der Groesse)

Inhaltsverzeichnis-

Was ist Sprint Velocity in Agile?

Sprint Velocity, oft einfach als "Velocity" bezeichnet, repraesentiert die Menge der Story Points, die ein Team innerhalb eines einzelnen Sprints abschliesst.

Waehrend einige Teams moeglicherweise andere Messungen bevorzugen, wie Stunden oder abgeschlossene Stories, bleibt das grundlegende Konzept unveraendert - Velocity quantifiziert die Arbeitsmenge, die ein Team waehrend eines Sprints erledigt.

Es ist entscheidend zu erkennen, dass Sprint Velocity eine deskriptive Metrik ist, keine Erfolgsmetrik. Sie dient dazu, die Kapazitaet Ihres Teams zu messen, anstatt diese Kapazitaet zu erhoehen.

⚠️

Velocity ist ein Planungswerkzeug, kein Leistungsziel. Druck zur "Velocity-Erhoehung" fuehrt zu aufgeblasenen Schaetzungen, gehetzter Arbeit und technischen Schulden - keines davon liefert echten Wert.

Wie berechnet man Sprint Velocity?

Die Messung der Sprint Velocity ist unkompliziert.

Am Ende jedes Sprints zaehlen Sie die Gesamt-Story-Points zusammen, die mit jeder abgeschlossenen User Story verbunden sind.

Diese Summe bildet die Velocity-Metrik Ihres Teams fuer diesen Sprint.

Beispielberechnung:

Wenn Ihr Team drei User Stories schaetzt und abschliesst:

Story A (4 Punkte) - vollstaendig fertig
Story B (2 Punkte) - vollstaendig fertig
Story C (3 Punkte) - vollstaendig fertig

Ihre Velocity fuer diesen Sprint betraegt 9 Story Points.

Wichtig: unvollstaendige User Stories sollten nicht in die Berechnung einbezogen werden, auch wenn sie zu 90% abgeschlossen sind.

Denken Sie daran: Nur PBIs, die die Definition of Done erfuellen, zaehlen.

Durchschnittliche Velocity berechnen

Um Ihre durchschnittliche Sprint Velocity zu ermitteln, summieren Sie die Story Points der letzten 3-5 Sprints und teilen durch die Anzahl der Sprints.

Beispiel:

Sprint 1: 28 Punkte
Sprint 2: 32 Punkte
Sprint 3: 36 Punkte

Durchschnittliche Velocity = (28 + 32 + 36) / 3 = 32 Story Points pro Sprint

Warum messen Teams Sprint Velocity?

Sprint Velocity bietet mehrere Vorteile fuer Agile-Teams:

1. Verbessertes Sprint Planning

Velocity befaehigt Teams, praezisere Sprint-Plaene zu erstellen, indem sie Einblicke bietet, wie viele Story Points sie realistisch innerhalb eines Sprints erreichen koennen.

2. Fortschritt visualisieren

Die Visualisierung der Sprint Velocity ueber die Zeit, oft in Form eines Burndown-Charts, liefert Teams wertvolle Einblicke in ihren Fortschritt waehrend des Sprints.

3. Fokus waehrend Retrospektiven

Sprint Retrospektiven sind eine ideale Gelegenheit, Sprint Velocity zu nutzen. Sie kann zu Beginn einer Retrospektive als Fokuspunkt dienen.

4. Optimierungsmoeglichkeiten

Moegliche Strategien zur Verbesserung der Sprint Velocity:

Backlog Refinement meistern: Gruendlich verfeinerte Backlogs ermoeglichen Teammitgliedern, Aufgaben mit allen notwendigen Informationen zu beginnen.
Automatisierung: Das Automatisieren von Testprozessen kann zu erheblichen Velocity-Verbesserungen fuehren.
Teamdynamik beobachten: Aenderungen oder Maengel im Team frueh adressieren.
Externe Abhaengigkeiten managen: Verzoegerungen durch externe Faktoren identifizieren und adressieren.

Velocity fuer Release-Planung und Prognosen verwenden

Eine der maechtigen Anwendungen der Sprint Velocity ist die Release-Prognose.

Schrittweise Release-Prognose

Gesamt-Story-Points verbleibend im Product Backlog fuer das geplante Release zaehlen
Durchschnittliche Velocity der letzten 3-5 Sprints berechnen
Verbleibende Punkte durch durchschnittliche Velocity teilen um benoetigte Sprints zu schaetzen
Mit Sprint-Laenge multiplizieren um Kalenderzeit zu erhalten

Beispiel:

Verbleibender Release-Scope: 160 Story Points
Durchschnittliche Velocity: 32 Punkte pro Sprint
Geschaetzte benoetigte Sprints: 160 / 32 = 5 Sprints
Sprint-Laenge: 2 Wochen
Geschaetztes Release-Datum: 10 Wochen ab jetzt

Geben Sie immer einen Bereich statt einem einzelnen Datum an. Verwenden Sie Minimal-Velocity (schlechtester aktueller Sprint) und Maximal-Velocity (bester aktueller Sprint), um Stakeholdern einen realistischen Bereich zu geben.

Velocity-Stabilisierung: Was Sie erwarten koennen

Waehrend der ersten Sprints eines Teams kann die Velocity erheblich schwanken. Diese Zeit ist gekennzeichnet durch:

Kalibrierung von Story-Point-Schaetzungen
Laengere Meetings als das Team Scrum lernt
Teammitglieder gewoehnen sich an die Codebasis und Domaene
Weiterentwicklung der Definition of Done

Es ist ratsam, sich erst nach drei bis fuenf Sprints auf eine stabile Velocity zu verlassen und diese zu erwarten, wenn ausreichend Daten verfuegbar werden.

Sprint Velocity verbessern

Um die Velocity Ihres Teams zu stabilisieren und zu verbessern:

Klare und praegnante User Stories schreiben
Konsistente Teammitgliedschaft und -groesse aufrechterhalten
Sprint-Retrospektiven nutzen, um Verbesserungsbereiche zu identifizieren
Abhaengigkeiten eliminieren, die den Fortschritt behindern
Eine robuste Definition of Done entwickeln
Qualitaet ueber Geschwindigkeit priorisieren - Hetze erzeugt technische Schulden
Ausreichend Zeit fuer gruendliche Tests und Code-Review einplanen

Einschraenkungen von Velocity

Waehrend Velocity ein hilfreiches Planungswerkzeug ist, ist es entscheidend, seine Einschraenkungen zu erkennen:

Velocity ist teamspezifisch: Der Vergleich der Velocity verschiedener Teams ist nicht produktiv.
Velocity kann aufgrund von Aenderungen in der Teamzusammensetzung variieren: Wenn ein Teammitglied das Team verlaesst oder hinzukommt, kann dies die Velocity beeinflussen.
Velocity ist kein Mass fuer Wert: Eine hohe Velocity bedeutet nicht unbedingt, dass das Team hochwertige Features liefert.
Velocity kann manipuliert werden: Wenn sie als Leistungsmetrik verwendet wird, werden Teams Schaetzungen aufblasen.
Velocity zeigt keine Arbeitsqualitaet: Hohe Velocity mit hohen technischen Schulden kann zukuenftige Sprints verlangsamen.

Velocity-Anti-Muster vermeiden

Anti-Muster 1: Velocity als Ziel verwenden

Problem: Management setzt Velocity-Ziele ("Sie muessen 50 Punkte pro Sprint erreichen").

Warum schaedlich: Teams blaehen Story-Point-Schaetzungen auf, ohne die tatsaechliche Ausgabe zu erhoehen.

Loesung: Velocity als Planungsinput verwenden, niemals als Leistungsziel.

Anti-Muster 2: Velocity ueber Teams hinweg vergleichen

Problem: "Team A liefert 60 Punkte pro Sprint. Team B nur 30."

Warum schaedlich: Story-Point-Skalen sind teamspezifisch. Der Vergleich ist bedeutungslos und demoralisierend.

Loesung: Den Velocity-Trend jedes Teams ueber die Zeit vergleichen, nicht absolute Zahlen teamuebergreifend.

Anti-Muster 3: Teilgutschrift fuer unvollstaendige Stories

Problem: Teams geben teilweise Velocity-Gutschrift fuer Stories, die zu 80% abgeschlossen sind.

Warum schaedlich: Teilweise Stories erzeugen falsche Velocity-Daten und untergraben die Definition of Done.

Loesung: Alles-oder-nichts-Regel anwenden. Wenn eine Story die Definition of Done nicht vollstaendig erfuellt, traegt sie null zur Velocity bei.

Velocity vs. Throughput: Was sollten Sie verfolgen?

Aspekt	Velocity	Throughput
Was wird gezaehlt	Abgeschlossene Story Points	Anzahl abgeschlossener Elemente
Schaetzung erforderlich	Ja (Story Points)	Nein
Am besten fuer	Sprint-Kapazitaet planen, Release-Prognose	Flow-Effizienz, Cycle-Time-Analyse
Manipulationsrisiko	Hoeher	Niedriger

Viele reife Agile-Teams verfolgen beides: Velocity fuer Sprint-Planung und Throughput fuer Flow-Analyse.

Die Sprint Velocity Ihres Teams regulieren

Konsistenz in der Sprint Velocity ist entscheidend:

User Stories klaeren: Stellen Sie sicher, dass User Stories vor dem Sprint klar und verstaendlich sind.
Konsistenz aufrechterhalten: Vermeiden Sie haeufige Aenderungen bei Teamzusammensetzung, Sprint-Laenge oder Prozessen.
Einheitliche Definition of Done etablieren: Klare Kriterien verbessern die Schaetzungsgenauigkeit. Definieren Sie "fertig".
Sprint-Retrospektiven abhalten: Nutzen Sie die iterative Natur von Agile, um kontinuierlich zu verbessern.
Den Trend verfolgen, nicht die Zahl: Fixieren Sie sich nicht auf einzelne Sprint-Velocity-Zahlen. Verfolgen Sie den rollierenden Durchschnitt ueber 5-10 Sprints.

Velocity-Reifemodell

Phase 1: Bewusstsein (Sprints 1-6)

Das Team lernt Story Points und Schaetzung. Velocity variiert erheblich (Schwankung von 50%+ ist normal). Keine Velocity fuer externe Prognosen verwenden.

Phase 2: Vorhersagbarkeit (Sprints 7-15)

Velocity beginnt sich zu stabilisieren (Schwankung innerhalb von 20-25%). Team nutzt Velocity sicher fuer Sprint-Planung. Rollierender Durchschnitt wird verfolgt.

Phase 3: Optimierung (Sprint 16+)

Velocity ist stabil und vorhersagbar. Team verwendet Velocity fuer stakeholder-orientierte Release-Prognosen. Throughput wird neben Velocity fuer Flow-Analyse verfolgt.

Fazit

Sprint Velocity ist ein wertvolles Instrument im Agile-Toolkit, aber ihre effektive Nutzung erfordert ein differenziertes Verstaendnis.

Wichtige Erkenntnisse:

Velocity als Summe der Story Points fuer vollstaendig erledigte Stories berechnen
Velocity fuer Sprint-Planung und Release-Prognose verwenden, niemals als Leistungsziel
3-5 Sprints abwarten, bevor Velocity als zuverlaessig gilt
Throughput neben Velocity fuer ein vollstaendiges Bild der Flow-Gesundheit verfolgen
Velocity niemals teamuebergreifend vergleichen
Einbrueche von 25%+ sofort untersuchen - sie signalisieren echte Probleme

Agile-Erfolg haengt letztendlich von der Faehigkeit des Teams ab, sich anzupassen und ihre Praktiken mit dem uebergeordneten Ziel der Wertlieferung an Kunden auszurichten.

Quiz über Sprint Velocity

Ihre Punktzahl: 0/15

Frage: Was misst Sprint Velocity in einem Scrum-Team?

Die Anzahl der pro Sprint geleisteten ArbeitsstundenDie Gesamt-Story-Points der vollstaendig abgeschlossenen User Stories in einem SprintDie Anzahl der waehrend eines Sprints behobenen BugsDer Prozentsatz des abgeschlossenen Product Backlogs

Weiterlesen

Scrum Burndown-Charts: Vollstaendiger LeitfadenErfahren Sie, wie Burndown-Charts Ihre Sprint Velocity nutzen, um den taeglichen Fortschritt zu visualisieren und die Sprint-Fertigstellung vorherzusagen.

Kumulative Flussdiagramme: WIP visualisierenEntdecken Sie, wie CFDs die Velocity-Verfolgung erganzen, indem sie Flow-Effizienz und Engpaesse ueber Workflow-Stufen zeigen.

Sprint Planning: Effektive Scrum-AusfuehrungMeistern Sie Sprint Planning unter Verwendung der historischen Velocity Ihres Teams, um realistische Sprint-Verpflichtungen festzulegen.

Sprint Retrospektive: Team-Performance verbessernNutzen Sie Velocity-Trends als Daten in Retrospektiven, um systemische Probleme und Verbesserungsmoeglichkeiten zu identifizieren.

Definition of Done: Der vollstaendige LeitfadenVerstehen Sie, warum eine klare Definition of Done fuer die genaue Velocity-Berechnung und konsistente Sprint-Planung wesentlich ist.

Scrum Product Backlog: Wesentliches Agile-ArtefaktErfahren Sie, wie velocity-basierte Prognosen dem Product Owner helfen, das Product Backlog fuer realistische Release-Planung zu priorisieren.

Was ist eine User Story? Vollstaendiger LeitfadenMeistern Sie das Schreiben von User Stories, um gut dimensionierte Stories zu erstellen, die zu einer stabilen, vorhersagbaren Sprint Velocity beitragen.

Der Sprint: Vollstaendiger Leitfaden zur Scrum-IterationVerstehen Sie, wie Sprint-Struktur und Time-Boxing die Grundlage fuer eine aussagekraeftige Velocity-Messung bilden.

Häufig gestellte Fragen (FAQs)

Wie haengt Sprint Velocity mit Teamzufriedenheit und Nachhaltigkeit zusammen?

Sollen Story Points neu geschaetzt werden, wenn ein Sprint bereits begonnen hat?

Wie geht man mit Velocity um, wenn Teammitglieder Teilzeit im Scrum-Team arbeiten?

Was passiert mit der Velocity, wenn ein Team Continuous Delivery einfuehrt?

Wie wirkt sich technische Schulden auf die Sprint Velocity aus?

Wann sollte ein Team in Erwaegung ziehen, Story Points und Velocity-Tracking gaenzlich aufzugeben?

Wie sollte Velocity nicht-technischen Stakeholdern kommuniziert werden?

Was ist der Unterschied zwischen Kapazitaet und Velocity in der Sprint-Planung?

Wie wirkt Velocity mit dem Scrum-Wert des Engagements zusammen?

Ist Velocity relevant fuer Teams, die Research, Design oder Discovery statt Software-Lieferung durchfuehren?

Was sollte der Product Owner bei Velocity-Diskussionen tun?

Wie aendert sich Velocity, wenn ein Scrum-Team von 2-woechigen auf 3-woechige Sprints wechselt?

Wann sollte die Velocity oeffentlich ausserhalb des Scrum-Teams sichtbar sein?

Wie koennen grosse Teams oder Teams von Teams Velocity verfolgen?

Wie unterscheiden sich Kapazitaet und Velocity in der Praxis?

Burn-Down-Charts Cumulative Flow Diagrams