Die Velocity-Falle

Wenn drei Junioren weniger leisten als ein Senior

„Wir brauchen mehr Entwickler, um unsere Deadline zu halten!“ Dieser Satz fällt in Planungsrunden regelmäßig. Die vermeintlich einfache Lösung lautet, drei Junioren einzustellen statt einen teuren Senior. Auf dem Papier wirkt die Rechnung überzeugend: Drei Junioren kosten oft zusammen nur unwesentlich mehr als ein Senior und bringen theoretisch die dreifache Zahl an Arbeitsstunden.

Doch diese Logik trügt. Praxiserfahrungen zeigen, dass Junioren nur etwa 60 Prozent der Produktivität eines Seniors erreichen und dass die versteckten Kosten für Koordination, Mentoring und Qualität die vermeintlichen Einsparungen schnell übersteigen. Das Ergebnis sind überlastete Teams, verzögerte Projekte und frustrierte Stakeholder. Das eigentliche Problem liegt in einer vereinfachten Velocity-Mathematik. Sie betrachtet Kapazitäten nur oberflächig, ohne die komplexen Abhängigkeiten moderner Softwareentwicklung einzubeziehen.

Das Problem: Vereinfachte Velocity-Mathematik führt zu kostspieligen Fehlentscheidungen

Zwei Faktoren stehen im Zentrum vieler Fehlplanungen: die trügerische Einfachheit von Story Points und ein oft übersehener Produktivitätsverlust.

Story Points sind in agilen Teams ein gängiges Maß für Aufwand und Produktivität. Doch sie sind alles andere als objektiv. Ein Senior-Entwickler bewertet eine Aufgabe vielleicht mit zwei Story Points, während ein Junior dieselbe Aufgabe mit fünf Punkten einschätzt. Dieser Unterschied ist kein Zufall, sondern Ausdruck fundamentaler Unterschiede in Erfahrung, Routine und Problemlösungskompetenz. Wer Story Points als rein mathematische Größe betrachtet, blendet diese Unterschiede aus und erzeugt falsche Erwartungen an die Teamleistung.

Noch gravierender wirkt sich der versteckte Produktivitätsverlust aus. Studien zeigen, dass 55 Prozent der Teams pro Entwickler zwischen fünf und fünfzehn Stunden pro Woche in unproduktive Arbeit investieren. [1] Besonders Junioren sind davon betroffen: Sie benötigen deutlich mehr Zeit für Code-Reviews, verlaufen sich häufiger in technischen Sackgassen, verbringen längere Zyklen mit Debugging und brauchen zusätzliche Unterstützung bei Architekturentscheidungen. Was auf dem Papier nach voller Kapazität aussieht, schrumpft in der Realität erheblich zusammen.

Ein Blick auf die tatsächlichen Velocity-Zahlen bestätigt dieses Bild. Junioren mit bis zu zwei Jahren Erfahrung erreichen bei Standardaufgaben nur rund 60 Prozent der Produktivität eines Seniors und fallen bei komplexen Architekturthemen sogar auf 30 bis 40 Prozent zurück. Mid-Level-Entwickler mit drei bis fünf Jahren Erfahrung liegen bei etwa 80 Prozent, können einen Großteil der Aufgaben eigenständig lösen und entlasten damit die Seniors. Erst Senior-Entwickler selbst bilden die Basis mit voller Produktivität, treffen tragfähige Architekturentscheidungen und wirken als Multiplikatoren für das gesamte Team.

Praxisbeispiel: Das Startup, das fast an der Velocity-Falle scheiterte

Die TechFlow GmbH, ein junges FinTech-Startup, stand vor einer entscheidenden Projektdeadline. Auf den ersten Blick schien die Lösung einfach: Statt einen weiteren Senior-Entwickler für 85.000 Euro einzustellen, entschied man sich für drei Junioren zu je 45.000 Euro. Auf dem Papier versprach diese Entscheidung 120 Entwicklerstunden pro Woche statt 40 und damit eine zusätzlichen Kapazitätszuwachs von 200 Prozent.

Die Realität nach sechs Monaten zeigte ein anderes Bild.

Geplante vs. tatsächliche Velocity

• Geplant: 45 Story Points pro Sprint (3 Junioren à 15 Points)
• Tatsächlich: 22 Story Points pro Sprint
• Vergleich: Ein Senior hätte voraussichtlich 28 bis 32 Story Points erreicht

Versteckte Kosten

• Mentoring-Overhead: Der vorhandene Senior verbrachte 40 Prozent seiner Zeit mit Code-Reviews und Architekturfragen
• Qualitätsprobleme: 35 Prozent mehr Bugs in der Produktion
• Rework-Zyklen: Im Schnitt 2,3 Iterationen pro Feature statt 1,2
• Kommunikationsaufwand: Tägliche Standups dauerten 50 Prozent länger

Nach einem halben Jahr zog TechFlow die Notbremse. Zwei Junioren verließen das Team, stattdessen wurde ein weiterer Senior eingestellt. Schon nach drei Sprints zeigte sich die Wirkung: Die Velocity stieg um 68 Prozent, die Bug-Rate sank um 45 Prozent und die Time-to-Market verkürzte sich um drei Wochen. Die Überlegung, drei Junioren leisten mehr als ein Senior, entpuppte sich als Fehlannahme, die erst durch eine strategische Neuausrichtung korrigiert werden konnte.

Die echten Kosten der Velocity-Mathematik: Ein Rechenbeispiel

Auf den ersten Blick wirken drei Junioren verglichen mit einem Senior wie ein Gewinn. Doch erst eine realistische Berechnung zeigt, wie stark die Produktivität tatsächlich von Erfahrung, Koordination und Qualität beeinflusst wird.

Szenario A: Drei Junioren

• Basis-Produktivität: 3 × 15 Story Points × 0,6 = 27 Points
• Mentoring-Overhead: –6 Points (20 % Reduktion)
• Koordinationsverluste: –4 Points (15 % Reduktion)
• Rework-Zyklen: –5 Points (zusätzliche Iterationen)

= Netto-Velocity: 12 Points pro Sprint

Versteckte Kosten pro Jahr

• Verzögerte Markteinführung: ca. 200.000 €
• Zusätzliche QA-Zyklen: ca. 35.000 €
• Erhöhte Infrastrukturkosten: ca. 15.000 €

= Gesamte versteckte Kosten: rund 250.000 €

Szenario B: Ein Senior

• Basis-Produktivität: 30 Points
• Architektur-Bonus: +3 Points (bessere technische Entscheidungen)
• Weniger Rework: +2 Points (höhere Erstqualität)

= Netto-Velocity: 35 Points pro Sprint

Echter ROI-Vergleich

• Drei Junioren: 135.000 € + 250.000 € versteckte Kosten = 385.000 € für 12 Points pro Sprint
• Ein Senior: 85.000 € für 35 Points pro Sprint

Kosten pro Story Point

• Junioren-Team: 32.083 €
• Senior: 2.429 €

Das Ergebnis ist eindeutig: Drei Junioren liefern nicht nur weniger, sondern kosten in Summe ein Vielfaches.

Die richtige Velocity-Mathematik implementieren

Wie können Projektleiter und CTOs verhindern, dass sie in die Velocity-Falle tappen? Entscheidend ist, Kapazitäten realistisch zu bewerten und die Teamzusammensetzung strategisch zu gestalten. Hier bietet sich ein Vorgehen in fünf Schritten an:

1. Realistische Produktivitätsfaktoren einführen

Nicht jeder Entwickler arbeitet mit derselben Geschwindigkeit oder Qualität. In der Kapazitätsplanung sollten daher Korrekturfaktoren berücksichtigt werden.

Entwickler-Level-Multiplikatoren:

• Junior (0–2 Jahre): 0,6 × geplante Kapazität
• Mid-Level (3–5 Jahre): 0,8 × geplante Kapazität
• Senior (5+ Jahre): 1,0 × geplante Kapazität
• Lead (8+ Jahre): 1,2 × geplante Kapazität (Team-Multiplikator)

Koordinations-Overhead nach Teamgröße:

• 2–3 Personen: –5 % Velocity-Verlust
• 4–6 Personen: –10 %
• 7–9 Personen: –20 %
• 10+ Personen: –35 %

2. Die optimale Team-Zusammensetzung berechnen

Eine ausgewogene Mischung bringt mehr als einseitige Besetzungen. Die sogenannte „Pizza-Team“-Formel empfiehlt das Verhältnis von 1 Senior : 2 Mid-Level : 1 Junior.

Beispielrechnung:

• 1 Senior × 1,0 = 30 Points
• 2 Mid-Level × 0,8 = 48 Points
• 1 Junior × 0,6 = 15 Points
• Mentoring-Bonus: +10 % (Senior unterstützt effektiv)

= 102 Points brutto, abzüglich 5 % Koordinationsaufwand = 97 Points netto

3. Qualitäts-gewichtete Velocity einführen

Traditionelle Velocity blendet Qualitätsunterschiede aus. Eine gewichtete Metrik berücksichtigt Bug-Rate und Rework-Rate:

Formel:

Gewichtete Velocity = Story Points × (1 – Bug-Rate/100) × (1 – Rework-Rate/100)

Beispielrechnung:

• Junior-Team: 45 Points × (1 – 0,35) × (1 – 0,40) = 17,5 gewichtete Points
• Senior-Team: 30 Points × (1 – 0,12) × (1 – 0,15) = 22,4 gewichtete Points

4. Eine langfristige Wachstumsstrategie entwickeln

Ein Team ist kein statisches Gebilde, sondern wächst mit seinen Mitgliedern. Deshalb lohnt es sich, von Anfang an eine klare Entwicklungsstrategie zu verfolgen. In der ersten Phase („Foundation“) stehen der Aufbau eines starken Senior-Kerns, die Definition von Standards und Architektur sowie Mentoring-Programme im Vordergrund. In der zweiten Phase („Scaling“) kommen gezielt Mid-Level-Entwickler hinzu, während Junioren behutsam in Nischenbereichen eingearbeitet werden und kontinuierliche Weiterbildung etabliert wird. In der dritten Phase („Optimization“) entwickeln sich Junioren zu Mid-Level, Seniors übernehmen zunehmend Lead-Rollen und die Multiplikator-Effekte im Team werden voll ausgeschöpft. Auf diese Weise entsteht Schritt für Schritt ein nachhaltiges Kompetenz- und Produktivitätswachstum.

5. Mess- und Monitoring-Systeme implementieren

Planung und Teamaufbau allein reichen nicht, ohne transparente Messung bleibt der tatsächliche Fortschritt im Dunkeln. Ein Set sinnvoller Kennzahlen schafft Klarheit. Dazu gehören

• eine Adjusted Velocity, die Qualitätsfaktoren berücksichtigt,
• die Cycle Time als Maß für die Durchlaufzeit von der Entwicklung bis zum Release,
• die Defect Escape Rate als Indikator für Fehler, die in Produktion gelangen,
• sowie der Mentoring Coefficient, der den Anteil der Senior-Zeit für Team-Support sichtbar macht.
• Ergänzend lohnt es sich, auch die Technical Debt Velocity zu erfassen, also die Kapazität, die für die Reduzierung technischer Schulden eingeplant wird.

Wer diese Kennzahlen regelmäßig erhebt und im Team transparent macht, kann Engpässe frühzeitig erkennen und gezielt gegensteuern.

Fazit: Velocity-Exzellenz durch intelligente Team-Komposition

Die Berechnungen zeigen deutlich, dass die vermeintlich einfache Gleichung „mehr Köpfe = mehr Produktivität“ nicht aufgeht. Drei Junioren leisten nicht das, was ein Senior in derselben Zeit schafft. In der Praxis liegt das Verhältnis eher bei 0,4 zu 1. Hinzu kommen versteckte Kosten für Mentoring, Koordination und Rework, die die vermeintlichen Einsparungen schnell um ein Vielfaches übersteigen.

Nachhaltige Produktivität entsteht erst durch eine intelligente Team-Komposition. Gemischte Teams mit einem ausgewogenen Verhältnis von Senior-, Mid-Level- und Junior-Entwicklern erzielen eine höhere Netto-Velocity, eine bessere Qualität und damit eine deutlich höhere Wertschöpfung. Qualität multipliziert Geschwindigkeit, weil weniger Rework und weniger Bugs die Entwicklung stabilisieren und beschleunigen.

Tipp: Analysieren Sie die Zusammensetzung Ihrer Teams mit den vorgestellten Formeln und Kennzahlen. Berechnen Sie die tatsächlichen Kosten pro Story Point und identifizieren Sie, wo Potenzial für Verbesserungen liegt. Die Investition in die richtige Balance zwischen Senior-Expertise und Junior-Talent zahlt sich nicht nur in höherer Velocity aus, sondern schafft auch die Grundlage für langfristiges Wachstum.

Hinweise:

[1] Siehe bspw. appinio: Produktivität am Arbeitsplatz oder manage it: Je mehr Akademiker, desto unproduktiver? oder Personalwirtschaft: Zeitverschwendung bei der Arbeit

Möchten Sie wissen, wie produktiv Ihr aktuelles Setup ist? Gemeinsam mit Ihnen analysiert Merlin Mechler  Ihre Teamzusammensetzung und berechnet, an welchen Stellen sich Produktivität steigern und Kosten reduzieren lassen. Das Angebot ist kostenlos, praxisnah und liefert klare Ergebnisse. So erhalten Sie eine fundierte Entscheidungsgrundlage für Ihre nächsten Projekte. Hier können Sie einen Termin vereinbaren.

Hier finden Sie weitere Informationen über Story Points.

Und hier finden Sie weitere Informationen zur Velocity bzw. zur Developer Velocity.

Was halten Sie von dem vorgestellten Ansatz? Teilen Sie den Beitrag gerne in Ihrem Netzwerk und diskutieren Sie darüber. Und falls Sie sich für weitere Tipps aus der Praxis interessieren, dann abonnieren Sie unseren beliebten Newsletter.