Hauptgedanke

Einen Defekt sofort zu beheben hat einen sichtbaren Preis: ein Feature, das nicht fertig wird, ein gestörtes Sprint-Ziel, ein verschobenes Roadmap-Thema. Das ist unangenehm, und es ist normal — Qualität verbraucht Kapazität wie alles andere auch.

Ein Team, das Defekte beiseiteschiebt, um seine Velocity zu halten, bekommt genau das, was es misst. Die Zahl hält. Währenddessen sammeln sich Reibung im Gebrauch, Support-Last, Schulden und Misstrauen an — und keiner dieser vier Posten fließt in die Velocity ein.

Warum das wichtig ist

Die Velocity misst einen Lieferdurchsatz, nicht den Zustand des Produkts. Wer sie zum Ziel macht, schafft genau den Anreiz, nicht zu beheben: Der einzige Weg, die Zahl zu schützen, besteht darin, die Qualität aus dem gemessenen Bereich herauszunehmen.

Nuancen und Grenzen

Auch das umgekehrte Extrem gibt es. Ein Team, das seine gesamte Kapazität aufs Beheben verlagert, schützt das Produkt und liefert nichts mehr — und auch das hat seinen Preis.

Offene Fragen

• Welches Maß drückt die Kosten der Defekte in derselben Einheit aus wie die Velocity, damit die Abwägung lesbar wird?