Velocity und Burndown: Zahlen lesen ohne Selbstbetrug

Velocity misst nicht, was Sie glauben

Velocity addiert abgeschlossene Schätzpunkte über einen Sprint. Das ist alles. Sie misst weder den gelieferten Wert noch die tatsächliche Schwierigkeit noch die Qualität. Zwei Teams mit derselben Velocity können völlig zusammenhanglose Dinge produziert haben.

Der häufigste Fehler besteht darin, sie zum Ziel zu machen. Sobald eine Velocity zur Vorgabe wird, dient die Schätzung der Vorgabe: Man bläht Punkte auf, schneidet anders zu, schließt fragwürdige Karten. Die Zahl steigt, die Information verschwindet.

Ein konkretes Beispiel: Ein Team aus fünf Personen liegt seit sechs Sprints bei etwa 42 Punkten pro Sprint. Ein neuer Sprint wird mit 60 Punkten geplant, weil ein Führungskraft „braucht“, dass es schneller geht. Vorhersehbares Ergebnis: Karten, die hastig reviewt werden, und ein Folge-Sprint bei 30 Punkten. Die Velocity ist nicht gestiegen, sie wurde in der Zeit verschoben.

Drei vertretbare Verwendungen

• Den nächsten Sprint anhand des Durchschnitts der letzten drei dimensionieren, nicht des besten.
• Eine Drift erkennen: Eine Velocity, die über zwei Sprints um 40 % fällt, verdient ein Gespräch.
• Ein Team mit sich selbst über die Zeit vergleichen, niemals mit einem anderen Team.

Ein fallender Burndown beweist nichts über das Gelieferte

Der Burndown zeigt die verbleibende Arbeit Tag für Tag. Seine Steigung erzählt einen Verlauf, keine Qualität. Eine Kurve, die am Vorabend des Reviews abstürzt, kann ein echtes Tempo signalisieren … oder ein massenhaftes Schließen kaum geprüfter Karten.

Ein Artikel von 2026 über kognitive Schulden beschreibt genau dieses Phänomen: Ein Ingenieur, der sieben Funktionen in einem Sprint liefert, kann makellose Metriken vorweisen und sich sechs Monate später außerstande finden, seinen eigenen Code zu erklären. Der Autor spricht von einer Lücke zwischen Produktionsgeschwindigkeit und Verständnisgeschwindigkeit, unsichtbar in Velocity-Metriken, die sich schließlich in späteren Indikatoren wie der mittleren Wiederherstellungszeit oder der Änderungsfehlerrate niederschlägt (rockoder.com).

Mit anderen Worten: Ein sauberer Burndown kann mit einem echten Problem koexistieren. Das Diagramm sieht es nicht.

Was man daneben betrachten sollte

• Die Anzahl der nach dem Sprint-Review wieder geöffneten Karten.
• Die Zeit im Code-Review, nicht nur in der Entwicklung.
• Der Anteil der am letzten Sprinttag abgeschlossenen Karten.

Der kumulative Fluss zeigt, was Velocity verbirgt

Das kumulative Flussdiagramm stapelt Karten nach Status (zu erledigen, in Arbeit, in Review, erledigt) über die Zeit. Seine Stärke ist, Engpässe sichtbar zu machen. Ein Band „in Review“, das Woche für Woche dicker wird, zeigt an, dass die Produktion schneller ist als die Prüfung.

Dieses Ungleichgewicht hat Kosten. Der Artikel über kognitive Schulden formuliert es klar: Wenn ein Junior-Ingenieur Code schneller erzeugen kann, als ein Senior-Ingenieur ihn ernsthaft prüfen kann, sinkt die Review-Tiefe, oft ohne explizite Entscheidung, weil der organisatorische Druck auf Durchsatz drängt (rockoder.com).

Der kumulative Fluss sagt nicht, warum das Band wächst. Er sagt, wo man hinsehen sollte. Das ist schon viel.

Vier Interpretationsfehler, die immer wiederkehren

1. Kapazität mit Zusage verwechseln. Vergangene Velocity beschreibt, was getan wurde, nicht was versprochen ist.
2. Zahlen glätten, um zu beruhigen. Einen atypischen Sprint zu entfernen, weil er „nicht zählt“, bedeutet, die nützlichste Information zu löschen.
3. Metriken zur individuellen Bewertung nutzen. Sobald ein Bericht der Einstufung von Personen dient, werden die Daten zum Spiel.
4. Teams untereinander vergleichen. Punkte sind keine universelle Einheit, selbst innerhalb einer Organisation.

Ein Team, das ein Kanban-Board mit anpassbaren Spalten und Aktivitätsprotokoll einführt, etwa in Ever Earlier, verfügt bereits über das Rohmaterial: wer was bewegt hat, wann, und wie schnell Karten die Spalten durchlaufen. Berichte fügen nichts hinzu, wenn diese Grundlage nicht zuverlässig ist.

Zahlen lesen, ohne sie zum Überwachungswerkzeug zu machen

Der Unterschied zwischen einem nützlichen Bericht und einem Überwachungswerkzeug beruht auf drei einfachen Regeln.

Regel 1: eine Zahl, eine Entscheidung

Bevor Sie einen Bericht öffnen, schreiben Sie die Frage auf, die er beantworten soll. „Ist der Sprint überdimensioniert?“ „Wo sammelt sich wartende Arbeit?“ Ein Diagramm, das keine Entscheidung ändert, muss nicht jede Woche konsultiert werden.

Regel 2: Trends betrachten, nicht Punkte

Eine Velocity von 38 Punkten in einem isolierten Sprint bedeutet nichts. Drei Sprints bei 38, 40, 37 nach einem Durchschnitt von 45, ja. Der Burndown wird genauso gelesen: Die Form der Kurve zählt mehr als ihr Endwert.

Regel 3: über Ursachen sprechen, nicht über Punktzahlen

Ein kumulativer Fluss, der eine Überlastung im Review zeigt, eröffnet eine Diskussion über die Größe der Karten, die Verfügbarkeit der Prüfer, die Definition von „fertig“. Er benennt niemanden.

In Ever Earlier sind die Sprint-Berichte (Burndown, Velocity, kumulativer Fluss) vom selben Bereich aus zugänglich wie das Backlog und die User Stories. Der Vorteil ist praktisch: Wenn eine Story im Review blockiert bleibt, findet man sie direkt im Board wieder, mit ihren Kommentaren und ihrer Historie, ohne das Werkzeug zu wechseln.

Eine gesunde Lesart in drei Sprints einführen

Kein Großprojekt nötig. Drei Sprints genügen, um eine Routine zu etablieren.

1. Sprint 1: messen, ohne etwas zu ändern. Velocity, Form des Burndown, Dicke der Bänder des kumulativen Flusses notieren. Keine Schlussfolgerung.
2. Sprint 2: einen einzigen Aufmerksamkeitspunkt identifizieren, zum Beispiel die am letzten Tag abgeschlossenen Karten. In der Retrospektive ansprechen, ohne Zahlenziel.
3. Sprint 3: eine konkrete Anpassung testen — die maximale Kartengröße reduzieren oder einen halben Tag Review in der Sprintmitte blockieren — und prüfen, ob sich die Kurve ändert.

Dieser Rhythmus vermeidet die klassische Falle: eine Retrospektive in ein Performance-Komitee zu verwandeln. Eine Retrospektive, die Trends über drei Sprints untersucht, produziert Entscheidungen. Eine Retrospektive, die die Zahl der Woche kommentiert, produziert Spannungen.

Was man mitnehmen sollte

Velocity beschreibt eine vergangene Kapazität. Der Burndown beschreibt einen Verlauf. Der kumulative Fluss beschreibt eine Zirkulation. Keiner der drei misst die Qualität, den Wert oder das Verständnis der gelieferten Arbeit.

Sie richtig zu nutzen bedeutet, sie als Diagnoseinstrumente zu behandeln, nicht als Noten. Eine Lücke zwischen Produktion und Verständnis kann in diesen Berichten monatelang unsichtbar bleiben; das ist ein Grund, sie mit Vorsicht zu lesen, nicht sie aufzugeben.

Wenn Sie diese Lesart an einem echten Projekt testen möchten, ist der Starter-Plan von Ever Earlier kostenlos, ohne Kreditkarte, mit drei Projekten und fünf Mitgliedern.