Rechner für Engineering-Velocity und Kapazität

Schluss mit Raten bei der Sprint-Kapazität. Nutzen Sie echte Daten und bewährte Formeln für realistische Sprints, Velocity-Trends und planbare Liefertermine. Inkl. kostenlosem Rechner und Vorlagen.

Warum Velocity-Tracking für Dev-Teams wichtig ist

Das Sprint-Planungs-Problem:

Montagmorgen. Sprint-Planungs-Meeting. Ihr PM fragt: „Wie viele Story Points können wir uns für diesen Sprint vornehmen?“

Ohne Velocity-Daten raten Sie:

• „Vielleicht 40 Punkte? So war es beim letzten Mal …“
• „John ist im Urlaub, also eher weniger …“
• „Wir haben noch den Production-Vorfall …“
• „Sagen wir 35 Punkte, um sicherzugehen?“

Zwei Wochen später:

• 28 Punkte erledigt (20 % unter dem Commitment)
• Stakeholder sind unzufrieden mit „langsamem Fortschritt“
• Das Team fühlt sich schlecht wegen „Unterleistung“
• Nächste Sprint-Planung: dasselbe Raten

Das eigentliche Problem: Sie planen nach Gefühl, nicht nach Daten.

Die Lösung: Engineering-Velocity berechnen und tracken.

⚠️ INTERAKTIVER VELOCITY-RECHNER

[PLATZHALTER FÜR INTERAKTIVEN RECHNER]

In diesem Abschnitt wird ein interaktiver JavaScript-Rechner mit folgenden Funktionen eingebunden:

Rechner-Funktionen:

Eingabefelder:

1. Teamgröße – Anzahl Entwickler im Team
2. Sprint-Länge – Tage pro Sprint (typisch 10–14 Tage)
3. Stunden pro Tag – Arbeitsstunden pro Entwickler und Tag
4. Meeting-Zeit – Daily Standup + Planung + Retro (Stunden/Tag)
5. Historische Velocity – Durchschnittliche erledigte Story Points in den letzten 3–5 Sprints
6. Story-Points-zu-Stunden-Verhältnis – Durchschnittliche Stunden pro Story Point Ihres Teams

Berechnungen:

1. Brutto-Kapazität = Teamgröße × Sprint-Tage × Stunden/Tag
2. Meeting-Overhead = Meeting-Stunden × Sprint-Tage × Teamgröße
3. Netto-Kapazität = Brutto − Meetings − Puffer (20 %)
4. Empfohlenes Sprint-Commitment = basierend auf historischer Velocity
5. Velocity-Trend = Letzte 5 Sprints mit Trendlinie
6. Kapazität pro Entwickler = Individuelle Zuteilung

Ausgaben:

• Sprint-Kapazität in Stunden
• Empfohlenes Story-Point-Commitment
• Puffer für ungeplante Arbeit
• Kapazität pro Entwickler
• Velocity-Trend-Diagramm
• Vergleich mit Team-Benchmark

Export:

• Als PDF herunterladen
• Als CSV exportieren
• In Corcava-Projekt speichern

Engineering-Velocity verstehen

Was ist Velocity?

Definition Velocity: Velocity ist die durchschnittliche Menge an Arbeit, die ein Entwicklungsteam pro Sprint abschließt – üblicherweise in Story Points oder Stunden gemessen.

Grundbegriffe:

Story Points:

• Relatives Maß für Komplexität und Aufwand
• Keine Zeitschätzungen (bewusst abstrakt)
• Team-spezifische Kalibrierung
• Typisch Fibonacci-Folge (1, 2, 3, 5, 8, 13, 21)

Velocity:

• Durchschnittliche erledigte Story Points pro Sprint
• Basiert auf den letzten 3–5 Sprints für Genauigkeit
• Team-spezifisch (nicht zwischen Teams vergleichbar)
• Verbessert sich bei stabiler Teamzusammensetzung

Kapazität:

• Verfügbare Arbeitsstunden pro Sprint
• Berücksichtigt Meetings, Overhead, Puffer
• Dient zur Absicherung von Velocity-Commitments
• Hilft bei Überlastung zu erkennen

Die Velocity-Formel

Einfache Velocity-Berechnung:

Velocity = Summe der in den letzten N Sprints erledigten Story Points ÷ N

Beispiel:
Sprint 1: 42 Punkte
Sprint 2: 38 Punkte
Sprint 3: 45 Punkte
Sprint 4: 40 Punkte
Sprint 5: 43 Punkte

Velocity = (42 + 38 + 45 + 40 + 43) ÷ 5 = 41,6 Punkte/Sprint

Kapazitätsberechnung:

Brutto-Kapazität = Teamgröße × Sprint-Tage × Stunden/Tag
Netto-Kapazität = Brutto-Kapazität − Meetings − Admin − Puffer

Beispiel (5 Personen, 10-Tage-Sprint):
Brutto = 5 Entwickler × 10 Tage × 8 h = 400 Stunden
Meetings = 5 Devs × 10 Tage × 1,5 h = 75 Stunden  
Admin-Overhead = 10 % × 400 = 40 Stunden
Puffer (20 %) = 80 Stunden
Netto-Kapazität = 400 − 75 − 40 − 80 = 205 Stunden

Umrechnung Story Points in Stunden:

Stunden pro Punkt = Erfasste Gesamtstunden ÷ Erledigte Story Points

Beispiel vom letzten Sprint:
Erfasste Zeit: 210 Stunden
Erledigte Story Points: 42 Punkte
Stunden/Punkt = 210 ÷ 42 = 5 Stunden/Punkt

Für den nächsten Sprint:
Netto-Kapazität: 205 Stunden
Commitment = 205 ÷ 5 = 41 Story Points

Team-Kapazität berechnen

Der Kapazitätsplanungs-Rahmen

Schritt 1: Brutto-Kapazität berechnen

Das theoretische Maximum, wenn alle 100 % der Zeit arbeiten:

Brutto-Kapazität = Teamgröße × Sprint-Tage × Stunden pro Tag

Beispiele:
3 Personen, 2-Wochen-Sprint (10 Tage), 8-Stunden-Tage:
= 3 × 10 × 8 = 240 Stunden

5 Personen, 2-Wochen-Sprint (10 Tage), 8-Stunden-Tage:
= 5 × 10 × 8 = 400 Stunden

8 Personen, 3-Wochen-Sprint (15 Tage), 7-Stunden-Tage:
= 8 × 15 × 7 = 840 Stunden

Schritt 2: Meeting-Zeit abziehen

Alle Team-Ceremonies einplanen:

Typische Meeting-Zeit pro Sprint:

• Daily Standup: 15 Min/Tag × Sprint-Tage = 2,5 h (10-Tage-Sprint)
• Sprint-Planung: 2 Stunden
• Sprint-Review/Demo: 1 Stunde
• Retrospektive: 1 Stunde
• Refinement/Grooming: 2 Stunden
• Summe: ca. 8,5 Stunden pro Entwickler und Sprint

Bei 10-Tage-Sprint, 5 Entwickler:

Meeting-Zeit = 8,5 h × 5 Entwickler = 42,5 Stunden

Schritt 3: Administrativen Overhead abziehen

Nicht-Entwicklungsarbeit berücksichtigen:

Typischer Admin-Overhead:

• Code-Reviews: 5–10 % der Kapazität
• E-Mails und Slack: 5–10 % der Kapazität
• Teamkoordination: 2–5 % der Kapazität
• Dokumentation: 2–5 % der Kapazität
• Summe: 15–25 % der Brutto-Kapazität

Bei 400 h Brutto-Kapazität:

Admin-Overhead = 20 % × 400 = 80 Stunden

Schritt 4: Puffer für Unvorhergesehenes

Production-Vorfälle, dringende Bugs, Scope-Änderungen einplanen:

Typischer Puffer:

• Reifes Produkt: 10–15 %
• Wachsendes Produkt: 15–20 %
• Frühphase: 20–30 %

Bei etabliertem Produkt:

Puffer = 15 % × 400 = 60 Stunden

Schritt 5: Netto-Kapazität berechnen

Netto-Kapazität = Brutto − Meetings − Admin − Puffer
Netto = 400 − 42,5 − 80 − 60 = 217,5 Stunden

Das ist Ihre realistische Sprint-Kapazität.

Team-Varianten berücksichtigen

Teilzeit-Mitarbeiter:

Entwickler mit 50 % Kapazität:
Beitrag = 0,5 × (Sprint-Tage × Stunden/Tag)
= 0,5 × (10 × 8) = 40 Stunden Brutto-Kapazität

Urlaub und Abwesenheit:

Entwickler mit 3 Tagen Urlaub in 10-Tage-Sprint:
Verfügbare Tage = 10 − 3 = 7 Tage
Beitrag = 7 × 8 = 56 Stunden Brutto-Kapazität

Neue Teammitglieder:

Erster Sprint: 25–50 % Produktivität (Onboarding)
Zweiter Sprint: 50–75 % Produktivität
Dritter Sprint: 75–90 % Produktivität
Vierter Sprint: ca. 100 % Produktivität

Neuer Entwickler im ersten Sprint:
Beitrag = 0,4 × (10 × 8) = 32 Stunden Brutto-Kapazität

Verschiedene Erfahrungsstufen:

Senior: Faktor 1,2 (schneller, weniger Blocker)
Mid-Level: 1,0 (Referenz)
Junior: Faktor 0,7 (Einarbeitung, braucht Review)

Effektive Kapazität:
2 Seniors: 2 × 1,2 × 80 = 192 Stunden
2 Mid-Level: 2 × 1,0 × 80 = 160 Stunden
1 Junior: 1 × 0,7 × 80 = 56 Stunden
Summe: 408 Stunden Brutto (bei 5 × 80 = 400)

Story-Point-Schätzung: Leitfaden

Was sind Story Points?

Story Points sind NICHT:

• ❌ Stunden oder Tage
• ❌ Kalenderzeit
• ❌ Nur Komplexität
• ❌ Zwischen Teams vergleichbar

Story Points SIND:

• ✅ Relative Aufwandsschätzungen
• ✅ Mix aus Komplexität, Aufwand und Unsicherheit
• ✅ Team-spezifisch kalibriert
• ✅ Instrument für Planung und Prognose

Die Fibonacci-Skala

Warum Fibonacci? (1, 2, 3, 5, 8, 13, 21, 34)

Die wachsenden Abstände spiegeln wachsende Unsicherheit bei größeren Schätzungen wider:

1 Punkt – Trivial

• Einfache Config-Änderung
• Einzeiliger Bugfix
• Textanpassung
• ca. 1 Stunde Arbeit

2 Punkte – Einfach

• Kleine UI-Änderung
• Einfache Formularvalidierung
• Einfacher API-Endpoint
• ca. 2–3 Stunden Arbeit

3 Punkte – Mittel

• Neue Seite mit bestehenden Komponenten
• Datenbankabfrage optimieren
• Mehrstufiges Formular
• ca. 4–6 Stunden Arbeit

5 Punkte – Komplex

• Neues Feature mit mehreren Komponenten
• Komplexe Business-Logik
• Datenbankschema-Änderung
• ca. 8–12 Stunden Arbeit

8 Punkte – Sehr komplex

• Mehrseitiges Feature
• Anbindung externer Dienste
• Größeres Refactoring
• ca. 15–20 Stunden Arbeit

13 Punkte – Sehr hohe Komplexität

• Großes Feature über mehrere Bereiche
• Neue Architekturkomponente
• Komplexe Integration
• ca. 25–35 Stunden Arbeit

21+ Punkte – Epic

• Zu groß – sollte zerlegt werden
• Arbeit über mehrere Sprints
• Sollte in kleinere Stories aufgeteilt werden

Schätz-Best-Practices

1. Referenz-Stories nutzen

• 3–5 „Kalibrier-Stories“ mit verschiedenen Punktwerten festlegen
• z. B. „3 Punkte ist wie beim Export-Feature“
• Neue Stories an Referenz-Stories anlegen

2. Planning Poker

• Das Team schätzt gemeinsam
• Alle zeigen ihre Schätzung gleichzeitig (Ankereffekt vermeiden)
• Abweichungen besprechen
• Auf gemeinsame Schätzung einigen

3. Alle Faktoren einbeziehen

• Komplexität – Wie anspruchsvoll ist der Code?
• Aufwand – Wie viel Arbeit ist nötig?
• Unsichereit – Wie gut verstehen wir die Anforderung?
• Abhängigkeiten – Was muss vorher passieren?

4. Im Zweifel höher schätzen

• Größere Schätzung enthält Puffer
• Besser über- als unterliefern
• Unsicherheit erhöht die Schätzung

5. Ist-Zeit erfassen

• Story Points mit erfassten Stunden vergleichen
• Stunden-pro-Punkt-Verhältnis des Teams berechnen
• Daten für bessere künftige Schätzungen nutzen

Velocity-Tracking und Trends

Sprint-Velocity erfassen

Was erfassen:

Nach jedem Sprint notieren:

• Geplante Story Points – was geplant war
• Erledigte Story Points – was fertig wurde
• Erledigungsquote – Erledigt ÷ Geplant
• Erfasste Gesamtstunden – tatsächlich investierte Zeit
• Stunden pro Punkt – Stunden ÷ erledigte Punkte
• Teamgröße – FTE im Sprint
• Wichtige Ereignisse – Feiertage, Production-Vorfälle, Teamänderungen

Beispiel-Sprint-Eintrag:

Sprint 12 (10.–21. Jan. 2025):
- Geplant: 42 Punkte
- Erledigt: 38 Punkte
- Erledigung: 90 %
- Erfasste Stunden: 195
- Stunden/Punkt: 5,1
- Team: 4,5 FTE (1 Person 50 % im Support)
- Ereignisse: 2 Feiertage, kleiner Production-Vorfall (4 h)

Gleitende Velocity berechnen

Warum gleitender Durchschnitt?

• Glättet Sprint-zu-Sprint-Schwankungen
• Aussagekräftiger als ein einzelner Sprint
• Zeigt das nachhaltige Tempo des Teams

3-Sprint-Durchschnitt:

Sprint 10: 35 Punkte
Sprint 11: 42 Punkte
Sprint 12: 38 Punkte

Velocity = (35 + 42 + 38) ÷ 3 = 38,3 Punkte/Sprint

5-Sprint-Durchschnitt (empfohlen):

Sprint 8: 40 Punkte
Sprint 9: 38 Punkte
Sprint 10: 35 Punkte
Sprint 11: 42 Punkte
Sprint 12: 38 Punkte

Velocity = (40 + 38 + 35 + 42 + 38) ÷ 5 = 38,6 Punkte/Sprint

Velocity-Trends und Muster

Aufwärtstrend (Verbesserung):

Sprint 1: 30 Punkte
Sprint 2: 34 Punkte
Sprint 3: 37 Punkte
Sprint 4: 40 Punkte
Sprint 5: 42 Punkte

Trend: +3 Punkte/Sprint

Ursachen:
✅ Team gewinnt Codebase-Erfahrung
✅ Bessere Schätzgenauigkeit
✅ Verbesserte Entwicklungsprozesse
✅ Weniger technische Schulden

Abwärtstrend (Rückgang):

Sprint 1: 45 Punkte
Sprint 2: 42 Punkte
Sprint 3: 38 Punkte
Sprint 4: 35 Punkte
Sprint 5: 32 Punkte

Trend: −3,25 Punkte/Sprint

Mögliche Ursachen:
❌ Technische Schulden bremsen Entwicklung
❌ Steigende Code-Komplexität
❌ Überlastung oder Stimmung im Team
❌ Mehr Production-Support
❌ Verlust erfahrener Teammitglieder

Volatil (instabil):

Sprint 1: 40 Punkte
Sprint 2: 28 Punkte
Sprint 3: 45 Punkte
Sprint 4: 30 Punkte
Sprint 5: 43 Punkte

Varianz: ±15 Punkte

Ursachen:
❌ Uneinheitliche Schätzung
❌ Unvorhersehbare Scope-Änderungen
❌ Production-Notfälle
❌ Wechselnde Teamverfügbarkeit
❌ Schwache Sprint-Planung

Stabil (vorhersehbar):

Sprint 1: 38 Punkte
Sprint 2: 40 Punkte
Sprint 3: 39 Punkte
Sprint 4: 41 Punkte
Sprint 5: 38 Punkte

Durchschnitt: 39,2 Punkte, Varianz: ±2 Punkte

Zeichen eines gesunden Teams:
✅ Stabile Teamzusammensetzung
✅ Gute Schätzpraxis
✅ Vorhersehbarer Sprint-Umfang
✅ Effektive Sprint-Planung
✅ Wenige Production-Notfälle

Branchen-Benchmarks und Vergleiche

Velocity-Benchmarks nach Teamgröße

Kleines Team (2–3 Entwickler):

• Typische Velocity: 20–35 Punkte/Sprint
• Stunden pro Punkt: 4–6 Stunden
• Sprint-Kapazität: 80–140 Netto-Stunden

Mittleres Team (4–6 Entwickler):

• Typische Velocity: 35–60 Punkte/Sprint
• Stunden pro Punkt: 4–5 Stunden
• Sprint-Kapazität: 140–260 Netto-Stunden

Großes Team (7–10 Entwickler):

• Typische Velocity: 60–100 Punkte/Sprint
• Stunden pro Punkt: 5–7 Stunden (Koordinations-Overhead)
• Sprint-Kapazität: 280–520 Netto-Stunden

Hinweis: Das sind grobe Orientierungswerte. Die Velocity Ihres Teams ist einzigartig und von vielen Faktoren abhängig.

Velocity nach Erfahrungsstufe

Junior-Team (< 1 Jahr Erfahrung):

• Zunächst niedrigere Velocity
• Verbesserungstrend zu erwarten
• Mehr Stunden pro Punkt (Lernphase)
• Höhere Schätzvarianz

Mid-Level-Team (1–3 Jahre Erfahrung):

• Stabile Velocity
• Gute Schätzgenauigkeit
• Übliche Stunden pro Punkt
• Gleichmäßige Lieferung

Senior-Team (3+ Jahre Erfahrung):

• Hohe Velocity
• Sehr gute Schätzungen
• Weniger Stunden pro Punkt
• Sehr gleichmäßige Lieferung

Erledigungsquoten – Benchmarks

Gesunde Erledigungsquoten:

• 90–110 % – Sehr gut (nahe am Commitment)
• 80–90 % – Gut (leicht unter dem Commitment)
• 110–120 % – Übererfüllung (evtl. Unter-Schätzung)

Warnsignale:

• < 75 % – Dauerhaftes Über-Commitment oder schlechte Schätzung
• > 125 % – Deutliches Unter-Commitment oder aufgeblähte Schätzungen

Velocity für die Sprint-Planung nutzen

Der velocity-basierte Planungsprozess

Schritt 1: Aktuelle Velocity berechnen

Letzte 5 Sprints: 38, 42, 40, 39, 41 Punkte
Aktuelle Velocity = (38 + 42 + 40 + 39 + 41) ÷ 5 = 40 Punkte

Schritt 2: Bekannte Faktoren einrechnen

Basis-Velocity: 40 Punkte

Anpassungen:
- Teammitglied im Urlaub: −10 %
- Feiertag im Sprint: −5 %
- Neues Teammitglied: +5 % (Einarbeitung)

Angepasste Velocity = 40 × (1 − 0,10 − 0,05 + 0,05) = 36 Punkte

Schritt 3: Mit Kapazität abgleichen

Netto-Kapazität diesen Sprint: 200 Stunden
Stunden pro Punkt (historisch): 5 Stunden/Punkt
Kapazitätsbasiertes Commitment = 200 ÷ 5 = 40 Punkte

Velocity-basiert: 36 Punkte
Kapazitätsbasiert: 40 Punkte

Konservatives Commitment: 36 Punkte (niedrigeren Wert nehmen)

Schritt 4: Stories auswählen

• Mit den höchsten Prioritäten starten
• Stories hinzufügen bis Ziel (36 Punkte) erreicht
• Mischung aus Größen für Flexibilität
• Kleinen Puffer für Scope-Änderungen lassen

Schritt 5: Mit dem Team validieren

• Wirkt das erreichbar?
• Bedenken zu einzelnen Stories?
• Technische Abhängigkeiten geklärt?
• Team steht zum Commitment

Planung bei Unsicherheit

Konfidenzniveaus:

Hohe Konfidenz (80–90 % sicher):

• Volles Velocity-Commitment
• Gut verstandene Stories
• Stabiles Team
• Keine großen Unbekannten

Mittlere Konfidenz (70–80 % sicher):

• 90 % der Velocity committen
• Etwas Unsicherheit bei Stories
• Teamänderungen
• Geringe Abhängigkeiten

Niedrige Konfidenz (60–70 % sicher):

• 75–80 % der Velocity committen
• Deutliche Unbekannte
• Neue Technologie oder Domäne
• Viele Abhängigkeiten

Beispiel:

Basis-Velocity: 40 Punkte
Konfidenz: Mittel (neues Feature-Gebiet)

Konservatives Commitment = 40 × 0,9 = 36 Punkte

Praxisbeispiele

Beispiel 1: Startup-Dev-Team

Team-Profil:

• 3 Entwickler (1 Senior, 2 Mid-Level)
• 2-Wochen-Sprints (10 Arbeitstage)
• Aufbau eines neuen SaaS-Produkts
• Deutliche Velocity-Steigerung erwartet

Kapazitätsberechnung:

Brutto-Kapazität = 3 Devs × 10 Tage × 8 h = 240 Stunden
Meetings = 3 × 8 h = 24 Stunden
Admin (20 %) = 48 Stunden
Puffer (25 % – Frühphase) = 60 Stunden
Netto-Kapazität = 240 − 24 − 48 − 60 = 108 Stunden

Velocity-Tracking:

Sprint 1: 18 Punkte (5 h/Punkt = 90 Stunden)
Sprint 2: 22 Punkte (4,8 h/Punkt = 106 Stunden)
Sprint 3: 25 Punkte (4,5 h/Punkt = 113 Stunden)
Sprint 4: 28 Punkte (4,2 h/Punkt = 118 Stunden)
Sprint 5: 30 Punkte (4 h/Punkt = 120 Stunden)

Aktuelle Velocity: 24,6 Punkte/Sprint
Trend: +3 Punkte/Sprint
Nächstes Sprint-Commitment: 32 Punkte

Auswertung: ✅ Gesunder Aufwärtstrend (Team lernt Codebase)
✅ Sinkende Stunden/Punkt (steigende Effizienz)
✅ Konservativer Puffer passend für Frühphase
✅ Commitment kann mit Trend angehoben werden

Beispiel 2: Agentur-Dev-Team

Team-Profil:

• 6 Entwickler (Kundenprojekte und Support)
• 2-Wochen-Sprints
• Mix aus Kundenarbeit und internen Tools
• Puffer für Kunden-Notfälle nötig

Kapazitätsberechnung:

Brutto-Kapazität = 6 Devs × 10 Tage × 7,5 h = 450 Stunden
Meetings = 6 × 10 h = 60 Stunden
Kunden-Support (Durchschnitt) = 60 Stunden
Admin (15 %) = 68 Stunden
Puffer (15 %) = 68 Stunden
Netto-Kapazität = 450 − 60 − 60 − 68 − 68 = 194 Stunden

Velocity-Tracking:

Sprint 1: 38 Punkte (198 h erfasst)
Sprint 2: 35 Punkte (175 h – Feiertag)
Sprint 3: 40 Punkte (205 h)
Sprint 4: 32 Punkte (160 h – Production-Vorfall)
Sprint 5: 39 Punkte (195 h)

Aktuelle Velocity: 36,8 Punkte/Sprint
Anpassung diesen Sprint:
- 1 Entwickler 50 % (Kunden-Eskalation) = −10 %
- Keine Feiertage = 0 %

Nächstes Sprint-Commitment: 36,8 × 0,9 = 33 Punkte

Auswertung: ✅ Velocity-Schwankung entspricht Agentur-Realität
✅ Support-Puffer verhindert Über-Commitment
✅ Anpassungen für bekannte Einschränkungen
✅ Konservative Planung schont Kundenbeziehungen

Beispiel 3: Enterprise-Produktteam

Team-Profil:

• 8 Entwickler (reifes Produktteam)
• 3-Wochen-Sprints
• Etabliertes Produkt mit Tech Debt
• Sehr stabile Teamzusammensetzung

Kapazitätsberechnung:

Brutto-Kapazität = 8 Devs × 15 Tage × 8 h = 960 Stunden
Meetings = 8 × 12 h = 96 Stunden
Code-Review (10 %) = 96 Stunden
Admin (12 %) = 115 Stunden
Puffer (12 %) = 115 Stunden
Netto-Kapazität = 960 − 96 − 96 − 115 − 115 = 538 Stunden

Velocity-Tracking:

Sprint 1: 85 Punkte (545 h)
Sprint 2: 83 Punkte (532 h)
Sprint 3: 88 Punkte (555 h)
Sprint 4: 84 Punkte (538 h)
Sprint 5: 86 Punkte (548 h)

Aktuelle Velocity: 85,2 Punkte/Sprint
Stunden/Punkt: 6,35 h (Reife + Tech Debt)
Varianz: ±2,5 Punkte (sehr stabil)

Nächstes Sprint-Commitment: 85 Punkte

Auswertung: ✅ Hohe Stabilität spricht für reifes Team
✅ Etwas mehr Stunden/Punkt durch Code-Komplexität
✅ Vorhersehbare Lieferung ermöglicht Langfristplanung
✅ Kleiner Puffer bei geringer Unsicherheit

Typische Velocity-Fehler

Fehler 1: Velocity zwischen Teams vergleichen

Problem: „Team A hat 50 Punkte Velocity, Team B 30. Team A ist produktiver!“

Warum das falsch ist:

• Story Points sind team-spezifisch kalibriert
• „5 Punkte“ bei Team A ≠ „5 Punkte“ bei Team B
• Verschiedene Domänen, verschiedene Komplexität
• Teamgröße, Erfahrung, Tech-Stack unterscheiden sich

Stattdessen:

• Velocity pro Team getrennt tracken
• Trends innerhalb desselben Teams über Zeit vergleichen
• Falls nötig Stunden-pro-Punkt zum Vergleich nutzen
• Auf gelieferten Mehrwert fokussieren, nicht auf Velocity-Zahlen

Fehler 2: Velocity als Leistungskennzahl nutzen

Problem: „Eure Velocity ist diesen Sprint gesunken – ihr müsst schneller arbeiten!“

Warum das falsch ist:

• Velocity dient der Planung, nicht der Leistungsbewertung
• Als Leistungsmaß verleitet sie zum Gaming (aufgeblähte Schätzungen)
• Natürliche Schwankung ist normal
• Komplexitätsunterschiede zwischen Sprints werden ignoriert

Stattdessen:

• Velocity nur für Kapazitätsplanung nutzen
• Teams an Ergebnissen und geliefertem Wert messen
• Trends untersuchen, nicht Einzel-Sprints
• Vertrauen aufbauen, niedrige Velocity nicht bestrafen

Fehler 3: Druck auf höhere Velocity ausüben

Problem: „Dieses Sprint committen wir 50 Punkte – das schaffen wir!“

Warum das falsch ist:

• Führt zu Über-Commitment und Überlastung
• Verleitet zu Abkürzungen (Qualität leidet)
• Schätzungen werden aufgebläht, um gut dazustehen
• Velocity verliert als Planungsinstrument ihren Nutzen

Stattdessen:

• Velocity akzeptieren wie sie ist
• Auf nachhaltiges Tempo achten
• Prozesse verbessern, damit Velocity natürlich steigt
• Gleichmäßige Lieferung feiern, nicht hohe Zahlen

Fehler 4: Kapazitätsgrenzen ignorieren

Problem: „Unsere Velocity ist 40 Punkte, also committen wir 40 – obwohl die Hälfte des Teams im Urlaub ist.“

Warum das falsch ist:

• Velocity setzt stabile Teamzusammensetzung voraus
• Ändernde Umstände werden nicht berücksichtigt
• Führt zu verfehlten Sprint-Commitments
• Untergräbt das Vertrauen der Stakeholder

Stattdessen:

• Velocity an bekannte Einschränkungen anpassen
• Kapazität separat berechnen
• Sowohl Velocity als auch Kapazität für die Planung nutzen
• Einschränkungen offen kommunizieren

Fehler 5: Velocity nicht lange genug tracken

Problem: „Wir haben 2 Sprints gemacht – unsere Velocity ist 35 Punkte!“

Warum das falsch ist:

• Zu kleine Stichprobe
• Natürliche Schwankung noch nicht geglättet
• Team kalibriert Schätzungen noch
• Noch nicht aussagekräftig

Stattdessen:

• Mindestens 5 Sprints tracken, bevor Sie sich auf Velocity verlassen
• Anfangs größeren Puffer einplanen
• Mit Verbesserung der Velocity rechnen, wenn das Team reifer wird
• Dem Prozess Zeit geben

Vorlagen zum Herunterladen

Sprint-Velocity-Tracker (Tabellenkalkulation)

Zu erfassende Spalten:

• Sprint-Nr. & Datum
• Geplante Punkte
• Erledigte Punkte
• Erledigungsquote %
• Erfasste Stunden
• Stunden pro Punkt
• Team FTE
• Wichtige Ereignisse/Notizen
• 3-Sprint-Gleitender Durchschnitt
• 5-Sprint-Gleitender Durchschnitt

Formeln:

Erledigung % = (Erledigte Punkte / Geplante Punkte) × 100
Stunden pro Punkt = Erfasste Stunden / Erledigte Punkte
3-Sprint-Durchschn. = AVERAGE(letzte 3 Sprints)
5-Sprint-Durchschn. = AVERAGE(letzte 5 Sprints)

Kapazitätsplanungs-Vorlage

Pro Sprint berechnen:

1. Teamzusammensetzung

   • Namen der Entwickler
   • Verfügbarkeit % (Urlaub etc.)
   • Faktor Erfahrungsstufe

2. Zeitberechnungen

   • Brutto-Kapazität pro Entwickler
   • Brutto-Kapazität gesamt
   • Abzug Meeting-Zeit
   • Abzug Admin-Overhead
   • Puffer
   • Netto-Kapazität

3. Commitment

   • Aktuelle Velocity
   • Anpassungen diesen Sprint
   • Kapazitätsbasiertes Maximum
   • Empfohlenes Commitment

Story-Point-Referenzkarte

Kalibrierung für Ihr Team:

Integration mit Corcava

Velocity-Tracking mit Corcava

1. Sprint-Board einrichten

• Boards pro Sprint anlegen
• Spalten für Workflow-Phasen nutzen
• Story-Point-Schätzungen im Aufgabenfeld „Betrag“ eintragen
• Zeit pro Aufgabe erfassen

2. Zeiterfassungs-Integration

• Automatische Zeiterfassung auf Aufgaben
• Echtzeit-Berechnung Stunden pro Story Point
• Zeitberichte nach Sprint/Board gefiltert

3. Sprint-Berichte

• Projekt-Performance-Berichte
• Zeit- und Aufgaben-Analysen
• Velocity-Trends über die Zeit
• Team-Performance-Metriken

4. Sprint-Planungs-Workflow

• Letzte 5 Sprints in Zeitberichten prüfen
• Velocity aus erledigten Aufgaben berechnen
• Neues Sprint-Board anlegen
• Aufgaben bis zum Velocity-Ziel hinzufügen
• Team startet Zeiterfassung für den neuen Sprint

5. Kontinuierliche Verbesserung

• Zeitdaten für Analysen exportieren
• Schätzungen mit Ist-Zeit vergleichen
• Muster bei Über-/Unterschätzung erkennen
• Story-Point-Kalibrierung verfeinern

Einstieg ins Velocity-Tracking

Woche 1: Basis schaffen

Maßnahmen:

• Sprint-Board-Struktur einrichten
• Team in Story-Point-Schätzung schulen
• Referenz-Stories zur Kalibrierung anlegen
• Ersten Sprint erfassen
• Alle Zeit auf Aufgaben erfassen

Ergebnisse:

• Sprint-Board mit geschätzten Aufgaben
• Einigung im Team auf Story-Point-Skala
• Zeiterfassung gestartet

Woche 2–10: Daten sammeln

Maßnahmen:

• 5 Sprints durchführen (2-Wochen-Sprints = 10 Wochen)
• Nach jedem Sprint Velocity notieren
• Stunden pro Story Point erfassen
• Wichtige Ereignisse oder Ausreißer vermerken
• Schätzweise vorerst beibehalten

Ergebnisse:

• 5 Sprint-Velocity-Einträge
• Stunden-pro-Punkt-Verhältnis
• Erste Trends erkennbar

Ab Woche 11: Daten für die Planung nutzen

Maßnahmen:

• Gleitenden 5-Sprint-Velocity berechnen
• Velocity für die nächste Sprint-Planung nutzen
• Commitment mit Kapazität vergleichen
• Erledigungsquote tracken
• Schätzung bei Bedarf verfeinern

Ergebnisse:

• Velocity-basierte Sprint-Planung
• Bessere Schätzgenauigkeit
• Vorhersehbare Lieferung

Fazit: datengetriebene Sprint-Planung

Schluss mit Raten bei der Sprint-Kapazität. Planen Sie mit echten Daten.

Das haben Sie gelernt:

✅ Team-Kapazität berechnen – Meetings, Overhead und Puffer einrechnen
✅ Velocity tracken – Gleitender Durchschnitt der letzten 5 Sprints
✅ Mit Story Points schätzen – Relatives Sizing, nicht Stunden
✅ Realistische Sprints planen – Velocity und Kapazität nutzen
✅ Trends beobachten – Verbesserungen oder Probleme früh erkennen
✅ Typische Fehler vermeiden – Teams nicht vergleichen, keinen Druck auf höhere Velocity

Das Ergebnis:

• Vorhersehbare Sprint-Lieferung
• Stakeholder-Vertrauen in Commitments
• Nachhaltiges Team-Tempo
• Daten für kontinuierliche Verbesserung
• Bessere Langfristplanung

Bereit, Velocity zu tracken?

Mit der integrierten Zeiterfassung und dem Projektmanagement von Corcava berechnen Sie automatisch die Velocity Ihres Teams, verfolgen Trends und planen realistische Sprints.

Nächste Schritte:

1. Erstes Sprint-Board anlegen – in Corcava
2. Mit Story Points schätzen – Fibonacci-Skala nutzen
3. Zeit auf allen Aufgaben erfassen – automatisch oder manuell
4. Sprint-Ergebnisse festhalten – nach jedem Sprint
5. Velocity berechnen – nach 5 Sprints Daten für die Planung nutzen

Sprint-Planung von Bauchgefühl zu Daten: Ihr Team, Ihre Stakeholder und Ihre Nerven werden es Ihnen danken.

Weitere Ressourcen:

• Sprint-Planung in Corcava
• Automatische vs. manuelle Zeiterfassung
• Projektmanagement-Dokumentation
• Zeiterfassung & Berichte
• Team-Performance-Analysen

Bereit zum Start?Jetzt bei Corcava registrieren und die Engineering-Velocity Ihres Teams tracken.