Velocity

Velocity steht für Geschwindigkeit und kann daher in vielen Bereichen zur Anwendung kommen. So auch im Java Umfeld: Das sogenannte Top Level Projekt Apache Velocity dient der Trennung von Inhalt und Präsentation. Die Basis hierfür bildet die Velocity Template Language (VTL). Neben dem Handwerk und der Wissenschaft und weiteren Gebieten spielt Velocity auch bei Scrum eine entscheidende Rolle. Diese soll in dieser Übersicht genauer betrachtet werden.

Allgemeine Informationen zum Thema

Bei Scrum gibt Velocity Auskunft über Fragen wie: „Wann wird das Projekt fertig?“, „Wie viele Elemente werden fertiggestellt?“ oder „Was wird das kosten?“. Grundsätzlich muss man bei der Ermittlung der Velocity zwischen zwei Vorgehensweisen unterscheiden. Wenn Scrum Teams bereits miteinander gearbeitet haben, lässt sich die voraussichtliche Velocity im Vorfeld recht gut einschätzen, wenn auch nicht präzise ermitteln. Kommt ein Team dagegen das erste Mal zusammen, liegen naturgemäß noch keine historischen Daten vor, auf deren Grundlage die Velocity festgelegt werden könnte.

In diesem Fall kann der Versuch unternommen werden, auf die Daten anderer Teams zurückzugreifen, die ähnliche Projekte durchgeführt haben. Alternativ dazu können zwei Sprints geplant werden, wobei der eine die obere und der andere die untere Velocity ermitteln soll. Wurde der erste Sprint beendet, hat man konkrete Werte und kann die Schätzungen vernachlässigen.

Chancen und Gefahren der Steigerung der Velocity

Je mehr Erfahrungswerte bzw. historische Daten vorliegen, desto leichter scheint es zu fallen, die Velocity zu erhöhen und somit die Effizienz zu steigern. Auch eine verbesserte Zusammensetzung des Scrum Teams mit entsprechend passenden Aufgabenverteilungen oder die Einbeziehung unterstützender Tools kann zu einer Steigerung der Velocity führen. Die genannten Aspekte können aber auch einen gegenteiligen Effekt haben, weil eingespielte Teams sich neu sortieren oder bislang nicht genutzte Tools zunächst kennengelernt werden müssen. Diese Faktoren können vorübergehend auch zu einer Senkung der Velocity führen.

Der auf den ersten Blick einfachste Weg zur Steigerung der Velocity ist die Anordnung von Überstunden. Erfahrungsgemäß werden damit zwar Steigerungsraten erzielt, diese sind aber nicht nachhaltig, weil der Stressfaktor im Team zunimmt und entsprechende Zeiten der Regeneration bei den Mitarbeitern benötigt werden. Zudem ist die Gefahr nicht von der Hand zu weisen, dass mangels Motivation der Teams die Qualität der Arbeit mittel- bis langfristig sinkt. Eine nahezu grenzenlose Verbesserung der Velocity ist schlicht nicht möglich, vielmehr gilt es, die Grenzen und Chancen gegeneinander abzuwägen.

Die richtige Methode zur Ermittlung der Velocity

Wie bereits erwähnt, ist die Einschätzung der Velocity umso schwieriger, je weniger Daten und Erfahrungen vorliegen. Gleiches gilt auch für all die anderen Anforderungen bei Scrum Projekten. Auch sie müssen geschätzt werden, wobei sich zwei Methoden gegenüberstehen, die miteinander konkurrieren.

Auf der einen Seite gibt es abstrakte Größen wie Story Points, die keine konkreten Einheiten darstellen. Auf der anderen Seite können konkrete Angaben wie etwa Stunden oder Personaltage für die Schätzung der Anforderungen genutzt werden.

Beide Methoden bieten Vor- und Nachteile, wie sich aus folgender Tabelle ergibt:

Methode	Vorteile	Nachteile
Konkrete Einheiten (Stunden, Personaltage etc.)	Gute Transparenz Einfache Kommunikation Kompatibel zu traditionellen Methoden Durch die Bekanntheit der Methode wenig Konflikte	Die Gefahr, den eigenen Selbsteinschätzungen durch Selbstbetrug und dem festhalten an den Zahlen zu erledigen Selbst erfahrene Entwickler können nur ungenaue Schätzungen abgeben Die Steigerung der Velocity ist kaum feststellbar
Abstrakte Einheiten (Story Points etc.)	Der Schwerpunkt liegt auf dem Nutzen, der für den Kunden erzielt werden kann Selbst wenig erfahrene Entwickler können recht genau Abschätzungen abgeben Die Steigerung der Velocity ist feststellbar	Gegenüber anderen Abteilungen fehlt die Kompatibilität Der Zusammenhang von Faktoren wie Funktionalität, Rahmenbedingungen oder Komplexität und deren Einfluss auf die Schätzungen gestaltet sich schwierig In der Regel entsteht ein größeres Konfliktpotenzial

Zur Steigerung der Velocity sind zwar abstrakte Einheiten sinnvoll, jedoch muss anhand aller Aspekte entschieden werden, ob diese auch zum Rest des Projektes passt.

Bedeutung für das Development

Wird die Velocity richtig angewendet, kann sie helfen, die Planung, Steuerung und das Controlling von Projekten richtig einzuschätzen. So lassen sich genau Preise für die Kunden kalkulieren und die Liefertermine einhalten. Allerdings muss die Velocity ernstgenommen werden und darf nicht aus dem Fokus der Beteiligten verschwinden. Beispielsweise wirkt es sich negativ aus, wenn das Team von einer konstanten Velocity ausgeht, obwohl bekannt ist, dass sie sich in die eine oder andere Richtung verschoben hat (also schneller oder langsamer wurde). Die Schätzungen müssen also im Laufe des Projekts regelmäßig überprüft und angepasst werden.

Wenn die Velocity nicht ständig in die Prozesse einbezogen wird, kann es passieren, dass die Deadline, die einzuhalten ist, plötzlich nicht mehr eingehalten werden kann.

Ist man sich über die Chancen und Nachteile der Velocity bewusst und richtet die Projektarbeit danach aus, ist sie ein hilfreiches Instrument, um Projekte erfolgreich vom Anfang bis zum Ende durchzubringen, ohne ungewollte Überraschungen zu erleben.

Weblinks

• Poster Vorteile von Sprints
• Story Points, Velocity vs. Zeit schätzen
• Normalisierte Story Points – wie und warum?
• Was ist Velocity?