Velocity

Velocity ist englisch für Geschwindigkeit. In der Softwareentwicklung bezeichnet das Wort eine Kennzahl. Viele Entwicklerteams arbeiten in festen Zeitabschnitten von meist zwei Wochen. Am Anfang eines solchen Abschnitts nehmen sie sich eine Liste von Aufgaben vor. Am Ende zählen sie zusammen, wie viel davon wirklich fertig geworden ist. Genau diese Summe ist die Velocity des Teams. Sie misst also nicht, wie schnell einzelne Leute tippen, sondern wie viel Arbeit hinten fertig herauskommt.

Warum Teams ihr eigenes Tempo messen

Softwareprojekte werden notorisch zu optimistisch geschätzt. Fragt man ein Team, wie lange etwas dauert, kommen oft Wunschzahlen heraus. Velocity ersetzt diese Wunschzahlen durch Erfahrungswerte. Wenn ein Team in den letzten sechs Abschnitten im Schnitt 30 Punkte geschafft hat, wird es im nächsten kaum 60 schaffen. Das ist eine unbequeme, aber nützliche Information.

Für Planung ist das wertvoll. Ein Produktchef kann grob abschätzen, wann eine Funktion fertig sein wird. Statt eines Versprechens gibt es eine Bandbreite: irgendwann zwischen Ende März und Mitte April. Auch Investoren und Vorstände hören solche Zahlen gern, weil sie Softwarearbeit halbwegs greifbar machen.

Gefährlich wird es, wenn Velocity zum Leistungsziel wird. Eine Kennzahl, die belohnt wird, lässt sich manipulieren. Ein Team kann seine Punktzahlen einfach großzügiger vergeben und sieht dann doppelt so produktiv aus, ohne mehr zu leisten. Deshalb gilt in der Praxis: Velocity ist ein Planungswerkzeug für das Team selbst, kein Zeugnis von außen.

Story Points und der Durchschnitt über mehrere Sprints

Um Arbeit zu zählen, braucht man eine Einheit. Stunden funktionieren schlecht, weil niemand Stunden verlässlich vorhersagen kann. Stattdessen benutzen Teams meist sogenannte Story Points. Das sind Schätzpunkte, die den relativen Aufwand einer Aufgabe ausdrücken. Eine Aufgabe mit 8 Punkten ist ungefähr doppelt so aufwendig wie eine mit 4 Punkten.

Am Ende jedes Zeitabschnitts – im Fachjargon Sprint genannt – werden nur die vollständig fertigen Aufgaben gezählt. Halb erledigte Arbeit bringt null Punkte. Das klingt hart, verhindert aber Selbstbetrug. Die Punktzahlen mehrerer Sprints bildet man dann zum Durchschnitt, oft über die letzten drei bis fünf. Einzelne Sprints schwanken zu stark, etwa wegen Krankheit oder Feiertagen.

Wichtig ist eine Abgrenzung: Velocity-Zahlen verschiedener Teams lassen sich nicht vergleichen. Jedes Team legt seine Punkteskala selbst fest. 40 Punkte bei Team A können weniger Arbeit bedeuten als 20 Punkte bei Team B. Die Zahl ist nur innerhalb eines Teams und über die Zeit hinweg aussagekräftig, ähnlich wie eine persönliche Bestzeit beim Laufen.

Von Jira-Diagrammen bis zu KI-Programmierhilfen

Wer in einem Unternehmen mit Software zu tun hat, stößt fast zwangsläufig auf Velocity. Projektwerkzeuge wie Jira oder Azure DevOps berechnen sie automatisch und zeichnen Balkendiagramme pro Sprint. In Meetings hängen diese Diagramme dann an der Wand und werden diskutiert.

In den letzten Jahren tauchte der Begriff auch in der KI-Debatte auf. Anbieter von Programmierassistenten, die Code vorschlagen, werben damit, die Velocity von Teams zu erhöhen. Studien dazu sind gemischt: Code entsteht schneller, aber es entstehen auch mehr Fehler und mehr Nacharbeit. Ob die fertige Arbeit tatsächlich zunimmt, ist umstritten.

Außerhalb der Softwarewelt hat das Wort noch andere Bedeutungen. In der Wirtschaft bezeichnet die Umlaufgeschwindigkeit des Geldes, englisch velocity of money, wie oft ein Euro pro Jahr den Besitzer wechselt. Und beim Thema Big Data ist Velocity eines von mehreren V-Merkmalen und beschreibt, wie schnell neue Daten hereinströmen. Beim Lesen von Nachrichten lohnt es sich also, kurz auf den Zusammenhang zu achten.